RAGや意味検索を始めるとき、最初に来る大きな技術選定が 「ベクトル検索基盤をどれにするか」 です。pgvector（PostgreSQLの拡張）で済ませるのか、Pinecone・Qdrant・Weaviate・Milvus のような専用ベクトルDBを導入するのか。
この記事は、その判断を感覚ではなく軸で下すための技術選定ガイドです。先に結論を言えば——「どれが最強か」という問いは存在しません。 あるのは「あなたの制約（規模・整合性要件・運用体制・予算）に、どれが合うか」だけです。本稿は、発注者・アーキテクトがこの意思決定を後悔なく下せるよう、各製品の特性と判断軸を、公式情報に基づいて整理します。
この記事のルール：pgvector の仕様は 公式ドキュメントに基づきます。各専用DBの特性は各社公式に基づきますが、**性能（QPS・レイテンシ・コスト）の数値はすべて「ベンダーの主張」**として扱い、中立なベンチマークとしては提示しません（性能はデータ・次元・再現率目標・ハードで激変するため）。製品仕様は更新が速いので、導入前に必ず最新の公式情報で要確認してください。
1. 結論を先に：判断フローチャート
細かい比較に入る前に、8割の案件はこの数問で決まります。
Q1. すでに PostgreSQL を運用している？
├─ No → 「ベクトルのためだけに」Postgres を増やすのは本末転倒。
│ プロトタイプなら Chroma、本番なら Qdrant / Pinecone を検討。
└─ Yes ↓
Q2. 埋め込みは業務データ（ユーザー・注文・文書）と整合させる必要がある？
│ （= 文書を消したらベクトルも同時に消えるべき、等）
├─ Yes → pgvector が極めて有利（同一トランザクション・同一バックアップ）。
└─ どちらでも ↓
Q3. ベクトルは当面どのくらいの規模？
├─ 数百万〜数千万行 → pgvector で十分戦える。第一候補。
├─ ~5,000万〜1億超 → pgvector + pgvectorscale（StreamingDiskANN）を検討。
└─ 数億〜数十億・高並列 → 専用DB（Milvus 分散 / Pinecone serverless）が優位。
Q4. 高並列QPSで「アプリDBから独立した」厳しいレイテンシSLAがある？
├─ Yes → 専用DB（in-memory HNSW / Pinecone DRN / Qdrant）に寄せる。
└─ No → pgvector で問題になりにくい。
最短の結論：「すでに Postgres があり、数千万行までで、整合性が大事」——この、いわば大多数のB2B SaaS・社内ツールでは、pgvector が第一候補になります。新しいインフラを1つも増やさずに始められるからです（KISS / YAGNI）。
2. 技術選定の7つの判断軸
「どれが合うか」は、次の軸を自分の案件の重み付けで評価すれば見えてきます。
① 運用負荷（Operational Simplicity）
すでに Postgres を運用しているなら、pgvector は新しいインフラ・監視・バックアップ・オンコール対象をゼロ追加で導入できます。これが最大のレバーです。専用DB（セルフホスト）は「もう1つのシステム」を運用する覚悟が要ります。マネージド（Pinecone / Zilliz / Qdrant Cloud 等）は運用を肩代わりしてくれますが、ベンダーと月額が増えます。
② 業務データとのトランザクション整合性
pgvector の決定的な強みです。埋め込みと業務行を同一のACIDトランザクションで更新でき、SQLでJOINでき、バックアップも一貫します。専用DBは別系統なので、業務DB↔ベクトルDBの同期パイプラインが要り、ここが「消したはずの情報が検索に残る」というステイルネス事故の温床になります。整合性が要件なら pgvector が圧倒的に有利。
③ スケール上限（Scale Ceiling）
方向性であり、ハードな閾値ではありません（ワークロード依存）。
- pgvector / + pgvectorscale：数百万〜数千万は余裕。pgvectorscale のディスク常駐インデックスとチューニングで5,000万〜1億超まで押し上げる事例も。
- 専用DB（Milvus分散・Pinecone serverless・Qdrantクラスタ）：1億〜数十億を水平シャーディングで扱うのが本職。ここは明確に専用DBが上。
④ レイテンシSLA
高並列QPSでtightなp95/p99を、しかもアプリDBの負荷から独立して守る必要があるなら、in-memory HNSW の専用エンジン（Pinecone DRN / Qdrant 等）が有利です。pgvector は中規模では十分競争力がありますが、同じインスタンスがOLTPも捌く点は意識すべきです。
⑤ メタデータフィルタの能力
ここは差が出ます。「このテナントの・公開済みの文書だけ意味検索」をどう速くやるか。Qdrant（filterable HNSW） と pgvectorscale（Filtered/StreamingDiskANN） は、ANN探索中にフィルタを適用する事前/ストリーミングフィルタで「絞ったら結果が足りない」問題を回避します。素の pgvector も任意のSQL WHERE・JOINで表現力は最強ですが、高選択率フィルタはインデックス設計次第。複雑な高カーディナリティのフィルタが中心なら Qdrant / pgvectorscale を重く見ます。
⑥ コストモデル
- pgvector：既存 Postgres の中の限界コスト（新たな請求書なし。RAM/CPU/ディスクとDBA工数で払う）。
- マネージド専用DB：予測しやすい月額/従量だが、規模が出ると割高＋egress/ロックイン。
- セルフホストOSS（Qdrant/Milvus/Weaviate/Chroma）：ライセンス費ゼロ、インフラ＋運用人件費で払う。
⑦ 移行コスト / ロックイン
Pinecone は proprietary（クローズドソース）で、数億ベクトルの引っ越しは非自明＝出口コストが最大。一方、pgvector（PostgreSQLライセンス）・Qdrant/Milvus/Chroma（Apache 2.0）・Weaviate（BSD-3） はOSSで、自己ホストも移行も可能。ロックインは初日に評価すべき軸です。
3. 比較表：pgvector と主要な専用ベクトルDB
各製品の素性を一枚に。性能の優劣ではなく「設計思想と土俵」の違いとして読んでください。
| 製品 | デプロイ形態 | 主なインデックス | ライセンス | 際立つ強み | 主なトレードオフ | 得意な規模・対象 |
|---|---|---|---|---|---|---|
| pgvector | Postgres拡張（どこでも） | HNSW / IVFFlat | PostgreSQL License | 既存Postgresに集約・業務データと同一トランザクション・SQLそのまま | 超大規模・高並列SLAは専用DBに劣る | 数百万〜数千万（+scaleで1億級）。Postgres運用チーム |
| Pinecone | マネージド専用（クラウドのみ） | 独自serverless（storage/compute分離） | Proprietary（非OSS） | ゼロ運用・サーバーレスで数十億までスケール | ロックイン最大・自己ホスト不可・内部非公開 | 運用を一切したくない・大規模・SaaS許容 |
| Qdrant | OSS自己ホスト ＋ Cloud | 独自HNSW（フィルタ可能・Rust製） | Apache 2.0 | フィルタ付きANNが随一・高効率・ライセンスの罠なし | 大規模の水平スケールは運用作業 | フィルタ重視のRAG/検索/推薦。OSS志向 |
| Weaviate | OSS自己ホスト ＋ Cloud | HNSW / flat / dynamic | BSD-3-Clause | オブジェクト+ベクトル統合・埋め込み/ハイブリッド検索モジュール内蔵 | 純ANNより重く意見が強い設計 | 統合型「AIネイティブDB」を一括で欲しいチーム |
| Milvus | OSS自己ホスト（Lite/単体/分散）＋ Zilliz Cloud | 最多（HNSW/IVF/DiskANN/SCANN/GPU） | Apache 2.0 | 最大スケール・インデックスの選択肢が最も広い・GPU対応 | 分散モードは運用が重い（K8s・多コンポーネント） | 数億〜数十億の本格大規模。ops成熟チーム |
| Chroma | 組込み/単体/分散 ＋ Cloud | HNSWベース | Apache 2.0 | プロトタイピングが最速（import chromadb で即） | 超大規模の実績は新しめ | PoC・小〜中規模RAG・ローカル開発 |
表の「デプロイ形態」「ライセンス」「インデックス」は各社公式由来の事実です。「強み/トレードオフ」は設計思想の要約であり、あなたのワークロードでの優劣は計測で確かめてください。
4. pgvector の“スケール上限”は固定ではない
「pgvector は小規模専用」という思い込みは2026年では古いです。Postgresエコシステムの拡張で上限は押し上げられます。
pgvectorscale（Timescale / TigerData）
素の pgvector に、次を追加します（PostgreSQLライセンスのOSS）。
- StreamingDiskANN インデックス：Microsoft の DiskANN 由来。インデックスの一部をディスクに置くため、HNSWの全in-memoryよりもベクトル数の増加に対してコスト効率よくスケールします。
- ラベルベース / ストリーミングのフィルタ検索：「絞ったら結果が足りない」を避ける、十分な件数が揃うまで取得を続けるフィルタリング。
- Statistical Binary Quantization：標準BQの改良版。
性能はベンダー主張として読む：Timescale は「5,000万件のCohere埋め込み・再現率99%で、Pinecone の storage最適化(s1)比 p95レイテンシ28分の1・スループット16倍・コスト75%減（自己ホストEC2）」等を公表していますが、これは自社条件・単一データセットの第一者比較です。**「Timescaleはこう報告している」**という形でのみ受け取り、必ず自分のデータで検証してください。
VectorChord ほか
VectorChord（TensorChord、pgvecto.rsの後継）は IVF + RaBitQ量子化で「ディスク親和・低コストな大規模」を狙う Postgres拡張です。「pgvector比100倍速いインデックス構築」等の主張がありますが、これもベンダー主張として扱います。
要点：pgvector を選ぶ判断は「将来も小規模に縛られる」ことを意味しません。まず素の pgvector → 規模が来たら pgvectorscale / VectorChord へ、Postgresの中のまま移行できる——これがスケール面の安心材料です。
5. 正直に：pgvector が「向かない」ケース
私は pgvector への集約を多くの案件で推しますが、万能ではありません。次のときは専用DBを正面から検討します。
- 数億〜数十億ベクトル × サブミリ秒SLA × 高並列：水平シャーディングが第一級機能の Milvus（分散）/ Pinecone（serverless） の土俵。
- GPU推論や特殊インデックス（PQ/SCANN/DiskANNの作り込み）が必須：Milvus のインデックスの幅が効く。
- そもそも Postgres を運用していない：集約のメリット（運用一本化）が出ない。ベクトルのためだけに Postgres を増やすのは本末転倒で、その場合は Qdrant（OSS・フィルタ強）や Pinecone（ゼロ運用）の方が素直。
- 高カーディナリティの複雑フィルタが性能の中心：Qdrant か pgvectorscale を重く見る。
技術選定で最も誠実なのは、「自分のプロダクトが向かう先」を直視することです。来ない数十億のために今2つのデータストアへ割るのも、明らかに来る大規模を見ないふりするのも、どちらも失敗します。
6. まとめ：選定チートシート
- 問いの立て方：「最強はどれ」ではなく「自分の制約にどれが合うか」。軸は運用負荷・整合性・スケール上限・レイテンシ・フィルタ・コスト・ロックイン。
- 既に Postgres ＋ 数千万行まで ＋ 整合性重視 → pgvector（インフラ追加ゼロ・同一トランザクション）。大多数のB2B SaaSはここ。
- 数億〜数十億 ＋ 高並列SLA ＋ GPU/特殊index → Milvus / Pinecone。
- フィルタ検索が主役・OSS志向 → Qdrant。統合AIネイティブDB → Weaviate。PoC最速 → Chroma。
- pgvector のスケール は pgvectorscale（StreamingDiskANN） で押し上げ可能。性能数値はベンダー主張＝自分のデータで計測。
- ロックイン：Pinecone（proprietary）が最大、OSS各種は出口コスト低。初日に評価。
私は 生成AI音声チャットボット で、専用ベクトルDBを増設せず PostgreSQL + pgvector に業務データと埋め込みを集約する判断を採りました。商材ドキュメント（PDF/Excel/画像/動画）の意味検索を、業務データと同じDBの同じトランザクションで扱える運用の単純さを最優先したからです。一方で、もし要件が数十億ベクトルや独立した低レイテンシSLAだったなら、迷わず専用DBを提案します——選定は要件次第だからです。
「pgvector で十分なのか、専用ベクトルDBを入れるべきか」——この最初の一手を、あなたの規模・整合性要件・予算・チーム体制から一緒に見極めます。 要件整理の段階からでも、お気軽にご相談ください。実装に入るなら、まずは pgvector の始め方、本格RAGなら 本番RAG設計、速度・コスト最適化は チューニング完全ガイド へ。
参考（公式・一次情報）
- pgvector（GitHub）（PostgreSQL License・HNSW/IVFFlat） ／ pgvectorscale（Timescale）（StreamingDiskANN・ラベルフィルタ／性能はベンダー主張）
- Pinecone ／ Qdrant（GitHub・Apache 2.0） ／ Weaviate（GitHub・BSD-3） ／ Milvus（GitHub・Apache 2.0） ／ Chroma（GitHub・Apache 2.0）
- 性能・コストの比較主張は各ベンダー公表値（例：Timescale の pgvector vs Pinecone 記事）に基づき、中立ベンチマークではない点に留意してください。