pgvector vs Qdrant vs Chroma：ベクターDB選定の判断基準と用途別推奨
結論: 既存PostgreSQL環境があるならpgvector / メタデータフィルタを組み合わせた本番RAGならQdrant / 今日から試すプロトタイプならChroma。3つは競合でなく、使うフェーズと要件が違う。
社内RAGのプロトタイプはChromaで動いている。でも本番に上げる前に「このまま使い続けていいのか」という疑問が出てくる。pgvectorで十分なら別途DBを立てるコストが省ける。Qdrantは高機能そうだが、過剰投資になるのも避けたい。
この3択で止まっているなら、判断軸が整理されていないことが原因です。スペックを並べるだけでは選べません。「自分のケースでどれが適切か」を判定できる軸が必要です。
インフラ統合コスト・フィルタ精度・スケール上限・プロトタイプ速度の4軸で各ツールの位置づけを比較する。
3つのベクターDBの位置づけを最初に整理する
pgvector・Qdrant・Chromaは、それぞれ設計の出発点が異なります。
- pgvector: PostgreSQLの拡張機能。既存のRDBMS環境にベクター検索を追加する。
- Qdrant: ベクター検索専用に設計されたスタンドアロンDB。フィルタ付き検索と分散構成を中心に設計されている。
- Chroma: Python/JavaScript向けの組み込み型ベクターDB。プロトタイピングを最優先に設計されている。
3つを同一の基準で比べようとすると選べなくなります。「何を解決したいか」から入ることが出発点です。
簡易比較
| 軸 | pgvector | Qdrant | Chroma |
|---|---|---|---|
| 導入形態 | PostgreSQL拡張 | 独立サーバー | ライブラリ / サーバー |
| フィルタ付き検索 | 可 (post-filtering) | ネイティブ対応 | 可 (限定的) |
| 水平スケール | 非ネイティブ | ネイティブ対応 | 非対応 (シングルノード) |
| 最大ベクター次元 | halfvec: 4000次元 | — | — |
| ライセンス | PostgreSQL License | Apache 2.0 | Apache 2.0 |
判断軸1 — 既存インフラとの統合コスト
「別途ベクターDBサーバーを立てるコスト」を払えるかどうかが、最初の分岐点です。
PostgreSQLをすでに運用しているなら、pgvector (GitHub) は CREATE EXTENSION vector; の1行で有効化できます。PostgreSQL 13以上に対応しており、現行リリースは pgvector（GitHub） で確認できる（2026年7月時点 v0.8.3）。
pgvectorを選ぶ最大のメリットは、既存のACIDトランザクション・PITR・JOINをそのまま使えることです。ベクター検索と通常のSQL検索を同一クエリ内で組み合わせられるため、既存スキーマへの追加コストが最小になります。
ただし、水平スケール (シャーディング) はネイティブではサポートされていません。Citus や PgDog を使えば水平スケールは可能ですが、その分の追加学習コストが発生します。この点は後述します。
pgvectorのインデックス選択 — HNSWかIVFFlatか
pgvector が提供するインデックスは2種類で、用途によって選び方が変わります。
HNSW (Hierarchical Navigable Small World)
クエリ速度優先の場合はHNSWを選びます。pgvector (GitHub) のREADMEに記載されているデフォルト値は以下です。
m = 16(各ノードが持つ接続数の上限)ef_construction = 64(インデックス構築時の候補リストサイズ)ef_search = 40(検索時の動的候補リストサイズ)
ef_search を大きくするほどリコールが上がりますが、クエリ速度は下がります。精度と速度のトレードオフを自分の要件で決める必要があります。
IVFFlat (Inverted File with Flat quantization)
構築速度優先の場合はIVFFlatが適しています。lists パラメータの推奨値は、pgvector (GitHub) のREADMEに明示されています。
- 100万行以下:
rows / 1000 - 100万行超:
sqrt(rows)
IVFFlatはHNSWより構築が速いですが、クエリ精度ではHNSWが優位です。データ量が少なくインデックス構築を頻繁に行う場合はIVFFlat、クエリ精度を重視する本番環境ではHNSWが基本的な選択肢になります。
判断軸2 — フィルタ付きベクター検索の精度
「ユーザーの部署に属するドキュメントのみ」「特定の日付範囲のみ」など、メタデータによる絞り込みを組み合わせた検索が必要なら、ここが最大の判断軸になります。
post-filteringの問題
pgvectorでフィルタ付き検索を行う場合、典型的な実装では次の順序になります。
- ベクター空間で上位K件を取得する
- 取得したK件にSQLのWHERE句でフィルタをかける
この「検索してからフィルタ」の構造をpost-filteringと呼びます。フィルタ条件が厳しくなるほど、上位K件の中にフィルタを通過するドキュメントがなくなるリスクが上がります。結果として「マッチはあるはずなのに0件が返る」という問題が起きえます。
QdrantのHNSW + ペイロードインデックス
Qdrant公式ドキュメント によると、QdrantはベクターインデックスとメタデータインデックスをHNSW構造内で統合して単一パスで処理します。Qdrantのインデックスドキュメント には次の記述があります。
A key feature of Qdrant is the effective combination of vector and traditional indexes… a vector index speeds up vector search, and payload indexes speed up filtering.
ペイロードインデックス (メタデータインデックス) と ベクターインデックスが連動するため、フィルタ条件が厳しくても精度が劣化しにくい構造です。
重要な点として、同ドキュメントには「Payload indexes should be created before ingesting data.」と明記されています。フィルタに使うフィールドのインデックスはデータ投入前に定義しておく必要があります。後から追加することは技術的には可能ですが、既存データに対してインデックスを後付けする場合の挙動は事前に確認してください。
マルチテナント設計については、Qdrantのコレクションドキュメント に推奨アプローチが記載されています。
In most cases, you should only use a single collection with payload-based partitioning. This approach is called multitenancy.
テナントごとにコレクションを分けるのではなく、1コレクション + ペイロードフィールドで分離する設計が公式の推奨です。
判断軸3 — メモリとスケールの上限
pgvectorのスケール戦略
pgvectorはv0.8.3時点で halfvec 型をサポートしており、ベクターを半精度浮動小数点 (16bit) で格納できます。最大次元数は halfvec で4000次元（通常の vector 型は2000次元）です（pgvector GitHub）。
半精度化によりストレージとメモリフットプリントを削減できます。さらに pgvector (GitHub) はバイナリ量子化もサポートしており、精度を許容範囲で犠牲にする代わりにスペースを大幅に削減できます。
水平スケールが必要になった場合の選択肢は Citus または PgDog になりますが、どちらも PostgreSQL エコシステムの追加ツールであり、導入・運用コストが上乗せされます。pgvectorを選んだ後に水平スケールが必要になったとき、この移行コストは事前に見積もっておくべき項目です。
Qdrantの量子化とシャーディング
Qdrant量子化ドキュメント によると、Qdrantは4種類の量子化をサポートしています。
| 量子化方式 | 圧縮率 |
|---|---|
| TurboQuant | 最大32x |
| Scalar Quantization | 4x |
| Binary Quantization | 最大32x |
| Product Quantization | 最大64x |
圧縮率はトレードオフを伴います。圧縮率が高いほどメモリ消費は下がりますが、リコール精度への影響を自分のデータで検証する必要があります。
分散デプロイについては、Qdrant分散デプロイドキュメント に次の記述があります。
Since version v0.8.0 Qdrant supports a distributed deployment mode. … To enable distributed deployment - enable the cluster mode …
QDRANT__CLUSTER__ENABLED=true
環境変数1つでクラスターモードを有効化できます。シャーディングとレプリカ設定は有効化後にコレクション単位で設定します。
判断軸4 — 「今日から動かせるか」= Chromaの使いどころ
Chroma公式ドキュメント によると、Chromaは Apache 2.0 ライセンスで提供されており、ローカル・セルフホスト・Chroma Cloud (マネージド) の3形態で動作します。
即起動の速さ
Chroma クライアントドキュメント に記載のDockerコマンドは以下です。
docker pull chromadb/chroma
docker run -p 8000:8000 chromadb/chromaPython パッケージ chromadb をインストールすれば、インプロセスで即起動することも可能です。プロトタイプのサイクルを速く回す局面では、この速さが最大の強みです。
HNSWのデフォルト値
Chroma コレクション設定ドキュメント によると、シングルノードChromaのHNSWデフォルト値は以下です。
ef_construction = 100ef_search = 100max_neighbors = 16(M パラメータ相当)
同ドキュメントに「In Distributed Chroma and Chroma Cloud collections, we use a SPANN index」と記載されており、分散構成では SPANN インデックスに切り替わります。ただし「We currently don’t allow customization or modification of SPANN configuration.」とあり、SPANNの設定カスタマイズは現時点で非対応です。
シングルノードの上限について
シングルノードChromaが何ベクターまで安定して動作するかについて、公式ドキュメントに明示された数値はありません。本番規模のデータを扱う場合は、自分のデータ量でベンチマークを取るか、Chroma Cloudへの移行またはQdrant/pgvectorへの切り替えを前提として設計しておくことを推奨します。
各種ベクターDBのベンチマーク比較は ANN Benchmarks が参考になりますが、QPS・Recallの具体的な数値は構成・ハードウェア・データセットに強く依存するため、公式グラフを自分のユースケースで読み取ることが必要です。
用途別推奨まとめ — 3つのシナリオで選ぶ
シナリオA: 既存PostgreSQL環境で社内RAGを追加したい
推奨: pgvector
CREATE EXTENSION vector; の1行から始められます。既存のバックアップ・ユーザー管理・JOINをそのまま活用でき、新しいインフラを増やさずに済みます。フィルタ件数が限定的で、スケールがシングルノードPostgreSQLの範囲に収まるなら、pgvectorが最もコストパフォーマンスに優れた選択です。
シナリオB: 部署・プロジェクト単位のフィルタ付き検索が必須の本番RAG
推奨: Qdrant
マルチテナント設計 (1コレクション + ペイロード分離) でフィルタ付き検索の精度を確保しつつ、将来の水平スケールも1設定で対応できます。フィルタに使うフィールドのペイロードインデックスはデータ投入前に定義することを忘れないでください。
シナリオC: 今週中に動かして検証したい
推奨: Chroma
pip または Dockerで即起動でき、プロトタイプの反復速度が最速です。ただし本番移行のタイミングでpgvectorまたはQdrantへの切り替えを前提として設計しておくと、後の手戻りを最小化できます。
比較表 (確認済み数値のみ)
| pgvector | Qdrant | Chroma | |
|---|---|---|---|
| PostgreSQL統合 | ネイティブ | 別サーバー | 別プロセス |
| 最大次元数 | 2000 (vector) / 4000 (halfvec) | — | — |
| フィルタ付き検索 | post-filtering | 単一パス | 限定的 |
| 水平スケール | 非ネイティブ (Citus等) | QDRANT__CLUSTER__ENABLED=true | 非対応 |
| HNSWデフォルト (m / ef_c / ef_s) | 16 / 64 / 40 | — | 16 / 100 / 100 |
| ライセンス | PostgreSQL License | Apache 2.0 | Apache 2.0 |
Weaviate（マネージド型ベクターDBの代表例）・Pinecone（クラウドネイティブなベクターDB）との比較は別記事で扱う。ANN Benchmarks にはpgvector・Qdrant・Weaviateが掲載されており、複数DBのベンチマーク比較の入口として活用できます。
RAGシステムの構築から精度チューニングまで、お問い合わせはこちら → [email protected]
よくある質問
Q. ChromaからQdrantへの移行は大変ですか?
データ移行自体はベクターとメタデータをエクスポートしてQdrantへインポートする手順になります。コレクション設計 (特にペイロードインデックスの定義) を最初から意識した設計にしておくと、移行コストを下げられます。
Q. pgvectorはOpenAI Embeddings (1536次元) に対応できますか?
対応しています。vector 型の上限が2000次元であるため、1536次元は範囲内です。text-embedding-3-large の3072次元を使う場合は halfvec 型 (上限4000次元) への切り替えが必要です。
Q. QdrantのペイロードインデックスをデータINSERT後に追加できますか?
Qdrantインデックスドキュメント ではデータ投入前の定義を推奨しています。後から追加する場合の挙動は公式ドキュメントを確認し、既存データへの再インデックスが発生するかどうかを事前に把握してください。
Q. ChromaのHNSWパラメータはどこで変更できますか?
Chroma コレクション設定ドキュメント にコレクション作成時のパラメータ指定方法が記載されています。ただし分散構成 (Chroma Cloud含む) では SPANN インデックスに切り替わり、現時点ではカスタマイズ非対応です。
Q. Qdrantの量子化はどれを選べばいいですか?
Qdrant量子化ドキュメント に4方式の使い分けが記載されています。リコール精度への影響は使用するEmbeddingモデルとデータセットに依存するため、自分のデータで検証した上で選択することを推奨します。Binary Quantizationは最大32x圧縮ですが、精度劣化の許容範囲を確認してから本番適用してください。