# pgvector vs 専用ベクトルDB（Pinecone / Qdrant / Weaviate / Milvus）徹底比較と技術選定ガイド > ベクトル検索基盤をどれにするか——pgvector（PostgreSQL拡張）と専用ベクトルDB（Pinecone・Qdrant・Weaviate・Milvus・Chroma）を、運用負荷・トランザクション整合性・スケール上限・レイテンシ・メタデータフィルタ・コスト・ロックインの7軸で比較。pgvectorscale（StreamingDiskANN）によるスケール戦略も含め、発注者・アーキテクトの意思決定を支える技術選定ガイドです。 - 公開日: 2026-06-26 - 著者: 友田 陽大 - タグ: PostgreSQL, RAG, Pinecone, アーキテクチャ設計, コスト最適化 - URL: https://tomodahinata.com/blog/pgvector-vs-pinecone-qdrant-weaviate-milvus-vector-database-comparison-guide ## 要点 - 問いは『どれが最強か』ではなく『自分の制約にどれが合うか』。判断軸は運用負荷・業務データとの整合性・スケール上限・レイテンシSLA・フィルタ・コスト・ロックインの7つ - 既にPostgresを運用し、ベクトルが数百万〜数千万行で、埋め込みと業務データの整合性が重要なら、まず pgvector が最有力。新しいインフラを1つも増やさない - 数億〜数十億ベクトル、高並列での厳しいレイテンシSLA、GPU/特殊インデックスが要るなら専用DB（Milvus/Pinecone）が優位。Qdrantはフィルタ検索に強いOSSの中間解 - pgvector のスケール上限は pgvectorscale（StreamingDiskANN・ディスク常駐）で押し上げられる。性能の数値はすべてベンダー主張として扱い、自分のデータで計測する - Pinecone はゼロ運用だが proprietary でロックインが最大。OSS（Qdrant/Milvus/Weaviate/Chroma/pgvector）は出口コストが低い。ロックインは初日に評価する --- RAGや意味検索を始めるとき、最初に来る大きな技術選定が **「ベクトル検索基盤をどれにするか」** です。`pgvector`（PostgreSQLの拡張）で済ませるのか、Pinecone・Qdrant・Weaviate・Milvus のような**専用ベクトルDB**を導入するのか。 この記事は、その判断を**感覚ではなく軸で**下すための技術選定ガイドです。先に結論を言えば——**「どれが最強か」という問いは存在しません。** あるのは「**あなたの制約（規模・整合性要件・運用体制・予算）に、どれが合うか**」だけです。本稿は、発注者・アーキテクトがこの意思決定を後悔なく下せるよう、各製品の特性と判断軸を、公式情報に基づいて整理します。 > **この記事のルール**：pgvector の仕様は **公式ドキュメント**に基づきます。各専用DBの特性は**各社公式**に基づきますが、**性能（QPS・レイテンシ・コスト）の数値はすべて「ベンダーの主張」**として扱い、中立なベンチマークとしては提示しません（性能はデータ・次元・再現率目標・ハードで激変するため）。製品仕様は更新が速いので、**導入前に必ず最新の公式情報で要確認**してください。 --- ## 1. 結論を先に：判断フローチャート 細かい比較に入る前に、**8割の案件はこの数問で決まります**。 ```text 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音声チャットボット](/case-studies/ai-voice-chatbot) で、**専用ベクトルDBを増設せず PostgreSQL + pgvector に業務データと埋め込みを集約**する判断を採りました。商材ドキュメント（PDF/Excel/画像/動画）の意味検索を、業務データと**同じDBの同じトランザクション**で扱える運用の単純さを最優先したからです。一方で、もし要件が数十億ベクトルや独立した低レイテンシSLAだったなら、迷わず専用DBを提案します——**選定は要件次第**だからです。 **「pgvector で十分なのか、専用ベクトルDBを入れるべきか」——この最初の一手を、あなたの規模・整合性要件・予算・チーム体制から一緒に見極めます。** 要件整理の段階からでも、お気軽にご相談ください。実装に入るなら、まずは [pgvector の始め方](/blog/pgvector-getting-started-installation-docker-supabase-rds-neon-guide)、本格RAGなら [本番RAG設計](/blog/pgvector-postgres-production-rag-hybrid-search)、速度・コスト最適化は [チューニング完全ガイド](/blog/pgvector-index-tuning-hnsw-ivfflat-quantization-iterative-scan-guide) へ。 --- ### 参考（公式・一次情報） - [pgvector（GitHub）](https://github.com/pgvector/pgvector)（PostgreSQL License・HNSW/IVFFlat） ／ [pgvectorscale（Timescale）](https://github.com/timescale/pgvectorscale)（StreamingDiskANN・ラベルフィルタ／性能はベンダー主張） - [Pinecone](https://www.pinecone.io/) ／ [Qdrant（GitHub・Apache 2.0）](https://github.com/qdrant/qdrant) ／ [Weaviate（GitHub・BSD-3）](https://github.com/weaviate/weaviate) ／ [Milvus（GitHub・Apache 2.0）](https://github.com/milvus-io/milvus) ／ [Chroma（GitHub・Apache 2.0）](https://github.com/chroma-core/chroma) - 性能・コストの比較主張は各ベンダー公表値（例：[Timescale の pgvector vs Pinecone 記事](https://www.tigerdata.com/blog/pgvector-vs-pinecone)）に基づき、**中立ベンチマークではない**点に留意してください。