コラム / 技術選定 /
pgvector vs Pinecone vs Qdrant ─ 業務RAGで選ぶベクトルDBの実務基準
📖 約10分 / 公開日: 2026/05/18
## ベクトルDB選定でつまずく相談がこの半年で急増している
ベクトルDB選定で迷う相談が、ここ半年で目に見えて増えています。背景は単純で、社内ナレッジを RAG に乗せたい企業が増え、PoC は走ったが本番化すると遅い・高い・止まる、という三重苦に直面している現場が多いからです。
200万チャンクを超えるあたりから、選定の差が容赦なく顕在化します。当センターでは過去12ヶ月で pgvector、Pinecone、Qdrant のいずれも本番運用に乗せた案件をそれぞれ担当しており、その肌感をそのまま書きます。読み手を惑わせるための公平な並列比較ではなく、現場で判断した結果を率直に置きます。
## 結論を先に置く
500万チャンク以下、組織が既に Postgres を運用しているなら pgvector で十分です。AWS RDS の db.m6i.large（vCPU 2、メモリ 8GB）で月額 4万円台、HNSW を選び、m=16・ef_construction=64 を起点に調整すれば、p99 レイテンシは 200ms 前後に収まります。これより速い構成は他にあるが、業務RAG の体感としては差を感じない領域です。
ところが、フィルタ条件が多重に絡む業務用途、たとえば「部署=営業 AND 期間=2024Q4 AND 機密区分=社内のみ」が頻発する設計だと、pgvector の素直な実装は弱点を露呈します。ベクトル検索後にフィルタを適用するか、フィルタ後にベクトル検索をかけるかで挙動が大きく変わるためです。pre-filter を強制すると、対象セット縮小によって ANN インデックスの効きが落ち、リコールが下がる。post-filter にすると、上位 K を多めに取得してフィルタする必要があり、p99 が容易に倍化する。この問題に正面から対処したのが Qdrant です。
## Qdrant が「フィルタ可能 ANN」で勝つ場面
Qdrant は最初から「フィルタ可能 ANN」を前提に設計されており、ペイロードインデックスとベクトルインデックスを連動させた検索ができます。同じ 200万チャンク、10種類のフィルタを混在させた負荷試験で、Qdrant Cloud の Standard（4vCPU/16GB）で p99 が 180ms、同等の RDS で pgvector を回した場合 p99 が 420ms というのが直近の実測値です。月額は Qdrant Cloud が 8万円台、RDS が 4万円台。約2倍払って2倍以上速くなる、というシンプルなトレードオフ。フィルタが3つを超えるなら Qdrant に振るのが現場感覚です。
セルフホストの Qdrant も難しくありません。EKS / GKE に Helm chart で立てる構成で、ストレージ 200GB の構成なら月額 3.5万円程度に抑えられます。ただし、運用人員 0.2人分は最低でも必要です。バックアップ、アップグレード、HA 構成のメンテで時間を取られるので、人がいない組織は素直に Qdrant Cloud を契約したほうがいい。
## Pinecone は便利だが、跳ね方が急
Pinecone は s1.x1 から始めると月額 70 ドル前後で、3000万ベクトル規模でも p99 100ms を切るチューニングが可能です。SaaS としての完成度は3者の中で抜けており、ノードのスケーリング、レプリケーション、メタデータインデックスの自動チューニングは何もしなくて良い。手を出すべきポイントが本当に少ない。
ただし、200万チャンク・複数フィルタ・更新頻度高め、という業務RAG典型構成だと p2.x1 が必要になり、月額 18万円を超えるケースが普通です。Standard プランから Enterprise プランへの跳ね方も急で、SSO や VPC Peering を入れた瞬間に倍以上になる。中堅以上の企業で「コストはあとで考える」と契約すると、半年後に CFO から呼び出されます。
もうひとつ盲点があります。Pinecone は「ベクトルの delete が遅い」点。バッチ削除で 1万件を消すのに数十秒かかることがあり、社員退職時にその人がアップロードした全データを即座に消したい、という GDPR / 改正個人情報保護法対応の場面で詰まります。upsert は速いので、論理削除フラグでフィルタする運用に切り替えるのが現実解ですが、これはこれで毎クエリにフィルタ条件が増え、検索コストに跳ねる。設計時にこの制約を知らないまま機密データを載せると、後で構造ごと作り直す羽目になります。
## 運用工数の現実
pgvector の運用工数を軽く見る記事が多い。これは過小評価です。HNSW のインデックス再構築が必要になる場面 ─ たとえばチャンク戦略を変えて全件再エンベディングしたとき ─ で 200万件・1536次元の REINDEX に 4時間以上かかります。この間 INSERT を止めるか、新テーブルに書いてアトミックに切り替えるか、判断が必要です。判断を誤ると本番が数時間止まります。
Qdrant は collection を別名で作って alias を切り替える運用が標準なので、ここは Qdrant のほうが楽。Pinecone は名前空間で論理的に分離して新旧を並走させる運用が定石で、これも楽ですが、新旧両方の write コストが二重にかかるため、移行期間中のコストは倍になる。3者とも一長一短ある領域です。
監視も意外と差が出ます。pgvector は Datadog の Postgres インテグレーションで EXPLAIN ANALYZE までフル可視化できますが、Pinecone と Qdrant Cloud は外部メトリクスエクスポートが弱く、レイテンシ分布を見るには独自にラッピング層でログを取るしかない。p99 が悪化したときの原因切り分けで、これは効いてくる。「なぜ遅いか分からない」状態を許容できる組織は少ないので、可観測性が要件の上位にあるなら pgvector が有利です。
## 結局どれを選ぶか
業務システムで既に Postgres を運用しており、500万チャンク以下、フィルタが3条件以内なら pgvector を勧めます。インフラが Postgres に統一されていることの運用上のメリットは過小評価されがち。バックアップ、レプリケーション、点検手順がすべて既存の運用に乗ります。
500万チャンクを超える、フィルタが多段になる、SLA で p99 200ms 以下を厳格に求められる ─ このどれかに該当するなら Qdrant を勧めます。OSS としてセルフホストもでき、Qdrant Cloud に逃がすこともできるという二択を持てるのは、ベンダーロックインを嫌う企業にとって大きな意味があります。
Pinecone は「とにかく動かせ、運用工数はゼロにしろ、コストは二の次」という要件のスタートアップ向け。中堅以上の企業で月額 18万円を超えてくるなら、Qdrant Cloud に切り替えて運用人員を 0.3人分追加するほうが、3年で見ると安く済みます。「Pinecone を勧めない」と言いきってしまうのは乱暴ですが、業務RAG の本番運用において、コストと運用工数のバランスで Pinecone が最適解になるケースは限定的、というのが直近 18ヶ月の肌感です。
## 移行の罠
最後に、3者間の移行で何度も詰まったポイントを置いておきます。移行プロジェクトの見積もりでここを甘く見ると、初日でスケジュールが破綻する話です。
pgvector → Qdrant は HNSW パラメータ（m、ef_construct）を素直に移植できます。が、距離関数の指定が cosine / dot / euclidean で微妙に内部実装が異なり、同一エンベディングでも検索結果が変わります。本番切り替え前に、回帰テスト用の質問 100 問でリコール差分を取ることを強く推奨します。差分が出る前提で組まないと、切り替え当日に「精度が落ちた」と言われて慌てます。
Pinecone → 他系の移行は、Pinecone がベクトルのエクスポートに API レート制限を厳しくかけているため、200万ベクトルの取り出しに丸一日かかることがあります。fetch エンドポイントは ID ベースで、ID リストを別途持っていないとフルダンプができない、という設計上の制約も効きます。移行プロジェクトを請けるときは、まずこのエクスポート時間を実測することから始めるべきです。
Qdrant → pgvector は逆に簡単で、snapshot 経由で SQL に流し込めます。ただし、pgvector には HNSW の動的 ef 調整がない（hnsw.ef_search はクエリごとに変えられるが、自動最適化はしない）ため、Qdrant で動的 ef を活用していた構成からは、リコール優先か速度優先かを事前に決めて固定値で運用する必要があります。
ベクトル DB は「動かすだけ」なら3者とも難しくありません。難しいのは、業務要件に合わせて費用・速度・運用工数を年単位で見積もり、3年後にどこに着地しているかを描く部分。ここで失敗すると、PoC は通ったのに本番で詰む、という典型パターンに陥ります。選定で迷っているなら、まず自社の chunk 数、フィルタ条件の数、許容 p99、運用人員の余力 ─ この4つを数値で書き出すところから始めてください。それで自然に答えは絞り込まれます。
ベクトルDB選定で迷う相談が、ここ半年で目に見えて増えています。背景は単純で、社内ナレッジを RAG に乗せたい企業が増え、PoC は走ったが本番化すると遅い・高い・止まる、という三重苦に直面している現場が多いからです。
200万チャンクを超えるあたりから、選定の差が容赦なく顕在化します。当センターでは過去12ヶ月で pgvector、Pinecone、Qdrant のいずれも本番運用に乗せた案件をそれぞれ担当しており、その肌感をそのまま書きます。読み手を惑わせるための公平な並列比較ではなく、現場で判断した結果を率直に置きます。
## 結論を先に置く
500万チャンク以下、組織が既に Postgres を運用しているなら pgvector で十分です。AWS RDS の db.m6i.large（vCPU 2、メモリ 8GB）で月額 4万円台、HNSW を選び、m=16・ef_construction=64 を起点に調整すれば、p99 レイテンシは 200ms 前後に収まります。これより速い構成は他にあるが、業務RAG の体感としては差を感じない領域です。
ところが、フィルタ条件が多重に絡む業務用途、たとえば「部署=営業 AND 期間=2024Q4 AND 機密区分=社内のみ」が頻発する設計だと、pgvector の素直な実装は弱点を露呈します。ベクトル検索後にフィルタを適用するか、フィルタ後にベクトル検索をかけるかで挙動が大きく変わるためです。pre-filter を強制すると、対象セット縮小によって ANN インデックスの効きが落ち、リコールが下がる。post-filter にすると、上位 K を多めに取得してフィルタする必要があり、p99 が容易に倍化する。この問題に正面から対処したのが Qdrant です。
## Qdrant が「フィルタ可能 ANN」で勝つ場面
Qdrant は最初から「フィルタ可能 ANN」を前提に設計されており、ペイロードインデックスとベクトルインデックスを連動させた検索ができます。同じ 200万チャンク、10種類のフィルタを混在させた負荷試験で、Qdrant Cloud の Standard（4vCPU/16GB）で p99 が 180ms、同等の RDS で pgvector を回した場合 p99 が 420ms というのが直近の実測値です。月額は Qdrant Cloud が 8万円台、RDS が 4万円台。約2倍払って2倍以上速くなる、というシンプルなトレードオフ。フィルタが3つを超えるなら Qdrant に振るのが現場感覚です。
セルフホストの Qdrant も難しくありません。EKS / GKE に Helm chart で立てる構成で、ストレージ 200GB の構成なら月額 3.5万円程度に抑えられます。ただし、運用人員 0.2人分は最低でも必要です。バックアップ、アップグレード、HA 構成のメンテで時間を取られるので、人がいない組織は素直に Qdrant Cloud を契約したほうがいい。
## Pinecone は便利だが、跳ね方が急
Pinecone は s1.x1 から始めると月額 70 ドル前後で、3000万ベクトル規模でも p99 100ms を切るチューニングが可能です。SaaS としての完成度は3者の中で抜けており、ノードのスケーリング、レプリケーション、メタデータインデックスの自動チューニングは何もしなくて良い。手を出すべきポイントが本当に少ない。
ただし、200万チャンク・複数フィルタ・更新頻度高め、という業務RAG典型構成だと p2.x1 が必要になり、月額 18万円を超えるケースが普通です。Standard プランから Enterprise プランへの跳ね方も急で、SSO や VPC Peering を入れた瞬間に倍以上になる。中堅以上の企業で「コストはあとで考える」と契約すると、半年後に CFO から呼び出されます。
もうひとつ盲点があります。Pinecone は「ベクトルの delete が遅い」点。バッチ削除で 1万件を消すのに数十秒かかることがあり、社員退職時にその人がアップロードした全データを即座に消したい、という GDPR / 改正個人情報保護法対応の場面で詰まります。upsert は速いので、論理削除フラグでフィルタする運用に切り替えるのが現実解ですが、これはこれで毎クエリにフィルタ条件が増え、検索コストに跳ねる。設計時にこの制約を知らないまま機密データを載せると、後で構造ごと作り直す羽目になります。
## 運用工数の現実
pgvector の運用工数を軽く見る記事が多い。これは過小評価です。HNSW のインデックス再構築が必要になる場面 ─ たとえばチャンク戦略を変えて全件再エンベディングしたとき ─ で 200万件・1536次元の REINDEX に 4時間以上かかります。この間 INSERT を止めるか、新テーブルに書いてアトミックに切り替えるか、判断が必要です。判断を誤ると本番が数時間止まります。
Qdrant は collection を別名で作って alias を切り替える運用が標準なので、ここは Qdrant のほうが楽。Pinecone は名前空間で論理的に分離して新旧を並走させる運用が定石で、これも楽ですが、新旧両方の write コストが二重にかかるため、移行期間中のコストは倍になる。3者とも一長一短ある領域です。
監視も意外と差が出ます。pgvector は Datadog の Postgres インテグレーションで EXPLAIN ANALYZE までフル可視化できますが、Pinecone と Qdrant Cloud は外部メトリクスエクスポートが弱く、レイテンシ分布を見るには独自にラッピング層でログを取るしかない。p99 が悪化したときの原因切り分けで、これは効いてくる。「なぜ遅いか分からない」状態を許容できる組織は少ないので、可観測性が要件の上位にあるなら pgvector が有利です。
## 結局どれを選ぶか
業務システムで既に Postgres を運用しており、500万チャンク以下、フィルタが3条件以内なら pgvector を勧めます。インフラが Postgres に統一されていることの運用上のメリットは過小評価されがち。バックアップ、レプリケーション、点検手順がすべて既存の運用に乗ります。
500万チャンクを超える、フィルタが多段になる、SLA で p99 200ms 以下を厳格に求められる ─ このどれかに該当するなら Qdrant を勧めます。OSS としてセルフホストもでき、Qdrant Cloud に逃がすこともできるという二択を持てるのは、ベンダーロックインを嫌う企業にとって大きな意味があります。
Pinecone は「とにかく動かせ、運用工数はゼロにしろ、コストは二の次」という要件のスタートアップ向け。中堅以上の企業で月額 18万円を超えてくるなら、Qdrant Cloud に切り替えて運用人員を 0.3人分追加するほうが、3年で見ると安く済みます。「Pinecone を勧めない」と言いきってしまうのは乱暴ですが、業務RAG の本番運用において、コストと運用工数のバランスで Pinecone が最適解になるケースは限定的、というのが直近 18ヶ月の肌感です。
## 移行の罠
最後に、3者間の移行で何度も詰まったポイントを置いておきます。移行プロジェクトの見積もりでここを甘く見ると、初日でスケジュールが破綻する話です。
pgvector → Qdrant は HNSW パラメータ（m、ef_construct）を素直に移植できます。が、距離関数の指定が cosine / dot / euclidean で微妙に内部実装が異なり、同一エンベディングでも検索結果が変わります。本番切り替え前に、回帰テスト用の質問 100 問でリコール差分を取ることを強く推奨します。差分が出る前提で組まないと、切り替え当日に「精度が落ちた」と言われて慌てます。
Pinecone → 他系の移行は、Pinecone がベクトルのエクスポートに API レート制限を厳しくかけているため、200万ベクトルの取り出しに丸一日かかることがあります。fetch エンドポイントは ID ベースで、ID リストを別途持っていないとフルダンプができない、という設計上の制約も効きます。移行プロジェクトを請けるときは、まずこのエクスポート時間を実測することから始めるべきです。
Qdrant → pgvector は逆に簡単で、snapshot 経由で SQL に流し込めます。ただし、pgvector には HNSW の動的 ef 調整がない（hnsw.ef_search はクエリごとに変えられるが、自動最適化はしない）ため、Qdrant で動的 ef を活用していた構成からは、リコール優先か速度優先かを事前に決めて固定値で運用する必要があります。
ベクトル DB は「動かすだけ」なら3者とも難しくありません。難しいのは、業務要件に合わせて費用・速度・運用工数を年単位で見積もり、3年後にどこに着地しているかを描く部分。ここで失敗すると、PoC は通ったのに本番で詰む、という典型パターンに陥ります。選定で迷っているなら、まず自社の chunk 数、フィルタ条件の数、許容 p99、運用人員の余力 ─ この4つを数値で書き出すところから始めてください。それで自然に答えは絞り込まれます。