「ベクトルDBは専用プロダクトを別建てで入れるもの」——少し前まではそう判断するエンジニアが多かったはずです。私もそうでした。
ところが2026年に入って潮目が変わりました。OpenAIが8億人のChatGPTユーザーを支えるバックエンドにPostgreSQLを据えていることを公開。Microsoftも公式に「生成AI時代のデータ基盤としてPostgreSQLの重要性が高まっている」と発信。AWS・Azure・Google Cloudの3大マネージドはいずれもpgvector拡張をフル対応にし、DiskANNやScaNNといった独自インデックスまで載せ始めました。
本記事では、PostgreSQL × AI の現在地、専用ベクトルDBとの使い分け、各クラウドのマネージド事情、導入時の落とし穴を、クラウド管理者・SRE視点で整理します。
PostgreSQLが生成AI時代の「定番DB」になった理由
まずは事実関係から押さえます。決定打になったのは、OpenAI自身の公開情報です。
OpenAIが公開したChatGPTのDB構成
OpenAIは2026年初め、ChatGPTのバックエンドにPostgreSQLを大規模採用していることを公開しました。OpenAI公式ブログとInfoQ（2026年2月12日掲載）で明らかにされた構成は次の通り。
- 対象ユーザー数: 約8億人のChatGPT利用者
- 稼働基盤: Azure Database for PostgreSQL Flexible Server
- 構成: 単一プライマリ＋約50台の地理分散リードレプリカ
- 負荷の伸び: 過去1年で10倍超
- p99レイテンシ: 2桁ミリ秒台の前半
- 接続プール: PgBouncer（transaction poolingモード）
注目すべきは、これだけの規模を「単一プライマリ」で捌いている点です。シャーディングしていない。20年以上Linuxサーバーを運用してきた立場から見ても、読み取りレプリカ戦略が成立する設計ならここまで伸ばせる、という生きた証拠です。
Microsoftが公式に「定番」と発信した
TechTargetジャパン（2026年5月8日）では、Microsoftが「クラウドネイティブ環境における新規アプリケーション展開の選択肢としてPostgreSQLの重要性が高まっている」と明言したと報じられています。自社の商用DB（SQL Server）よりオープンソースのPostgreSQLを前に出すのは、商売としては不自然な動きです。それでもそうしているのは、市場の現実がPostgreSQLに動いている、という認識の表れに見えます。
「コスト削減用DB」から「AI基盤の主役」へ
もともとPostgreSQLは、Oracleからの乗り換えコスト削減という文脈で語られることが多かったDBです。ここ2〜3年で立ち位置がはっきり変わった理由は拡張機能の充実。pgvector・PostGIS・TimescaleDB・pg_trgmなど、専用DBの機能を拡張1つで取り込めるアーキテクチャが、生成AIの「いろんな型のデータを扱いたい」ニーズと噛み合いました。
pgvectorとは何か——拡張機能としての実体
1行でいうと「ベクトル型と類似検索を足す拡張」
pgvectorは、PostgreSQLに以下を追加するC言語製の拡張機能です。
- vector / halfvec / sparsevec / bit といったベクトル型のカラム
- 距離演算子（L2・内積・コサイン・L1・ハミング・ジャッカード）
- HNSW・IVFFlatの2種類のインデックス
導入はSQLでCREATE EXTENSION vector;を打つだけ。AWS RDS・Azure・Google Cloud SQL・AlloyDBはマネージド側で拡張が許可済のため、この一行で有効化できます。
最新バージョンと変遷
2026年5月時点の最新はpgvector 0.8.2（2026年2月26日リリース）。並列HNSWインデックス構築時のバッファオーバーフロー（CVE-2026-3172）を塞ぐセキュリティ修正版。本番運用中なら早めの更新を強く推奨します。
| バージョン | 主な追加・修正 | 運用上のポイント |
|---|---|---|
| 0.7.0 | halfvec（4,000次元まで）・sparsevec（1,000非ゼロ次元）・ハミング/ジャッカード距離・L1距離のHNSWサポート | 埋め込みを2バイトfloatで保存できるためストレージ半減 |
| 0.8.0 | iterative index scan（hnsw.iterative_scan / ivfflat.iterative_scan）追加 | フィルタ付き検索の「過剰絞り込み」問題が解消 |
| 0.8.2 | CVE-2026-3172（並列HNSWインデックスのバッファオーバーフロー）修正 | 本番運用中なら即時アップデート対象 |
HNSWとIVFFlatの使い分け
- HNSW: 検索精度・速度が高い。インデックス構築は遅くメモリも食う。本番の基本選択。
- IVFFlat: 構築が速く軽量、その分検索精度はHNSWに劣る。追加が多いケースや検証向け。
迷ったらHNSW、で実害はほぼ出ません。
なぜ専用ベクトルDBではなくPostgreSQLか
「Pinecone / Weaviate / Qdrant / Milvusと、結局どれを選ぶべきか」は、現場で一番聞かれる質問です。私の答えはこうです。すでにPostgreSQLを使っているなら、まずpgvectorで試す。それで足りなければ専用に逃げる。逆はしない。
主要ベクトルDB比較表
| 項目 | PostgreSQL+pgvector | Pinecone | Weaviate | Qdrant | Milvus |
|---|---|---|---|---|---|
| 提供形態 | OSS（マネージド可） | フルマネージドのみ | OSS＋マネージド | OSS＋マネージド（Rust製） | OSS＋マネージド（Zilliz） |
| 得意な規模 | 10M〜100M（pgvectorscale併用で50Mまで競争力） | 10M〜数B | 10M〜1B | 10M〜1B | 100M〜10B以上 |
| p99検索遅延（10M目安） | 20〜30ms前後（環境依存） | 10ms前後 | 約16ms | 約12ms | 約18ms |
| SQLとのJOIN | ○ ネイティブ | × | △（GraphQL） | × | × |
| トランザクション一貫性 | ○ ACID | × | △ | △ | △ |
| ハイブリッド検索 | ○（tsvector・pg_trgmと組合せ） | ○ 専有スパース符号化 | ○ BlockMax WAND＋RSF | ○ named vector hybrid | ○ Sparse-BM25 |
| 運用負荷 | 既存DBA運用に統合 | 低（マネージド任せ） | 中 | 中 | 中〜高（分散構成） |
| ライセンス | PostgreSQLライセンス（OSS） | 商用 | BSD-3 | Apache-2.0 | Apache-2.0 |
PostgreSQL+pgvectorの強み
表だけでは伝わらない、現場で効く強みを3つ挙げます。
- JOINで完結する: ユーザーIDで絞り込み、過去30日のドキュメントだけで類似検索、といった「メタデータ条件＋ベクトル類似度」を1本のSQLで書ける。専用DBだとアプリ層の前処理が必要でコードが膨らみがち。
- トランザクション一貫性が当然手に入る: 埋め込み生成と本文INSERTを同一トランザクションで書ける。専用DBは結果整合になりがちで、再ベクトル化時に整合性管理を自前で用意する必要が出る。
- 運用体制を分けなくていい: バックアップ・監視・障害対応・パッチ適用を1スタックで完結。専用DBを足すと運用窓口が増える。
専用DBに逃げるべき判断ライン
逆にpgvectorで無理が出るのは、①ベクトル数が1億を大きく超える、②1万QPS級が要る、③SQL要件がなく純粋にベクトル検索だけ、④分散シャーディング前提、のいずれかです。この場合はMilvus分散・Vespa、規模重視ならPineconeに軍配が上がります。判断基準はあとでチェックリストにまとめます。
クラウド各社のマネージドPostgreSQLとベクトル対応
AWS・Azure・Google Cloudそれぞれが、pgvectorをただ載せるだけでなく、独自の「+α」を投入し始めています。比較しておきます。
AWS Aurora PostgreSQL / RDS for PostgreSQL
- pgvector 0.8.0サポート済
- Aurora Optimized Readsでベクトル検索QPSが最大9倍
- Amazon Bedrock Knowledge Basesのベクトルストアに直接指定可能
- PostgreSQL 18は2025年11月にRDSで対応開始
BedrockでRAGを組むなら、ベクトルストアにAuroraを選べる時点でAWS内完結の設計が組みやすい。検証用環境でも、検索を頻発させるワークロードはOptimized Readsの効きが体感で分かるレベルでした。
Azure Database for PostgreSQL Flexible Server
- pgvectorに加えて、Azure独自のDiskANNインデックスを提供
- azure_ai拡張でAzure OpenAIから埋め込み生成をSQLで呼び出せる
- ChatGPTのバックエンドそのものが稼働している実績（OpenAI事例）
DiskANNは、メモリに乗り切らない巨大ベクトルセットでも高QPS・低遅延を狙える設計で、Azure独自の差別化要素です。10億点規模を想定するならAzure側の優位が大きい。
Google Cloud SQL / AlloyDB for PostgreSQL
- Cloud SQL・AlloyDBの両方でpgvector公式サポート
- AlloyDBはScaNNインデックスを追加サポート（Google Researchの12年の蓄積）
- vector assist機能で、埋め込み生成・クエリ最適化・インデックス作成を宣言的SQLで実行
- google_ml_integration拡張からVertex AIのtext-embedding-005を呼び出して埋め込みを自動生成
AlloyDBのScaNNは、Google検索の延長線にある技術なので、検索品質を最重要視するアプリケーションには魅力的です。
マネージド比較表
| 項目 | AWS RDS/Aurora | Azure Flexible Server | Google AlloyDB |
|---|---|---|---|
| pgvectorバージョン | 0.8.0 | 0.8.x | 0.8.x |
| 独自インデックス | —（pgvector純正） | DiskANN | ScaNN |
| 埋め込み生成連携 | Bedrock経由 | azure_ai拡張 | google_ml_integration |
| マネージドRAG連携 | Bedrock Knowledge Bases | Azure AI Search連携 | Vertex AI Agent Builder |
| 料金体系の傾向 | インスタンス＋ストレージ＋IO | インスタンス＋ストレージ | インスタンス（AlloyDBはやや高め）＋ストレージ |
pgvectorでRAGを組む——構成と最小コード例
具体的な実装イメージがないと判断しにくいので、最小構成のRAG（Retrieval-Augmented Generation）パイプラインの骨格を示します。
全体構成
- 質問を埋め込みモデルでベクトル化（例: text-embedding-3-small / text-embedding-005）
- pgvectorで類似ドキュメントをTop-K検索
- 取得文書を文脈としてLLMに渡す
- 応答をユーザーに返す
テーブル定義の最小例
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE documents (
id bigserial PRIMARY KEY,
title text NOT NULL,
content text NOT NULL,
embedding vector(1536),
tenant_id bigint NOT NULL,
created_at timestamptz NOT NULL DEFAULT now()
);
-- HNSWインデックス（コサイン距離）
CREATE INDEX ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);
-- メタデータ絞り込み用
CREATE INDEX ON documents (tenant_id);
類似検索クエリの例
-- tenant_id=42 のドキュメントから、質問ベクトルに近いTop5を取得
SET hnsw.ef_search = 100;
SET hnsw.iterative_scan = strict_order; -- pgvector 0.8.0以降
SELECT id, title, content,
1 - (embedding <=> $1::vector) AS similarity
FROM documents
WHERE tenant_id = 42
ORDER BY embedding <=> $1::vector
LIMIT 5;
注目してほしいのは、tenant_idでWHERE絞り込みしながら類似検索できる点です。マルチテナントSaaSでは、この一本のSQLが書けるかどうかで運用が変わります。専用ベクトルDBだとテナント分離をネームスペース単位で持たせる設計が要求され、運用とコスト計算が一段複雑になります。
埋め込み更新時の整合性
埋め込みモデルを変えた瞬間に既存ベクトルとの距離が意味を失う、というのは見落とされがちな課題です。pgvectorなら、新カラムembedding_v2を増やしてバックフィルしながら古いクエリは旧カラムを使い続ける、といった切り替えをトランザクションで管理できます。専用ベクトルDBではこれが意外と面倒です。
性能・スケーリングの考慮点
「ベクトル検索が遅い」「メモリが足りない」と相談を受けることが増えました。詰まりやすい4点を潰します。
1. 次元数とストレージ
OpenAIのtext-embedding-3-largeは3,072次元、smallは1,536次元。1ベクトルあたり3,072次元×4バイト＝12KB前後、1,000万件で約120GB。pgvector 0.7.0で追加されたhalfvecを使えば2バイトfloatになり、ストレージが半分になります。RAG用途なら精度劣化はほぼ許容範囲です。
2. メモリとHNSWパラメータ
HNSWインデックスはメモリに乗り切らないと一気に遅くなります。経験則は次の通り。
- maintenance_work_memをインデックス構築時だけ大きく（4GB以上）
- m=16 / ef_construction=64から始め、精度不足ならefを上げる
- 検索時はhnsw.ef_searchを40〜200で調整（大きいほど精度↑・速度↓）
3. 過剰絞り込み問題とiterative scan
pgvector 0.8.0以前は、WHERE句で強く絞ったTop-K検索でTop-Kが埋まらない「過剰絞り込み」が発生しました。0.8.0で追加されたhnsw.iterative_scan = strict_orderを有効にすれば、必要件数が埋まるまでインデックスを掘り進めてくれます。マルチテナント設計では実質必須です。
4. レプリカ戦略
OpenAIが約50台のリードレプリカで捌いているように、ベクトル検索は読み取り中心ワークロードと相性がいい。書き込みTPSと読み取りQPSの境界線を早めに引くのが鉄則です。
移行・導入時の注意点（料金・運用・バックアップ）
専用ベクトルDBからの移行、または新規導入を検討する人向けに、現場で詰まる箇所を列挙します。
料金の見積もり方
マネージドPostgreSQLの月額は、ざっくり「インスタンス単価×720時間＋ストレージ＋I/O・レプリカ＋データ転送」で見積もれます。1,000万ベクトル規模・中規模インスタンスなら月数百〜2,000ドル前後に収まることが多く、運用工数も含めれば専用DBより明確に安いケースが目立ちます。10億ベクトル級ではAlloyDBやAzure DiskANNでもインスタンス費が重くなり、Milvus分散の選択肢が現実味を帯びます。
バックアップ
ベクトル列もテキスト列も、PostgreSQLにとっては単なる列です。pg_dumpもPITRもそのまま機能します。これが地味に大きい。専用ベクトルDBはバックアップ・リストア手順が独自で、災害復旧訓練を別建てで運用する負担がかかります。
セキュリティ
- pgvector 0.8.2は必ず適用（CVE-2026-3172対策）
- 埋め込みは「元テキストの意味」を保持する。個人情報を含むテキストから生成した埋め込みは、それ自体が個人データ扱いになり得る
- マルチテナントではRow Level Securityの併用を推奨
監視
従来のpg_stat_statements・pg_stat_user_indexesに加えて、ベクトル検索固有の指標を見ます。
- HNSWインデックスのef_search別の応答時間分布
- iterative scanが発火した回数
- 埋め込み生成API（OpenAI / Vertex AI）のレイテンシとエラー率
FAQと導入判断チェックリスト
Q1. 既存DBがMySQLですが、AIのためだけにPostgreSQLに移行する価値はありますか？
A. アプリ全体を移行するのではなく、ベクトル/RAG用にPostgreSQLを別建てで足すのが現実解です。MySQLにはまだベクトル拡張の決定版がなく、生成AIワークロード用に小さなPostgreSQLを横に置く構成がよく採られます。
Q2. pgvectorは10億ベクトルまでスケールできますか？
A. 単体では10M〜100Mが現実的上限。pgvectorscale（Tiger Data）併用で50M前後まで競争力を維持できます。1億を大きく超えるならAlloyDBのScaNNやAzure DiskANN、もしくはMilvus分散・Vespaが安全です。
Q3. PineconeからPostgreSQLに移行する場合、何から始めればよいですか？
A. ①既存埋め込みをエクスポート（Pinecone fetch API）→②PostgreSQLにINSERT→③HNSWインデックス構築、の3段階。アプリ層のSDK差し替えはこの後。実装より先に、再ベクトル化が必要か（モデル変更の有無）を確定させるのが要点です。
Q4. PostgreSQL 18のAIO（非同期I/O）はベクトル検索にも効きますか？
A. 効きます。HNSWはランダムI/Oが多く、AIOの恩恵が大きい。公式値の「ストレージ読み出し最大3倍」はOLTP寄りですが、ベクトル検索でも体感差は出ます。新規構築ならPostgreSQL 18を選んで損はありません。
Q5. 埋め込みモデルを変えるとき、ダウンタイムなしで切り替える方法は？
A. 新カラム（例: embedding_v2 vector(3072)）を追加してバックフィルし、書き込みは新旧両方に行う「デュアルライト」が定石です。完了後に検索を新カラムへ切り替え、旧カラムは一定期間後に削除。トランザクションがあるからこそ素直に書けます。
導入判断チェックリスト
PostgreSQL+pgvectorで進めるか、専用ベクトルDBに振るかの判断材料です。「はい」が多いほどpgvector向き。
pgvector向きの条件
- ☐ 既にPostgreSQLを使っている（または使う予定）
- ☐ メタデータ絞り込み（テナント・期間・カテゴリ）が必要
- ☐ トランザクション一貫性が欲しい
- ☐ 想定ベクトル数が1億以下
- ☐ 想定検索QPSが1,000未満
- ☐ クラウドのマネージドサービスを使える
- ☐ バックアップ・監視・障害対応を1スタックで完結したい
専用ベクトルDBを検討すべき条件
- ☐ ベクトル数が1億超または10億以上を計画
- ☐ 検索QPSが数千〜万単位
- ☐ SQL要件がほとんどない
- ☐ フルマネージドで工数を最小化したい（Pinecone）
- ☐ ハイブリッド検索の品質が事業の中核（Weaviate）
- ☐ 低レイテンシp99数msが必須（Qdrant / Pinecone）
導入前の最終確認
- ☐ 埋め込みモデルと次元数を決めた
- ☐ 3年後のベクトル数を試算した
- ☐ pgvector 0.8.2を選定（CVE-2026-3172対策）
- ☐ HNSWパラメータ（m / ef_construction / ef_search）を試験
- ☐ iterative_scanを有効化（マルチテナント時）
- ☐ レプリカ戦略と読み書き分離を設計
- ☐ バックアップ・PITR・災害復旧手順を確認
- ☐ 埋め込みモデル変更時のデュアルライト計画
- ☐ Row Level Security設計（マルチテナント時）
まとめ——「専用を1個増やす前に、Postgresを1個使い倒す」
OpenAIが8億ユーザー規模で動かし、Microsoftが公式に「定番」と発信し、AWS・Azure・GCPの3大マネージドが揃ってpgvectorをフル対応にした。2026年5月時点の事実を並べただけでも、PostgreSQLが「AI時代のデフォルトDB」に育ってしまったのは否定しようがない。
専用ベクトルDBにもそれぞれの良さがあります。Pineconeのマネージド体験、Qdrantの速度、Weaviateのハイブリッド検索、Milvusの分散規模——用途が合えば最適解になります。ただ判断の順序としては「まずpgvectorで足りるかを検証する」が正解だと思っています。足りなかった場合の移行コストは、PostgreSQL→専用の方が、専用→PostgreSQLより圧倒的に低い。SQLで書いたコードはSDK差し替えで済むことが多いが、専用DB前提のスキーマは作り直しになりやすいからです。
まだpgvectorを触ったことがなければ、ローカルのDockerでpostgres:18＋pgvector:0.8.2を立ててCREATE EXTENSION vector;から始めてみてください。1時間あれば最小のRAGがSQLだけで動きます。クラウドのマネージドに載せるのは、その次の判断で十分です。
コメント