ベクトルデータベースの選び方｜pgvector・Qdrant・Milvus・Weaviate・Chromaを用途と規模と運用体制で決める

RAGを作りはじめると、わりと早い段階で「ベクトルデータベースは何を使うか」という問いにぶつかります。ところがこの問いは、比較記事を読んでも決着しません。ベンチマークの順位は条件でひっくり返りますし、各製品はバージョンごとに機能を足し合っていて、「どれが速いか」は数か月で意味を失うからです。決められるのは、自分たちのデータ量・更新の仕方・フィルタ条件・運用できる人数といった前提のほうです。この記事では、製品の優劣を断定するのではなく、どんな条件ならどの選択肢が向くのかを、判断軸の側から整理します。

そもそもベクトルDBは必要か#

いきなり水を差すようですが、最初に確認したいのは「本当に専用のベクトルデータベースが要るのか」です。

ベクトル検索の中身は、クエリの埋め込みベクトルと文書側のベクトルの距離を比べて近い順に並べる処理です。件数が少なければ、全件と距離を計算する総当たり(ブルートフォース、全件走査)でも十分に速く、しかも結果は常に正確です。近似最近傍(ANN)インデックスは、件数が増えて総当たりが間に合わなくなったときに、正確さを少し犠牲にして速度を買う仕組みにすぎません。

このことは各製品のドキュメントにも表れています。Weaviateはベクトルインデックスとしてhnswのほかにflat(総当たり)を用意し、小規模なコレクション向けと位置づけています。Milvusも、極めて高い再現率が要る場合やフィルタで大半が絞り込まれる場合には、総当たり(Brute-Force)のFLATが選択肢になると説明しています。pgvectorもインデックスを作らなければ厳密な検索になり、近似インデックスを足した瞬間に「結果が変わりうる」と明記されています。

もう一つ確認したいのが、そもそもベクトル検索が要る問題なのかです。検索対象が型番・エラーコード・社内の固有名詞のように字面の一致が支配的なら、既存の全文検索(BM25など)のほうが素直に当たります。ベクトル検索は言い換えや意味の近さに強い代わりに、完全一致は苦手です。既存の検索基盤で拾えている問い合わせを、わざわざベクトルに置き換えて精度を落とす、という事故は実際に起こります。

選定の6つの判断軸#

ベクトルDBを入れると決めたら、次は軸を先に決めます。以下の6つが揃えば、候補はかなり絞れます。

1. データ規模と成長見込み#

現在のチャンク件数と、1年後の見込みを出します。数万件と数億件では設計が別物です。数億件規模になると、メモリに載せきれるか、ディスク上のインデックスに逃がすか、シャーディングして分散させるかという話になり、Milvusのように単一マシン構成(Standalone)とKubernetes上の分散構成(Distributed)を選べるものや、DiskANNのようなオンディスクインデックスを持つものが視野に入ります。逆に数万件で分散構成を選ぶのは、ほぼ確実に過剰です。

2. 更新頻度と再構築のしやすさ#

日次バッチで洗い替えるのか、ドキュメントが更新されるたびに逐次で入れ替えるのか、削除はあるのかを整理します。近似インデックスは追記や削除のたびに構造を保守する必要があるため、更新が激しいワークロードではインデックス構築コストと検索性能の両方に効いてきます。pgvectorのドキュメントも、HNSWインデックスは「グラフがmaintenance_work_memに収まると大幅に速く構築できる」と述べており、構築はメモリ依存の重い処理です。

3. メタデータフィルタ付き検索#

実務のRAGでは、「このテナントの」「この部署が閲覧可能な」「2025年以降の」といった条件を付けた検索が必ず出てきます。ここが選定でいちばん差の出るところです。近似インデックスとフィルタの組み合わせは素直ではなく、各製品がそれぞれ違う解き方をしています。

• Qdrantは、ペイロード(メタデータ)のインデックスを作り、その値に基づく追加のエッジをHNSWグラフに張ることで、グラフを辿りながらフィルタを適用する方式を採っています。ドキュメントには「ペイロードインデックスとベクトルインデックスは別々では、フィルタ付き検索の課題を完全には解決できない」と明記されています。
• Elasticsearchは、近似kNNでプレフィルタを適用し、k件の結果が返ることを担保する設計を説明しています。
• pgvectorは、フィルタ列への通常のインデックス、部分インデックス、パーティショニング、そして必要な件数が集まるまでインデックスを追加で走査するiterative index scans(pgvector 0.8.0以降で利用できます)という複数の手段を提示しています。

つまり「フィルタが効くか」ではなく「フィルタを付けたときに、必要な件数が必要な速度で返るか」を測るべきだ、ということです。

4. ハイブリッド検索の要否#

キーワード検索とベクトル検索を組み合わせるハイブリッド検索を最初から使う予定があるなら、それが単体で完結するかどうかは大きな分かれ目です。Weaviateは転置インデックスを併せ持ちBM25とハイブリッドが標準機能、Qdrantは疎ベクトルとQuery APIのprefetch+融合(RRF/DBSF)、Milvusは複数ベクトルフィールドに対するハイブリッド検索とRRF/重み付きのリランカー、Elasticsearch/OpenSearchは全文検索エンジンにベクトル検索を統合しており、Elasticsearchは近似kNNと通常のクエリを組み合わせるハイブリッド検索を公式ドキュメントで説明しています(ただしElasticsearchは購読階層によって使える機能の範囲が変わるため、RRFなど個別機能の提供条件は導入前に確認してください)。Pineconeも疎ベクトルや全文検索フィールドを同じインデックスに持てます。pgvectorも「PostgreSQLの全文検索と組み合わせてハイブリッド検索に使える」とドキュメントに書かれていますが、融合処理は自分で書くことになります。

5. 運用体制#

見落とされがちですが、実は決定打になりやすい軸です。専用DBを1つ増やすということは、バックアップ・監視・バージョンアップ・障害対応の対象が1つ増えるということです。担当が1人か2人のチームで、Kubernetes上の分散構成を選ぶ判断は、たいてい後で効いてきます。自前で運用したくないなら、Qdrant Cloud、Weaviate Cloud、Chroma Cloud、Zilliz Cloud、Pineconeのようなマネージド提供を前提に考えます。Pineconeは原則としてフルマネージドのサーバーレスですが、データ主権やネットワーク分離の要件がある場合に向けて、自社のクラウドアカウント(AWS/GCP/Azure)の専用VPC内でデータプレーンを動かすBYOC(Bring Your Own Cloud)が用意されています(本記事作成時点の公式ドキュメントでは公開プレビューという位置づけで、提供ステータスは時点によって変わります)。ただし制御プレーンはPinecone側が持つため、OSSを自前のサーバーに立てるセルフホストとは性格が異なります。

6. 移行のしやすさ#

最初の選択を間違える前提で設計します。データ本体(元テキストとメタデータ)を他所に保持していて、ベクトルはいつでも再生成できる状態なら、乗り換えは「再投入」で済みます。逆に、ベクトルDBだけが正となるデータを持ってしまうと、移行は一気に難しくなります。フィルタ構文やスコアリングは製品ごとに違うため、アプリ側は「検索して候補を返す」という薄いインターフェースで切っておくと、差し替えの傷が浅くなります。

インデックス方式の考え方(HNSW・IVF・全件走査)#

製品を見比べる前に、インデックス方式の性格を押さえておくと読み解きが速くなります。細かなパラメータや速度の順位はバージョンとデータ次第なので、ここでは概念だけ整理します。

• 全件走査(FLAT/flat/インデックスなし): 総当たりで距離を計算します。常に正確ですが、件数に比例して遅くなります。小規模データや、フィルタで候補が大幅に絞られる場合の選択肢です。
• HNSW(階層的な近傍グラフ): ベクトル同士を近傍でつないだ多層グラフを辿って探索します。検索が速い代わりに、構築が重くメモリも食います。pgvector、Qdrant、Weaviate、Milvus、Elasticsearch、OpenSearchと、いま主流の実装はおおむねこれを持っています。
• IVF(転置ファイル/クラスタ分割): ベクトルをクラスタに分け、近そうなクラスタだけを探します。構築が軽い代わりに、探索するクラスタ数の設定で再現率が変わります。pgvectorのIVFFlat、MilvusのIVF系、OpenSearchのIVFなどが該当します。
• オンディスク・量子化系: DiskANNのようにグラフをディスクに置く方式や、スカラー量子化・直積量子化でベクトルを圧縮する方式です。メモリ制約の中で大規模データを扱うための道具で、多くは再現率と引き換えになります。

主要な選択肢の性格づけ#

各プロダクトの位置づけを、公式ドキュメントの記述に沿って整理します。機能は各社が競って追加しているため、この表は「現時点の性格」であって固定的な優劣ではありません。導入前に必ず最新の公式ドキュメントで確認してください。

表の内容は各製品の公式ドキュメント(記事末尾の出典)に基づく2026年7月時点の整理です。バージョンにより挙動や対応状況は変わります。また、ここに挙げた以外にも選択肢は多数あり、網羅を意図したものではありません。ライセンス条件や商用利用の可否は版によって異なるため、採用前に必ず一次情報で確認してください。

pgvectorが第一候補になりやすい理由と、その限界#

RAGの相談を受けたとき、まず確認するのは「PostgreSQLはもう動いていますか」です。動いているなら、pgvectorから検討するのが素直だと考えています。理由は3つあります。

1つ目は、運用対象が増えないことです。バックアップも監視も権限管理も、既存のPostgreSQLの仕組みにそのまま乗ります。新しいミドルウェアを1つ増やすコストは、機能表には現れませんが確実に効いてきます。Amazon RDSをはじめ主要なマネージドPostgreSQLでも拡張として提供されているため、マネージド利用でも導入しやすい部類です。

2つ目は、トランザクションと結合が使えることです。本文・メタデータ・権限情報が同じDBにあるなら、「閲覧権限のある文書だけをベクトル検索する」といった要件を、JOINとWHEREで素直に書けます。アプリ側で2系統のストアを整合させるコードを書かずに済むのは、地味ですが大きな差です。

3つ目は、機能が意外と揃っていることです。HNSWとIVFFlatの両方、複数の距離関数、halfvecやsparsevecといった型、全文検索と組み合わせたハイブリッド、フィルタ用のiterative index scansまで、実務で必要になるものはひととおりあります。ただし、これらは拡張のバージョンに依存します。HNSWは0.5.0以降、halfvecやsparsevecは0.7.0以降、iterative index scansは0.8.0以降で追加された機能なので、マネージドPostgreSQLを使う場合は提供中のpgvectorのバージョンを先に確認してください。

一方で、限界も明確です。

• 次元数の制約: vector型自体は最大16,000次元まで扱えますが、近似インデックスを張れるのはvectorで2,000次元、halfvecで4,000次元までです。高次元の埋め込みをそのまま使う場合は、halfvecへの変換や次元削減が前提になります。READMEのFAQでは、これ以外の回避策としてバイナリ量子化(bit型で最大64,000次元)と、subvectorに対する式インデックスも挙げられています。
• スケールアウトの重さ: 分散前提で設計されたベクトルDBのように、シャーディングでノードを足していくアーキテクチャではありません。PostgreSQLとしてのスケール手段(リードレプリカ、パーティショニング等)の範囲で考える必要があります。
• 構築負荷が既存DBに乗る: HNSWインデックスの構築はメモリを要求する重い処理です。業務系のトランザクションが走っている本番DBで大量データのインデックスを構築すると、他の処理に影響します。インスタンス分離やメンテナンス時間の確保を計画に入れてください。
• ハイブリッドは自作: 全文検索と組み合わせられますが、2つのランキングの融合は自分で実装することになります。標準機能として持つ製品と比べると、書く量は増えます。

よくある4つの失敗#

先にDBを選んでしまう#

「RAGを作るのでベクトルDBを比較する」から始めると、要件が後追いになります。決めるべき順番は、検索対象のデータと件数 -> 必要なフィルタ条件 -> 精度と速度の目標 -> 運用体制 -> 製品、です。逆から始めると、選んだ製品の得意な形に要件を歪めることになります。

埋め込みモデル変更時の再構築コストを見落とす#

埋め込みモデルを差し替えると、既存のベクトルはすべて無効になります。全文書の再埋め込み(API利用ならその費用と時間)、インデックスの再構築、その間の切り替え方法が必要です。しかもモデルによって次元数が違えば、カラムやコレクションの定義まで変わります。モデルの更新は年単位で必ず来るイベントなので、「全件を再投入する手順」を最初に一度は通しておくことを勧めます。

フィルタ付き検索の性能を測っていない#

フィルタなしの検索速度だけを測って本番に出し、権限フィルタを付けた途端に遅くなる、あるいは十分な件数が返らない、というのは頻出のつまずきです。近似インデックスとフィルタの相互作用は製品ごとに実装が違うため、本番相当のデータ量と本番相当のフィルタ条件で測る以外に確かめる方法はありません。

評価セットが無い#

これがいちばん重い問題です。評価セット(質問と、正解として拾えてほしい文書の対応表)が無いまま製品を乗り換えると、「良くなった気がする」以上のことが言えません。ベクトルDBの選定は精度・レイテンシ・コストのトレードオフの話なので、比べる物差しが無ければそもそも判断が成立しません。

小さく始めて、必要になったら移行する#

現実的な進め方は、最初から最終形を当てにいかないことです。

この順番なら、最初の選択を間違えても損失は限定的です。逆に、評価セットを作らないまま高機能な製品を選ぶと、うまくいかないときに原因が検索器なのかチャンク分割なのか埋め込みなのかプロンプトなのか、切り分ける手段がありません。

よくある質問#

まとめ#

ベクトルデータベースの選定は、製品の比較表を眺めて決まる問題ではありません。決まるのは、自分たちのデータ件数と成長見込み、更新の仕方、どんなメタデータで絞り込むのか、ハイブリッド検索が要るのか、誰が運用するのか、そして間違えたときにどれだけ楽に乗り換えられるのか、という前提のほうです。

その前提から見ると、すでにPostgreSQLを運用しているチームにとってpgvectorが第一候補になりやすいのは、性能が突出しているからではなく、運用対象を増やさずに済み、フィルタや結合を既存のSQLの延長で書けるからです。同時に、近似インデックスの次元数上限や分散スケールの手段、インデックス構築負荷といった限界も明確なので、そこに当たったときに専用製品へ移す、という順序が組み立てられます。

そして何より、評価セットを先に作ることです。物差しが無ければ、どの製品を選んでも「良くなった気がする」以上のことは言えません。ベクトルDB選びは速さの競争ではなく、条件と制約の突き合わせです。小さく通して、測って、必要になったら動かす。この順番を守るだけで、選定にかける時間はずいぶん短くなります。