背景
Topic Sentence: 多数あるベクトルデータベースについて、2025年現在での選択のための指針を示したいと思います。
Evidence / Data: ベクトルデータベースはRAGの隆盛に伴い新規参入も多く、群雄割拠の領域と化しています。
Reasoning: それだけに、ニーズに対し適切なベクトルデータベースを選ぶことが難しいと考えています。
Example: 既存のDBの追加機能や有名どころに飛びついて、後から方針転換を余儀なくされてしまうことは起こりがちです。
Wrap-up: そこで、この記事では間違いだらけのベクトルデータベース選びを防ぐために、情報の交通整理を行いたいと考えています。
対象読者
- RAGのためにベクトルデータベースを選びたい方
※この記事は生成AIを活用して記述しています。ファクトチェックは行っていますが、AI生成に嫌悪感のある方はご注意下さい。
ベクトルデータベース比較
| DB名 |
検索性能 |
スケーラビリティ |
インデックス更新 |
互換性 |
運用機能 |
パフォーマンス |
セキュリティ |
コスト |
コミュニティ |
| Weaviate |
高精度（HNSW）＋フィルタリング |
分散対応、クラウド/オンプレ両対応 |
リアルタイム更新可 |
LangChain, LlamaIndex等 |
マネージドサービスあり |
高速検索、メタデータフィルタも高速 |
RBAC, TLS, マルチテナント |
OSS＋クラウド課金 |
活発、ドキュメント充実 |
| Milvus |
高速ANN（RaBitQ, IVF, HNSW） |
数十億ベクトル対応、Zilliz Cloudあり |
高速インジェスト、削除・更新改善中 |
多数の埋め込みモデルと統合 |
Zilliz Cloudで運用簡易化 |
RaBitQで3倍高速化 |
エンタープライズ向けセキュリティ |
OSS＋Zilliz Cloud課金 |
活発 |
| Qdrant |
高精度＋BM25ハイブリッド |
単一ノードでも高性能、クラスタ構成も可能 |
高速更新、永続化あり |
LangChain, OpenAI等 |
軽量で自己ホストも容易 |
高QPS、低レイテンシ |
TLS, 認証あり |
OSS＋商用サポートあり |
活発 |
| Chroma |
軽量・高速（小規模向け） |
ローカル中心、スケールは限定的 |
シンプルなAPIで即時反映 |
Python中心、Dockerで簡単導入 |
ローカル運用が前提 |
小規模用途で高速 |
ローカル用途中心 |
完全OSS |
新興だが注目度高 |
| Elasticsearch |
ハイブリッド検索（BM25＋ベクトル） |
ELKスタックと統合、スケール容易 |
インデックス再構築が必要な場合あり |
Elastic Stackと統合 |
商用Elastic Cloudあり |
大規模データでも安定 |
Elastic Securityと統合 |
Elastic Cloudは従量課金 |
長年の実績 |
| PGvector |
HNSW対応、PostgreSQL統合 |
PostgreSQL依存、Aurora等でスケール可能 |
PostgreSQLのトランザクションに準拠 |
PostgreSQL拡張として利用可能 |
Aurora, Azure等でマネージド利用可 |
PostgreSQLの性能に依存 |
PostgreSQLのセキュリティ機能を継承 |
OSS＋クラウド課金 |
PostgreSQLコミュニティと連携 |
| OpenSearch |
高精度＋ハイブリッド検索、GPU対応 |
分散構成、GPUスケーリング |
リアルタイムインジェスト、GPU高速化 |
LangChain, LLM統合 |
OpenSearch Cloudあり |
9.5倍高速化（v3.0） |
AWS統合、RBAC, TLS |
OSS＋クラウド課金 |
AWS支援、活発 |
| Cassandra |
SAIベースのベクトル検索（v5.0） |
グローバル分散、スケール自在 |
SAIで高速インデックス |
LLM対応、SAIで柔軟な構造 |
OSS＋DataStaxなど商用支援あり |
高スループット、低レイテンシ |
エンタープライズ向けセキュリティ |
OSS＋DataStaxなど |
広範な導入実績 |
| Valkey |
高速（HNSW/FLAT両対応）、高QPS |
クラスタ構成対応、水平スケール可 |
マルチスレッドで高速更新 |
LangChain対応、Redis互換 |
Google Cloud Memorystore対応 |
単桁msレイテンシ、SIMD最適化 |
Google Cloud準拠、TLS対応 |
OSS＋Google Cloud課金 |
Redis系から派生、活発化中 |
| CockroachDB |
pgvector統合、類似度検索対応 |
水平スケーラブル、99.999% SLA |
PostgreSQL互換でトランザクション対応 |
pgvector互換、LLM対応 |
Cockroach Cloudあり |
高可用性＋高速検索 |
PCI/HIPAA準拠、RBAC |
OSS＋Cockroach Cloud課金 |
新興だが注目度上昇中 |
| MongoDB |
Atlas Vector Searchで高精度検索 |
Atlasクラウドでスケーラブル |
Atlasで自動インデックス |
LangChain, OpenAI等 |
Atlasでマネージド運用 |
高速検索＋全文検索統合 |
Atlasで包括的セキュリティ |
Atlas従量課金 |
MongoDBコミュニティ強力 |
| LanceDB |
高速ベクトル検索＋メタデータフィルタリング対応 |
ローカル中心だが、クラウド・分散構成も可能 |
非同期インデックス＋即時検索（フォールバックあり） |
Python, TypeScript対応 |
組み込み型で簡単導入、クラウド接続も可能 |
15Mベクトルで65ms以下の低レイテンシ検索 |
TLS対応、クラウド連携で強化可能 |
OSS＋クラウド課金モデル |
新興だが注目度上昇中 |
RAGに適したものはどれか
1. 小規模・ローカル開発用途
-
おすすめ: Chroma
-
理由:
- 軽量でセットアップが簡単
- ローカル環境で高速に動作
- Python中心の開発に最適
2. クラウド前提・マネージド運用
-
おすすめ: Weaviate (Cloud), Qdrant (Cloud), MongoDB Atlas, OpenSearch Cloud
-
理由:
- マネージドサービスでスケーラビリティと可用性が高い
- LangChainやOpenAIとの統合が容易
- セキュリティ・監視機能が充実
3. エンタープライズ・大規模RAG
-
おすすめ: Milvus, OpenSearch, Cassandra (5.0+)
-
理由:
- 数十億ベクトル規模の処理に対応
- 高スループット・低レイテンシ
- 分散構成・高可用性・セキュリティ機能が豊富
4. PostgreSQLベースの統合環境
-
おすすめ: PGvector, CockroachDB
-
理由:
- 既存のPostgreSQL環境に統合しやすい
- SQLベースで扱いやすく、トランザクション管理も可能
- pgvectorはLangChainなどでもサポート
5. リアルタイム・高速応答が必要なRAG
-
おすすめ: Qdrant, Valkey, Milvus
-
理由:
- 高速なインデックス更新と検索
- HNSWや量子化による高速化
- ValkeyはRedis互換で超低レイテンシ
6. セキュリティ・ガバナンス重視
-
おすすめ: MongoDB Atlas, CockroachDB, OpenSearch
-
理由:
- RBAC、TLS、監査ログなどのセキュリティ機能が充実
- クラウドでのコンプライアンス対応（PCI, HIPAAなど）
判断
我々のプロジェクトでも、RAGのためにベクトルデータベースを選ぶ必要に迫られていました。
以下の観点から、我々のプロジェクトに最適なベクトルデータベースを絞り込みました。
億単位の大規模なベクトル群を管理する必要は近い将来まだ存在しない
- 現状、先行テスト実装では一記事当たり60ベクトル程度
- 300記事程度存在します
- 概算で18000ベクトル程度
- データソースは2年で300記事まで成長しています
- 線形で成長したと仮定すると、1億ベクトルを超えるのは10000年程度かかります
- 億単位の大規模なベクトル群への対応は当面必要ありません
開発DBと本番DBを一種類で賄いたい
- 開発環境での導入が容易で、本番環境へのスムーズな移行が可能なDBが望ましいです。
ここまでの選別で、候補としてQdrant, PGvector, LanceDB, Chromaが残りました。上記観点での評価結果が以下です。
- Qdrant
- 小規模から始められ、クラスタ構成でスケールも可能
- 高速更新・永続化あり
- LangChainやOpenAIとの統合でLLM系にも強い
- 自己ホストもクラウドも対応可能で柔軟
- PGvector
- PostgreSQLベースで既存RDBとの統合が容易
- AuroraやAzureなどのマネージドサービスで本番運用も安心
- トランザクションやセキュリティもPostgreSQL準拠
- LanceDB
- 組み込み型でローカル開発が非常に簡単
- クラウド連携も可能で本番運用にも対応
- Python/TypeScript対応で開発者に扱いやすい
- Chroma
- 小規模用途に特化、導入が非常に簡単
- ローカル中心でPoCや軽量な本番運用に最適
- ただしスケーラビリティは限定的
追加で運用の容易さを計るための以下評価基準でさらに比較します。具体的な指標を用いて評価したかったので、環境依存の評価基準となっていますが、考え方自体は他の環境においても役に立つはずです。
| 評価基準の分類 |
評価項目 |
説明 |
| 導入の容易さ（Kubernetes環境を前提） |
Helmチャートの有無 |
Helmを使ってKubernetes上に簡単にデプロイできるか |
| 導入の容易さ（Kubernetes環境を前提） |
初期構成の柔軟性 |
環境変数や設定ファイルで構成を柔軟に変更できるか |
| 導入の容易さ（Kubernetes環境を前提） |
ストレージ対応 |
永続ボリューム（PVC）との統合がスムーズに行えるか |
| インデックス管理の自動化 |
自動インデックス作成 |
データ追加時に自動でインデックスが作成されるか |
| インデックス管理の自動化 |
非同期インデックス処理 |
インデックス作成がバックグラウンドで非同期に行われるか |
| インデックス管理の自動化 |
インデックスの即時反映 |
データ追加直後に検索可能な状態になるか（フォールバック含む） |
| 監視・可視化機能（Prometheus前提） |
Prometheusエクスポーターの有無 |
Prometheus形式でメトリクスを出力するエクスポーターがあるか |
| 監視・可視化機能（Prometheus前提） |
メトリクスの粒度 |
QPS、レイテンシ、エラー率などの詳細なメトリクスが取得できるか |
| 監視・可視化機能（Prometheus前提） |
ログの構造化 |
JSONなどの構造化形式でログが出力され、解析や可視化がしやすいか |
| バックアップとリカバリ（Velero前提） |
バックアップの整合性 |
データとインデックスの整合性を保った状態でバックアップできるか |
| バックアップとリカバリ（Velero前提） |
スナップショット対応 |
ストレージレベルでのスナップショット取得に対応しているか |
DBごとの評価表は以下です。
スコアについては以下のようにしました。
- 3 = 優れている
- 2 = 標準的
- 1 = 劣っている
Qdrant
| 評価項目 |
スコア |
理由 |
| Helmチャートの有無 |
3 |
公式でHelmチャートを提供しており、Kubernetes環境での導入が容易。 |
| 初期構成の柔軟性 |
3 |
環境変数や設定ファイルで細かく構成可能。 |
| ストレージ対応 |
3 |
永続ボリューム（PVC）との統合が公式にサポートされている。 |
| 自動インデックス作成 |
3 |
データ追加時に自動でインデックスが作成される。 |
| 非同期インデックス処理 |
3 |
インデックスは非同期で構築され、パフォーマンスに優れる。 |
| インデックスの即時反映 |
3 |
書き込み直後でも検索可能な設計。 |
| Prometheusエクスポーターの有無 |
3 |
公式でPrometheus対応のメトリクスエクスポーターを提供。 |
| メトリクスの粒度 |
3 |
QPS、レイテンシ、エラー率など詳細なメトリクスが取得可能。 |
| ログの構造化 |
3 |
JSON形式でのログ出力に対応。 |
| バックアップの整合性 |
3 |
永続化ストレージと整合性のあるバックアップが可能。 |
| スナップショット対応 |
3 |
PVCベースでVeleroによるスナップショット取得が容易。 |
PGvector
| 評価項目 |
スコア |
理由 |
| Helmチャートの有無 |
2 |
PostgreSQL用のHelmチャートは豊富だが、pgvector専用ではない。 |
| 初期構成の柔軟性 |
3 |
PostgreSQLの設定柔軟性が高く、pgvectorも同様に対応。 |
| ストレージ対応 |
3 |
永続ボリュームとの統合はPostgreSQLとして確立済み。 |
| 自動インデックス作成 |
2 |
明示的にインデックス作成が必要なケースが多い。 |
| 非同期インデックス処理 |
2 |
通常は同期処理。非同期処理は手動で設定が必要。 |
| インデックスの即時反映 |
2 |
トランザクション完了後に反映されるが、即時性は限定的。 |
| Prometheusエクスポーターの有無 |
2 |
PostgreSQL用のエクスポーターがあり、pgvectorにも利用可能。 |
| メトリクスの粒度 |
2 |
PostgreSQLのメトリクスは豊富だが、ベクトル検索に特化していない。 |
| ログの構造化 |
2 |
PostgreSQLのログは構造化可能だが、設定が必要。 |
| バックアップの整合性 |
3 |
PostgreSQLの整合性保証が強く、pgvectorも同様。 |
| スナップショット対応 |
3 |
PVCベースでVeleroと連携可能。 |
LanceDB
| 評価項目 |
スコア |
理由 |
| Helmチャートの有無 |
2 |
公式Helmチャートはないが、K8sマニフェストで導入可能。 |
| 初期構成の柔軟性 |
2 |
Python/TypeScriptベースで柔軟だが、K8s向け設定は限定的。 |
| ストレージ対応 |
2 |
Arrowベースのストレージで、PVC対応は構成次第。 |
| 自動インデックス作成 |
2 |
データ追加時に自動でインデックスが作成される。 |
| 非同期インデックス処理 |
2 |
非同期処理に対応しているが、設定に注意が必要。 |
| インデックスの即時反映 |
2 |
フォールバック検索で即時性を確保。 |
| Prometheusエクスポーターの有無 |
2 |
明示的なエクスポーターはないが、メトリクス出力は可能。 |
| メトリクスの粒度 |
2 |
基本的なメトリクスは取得可能だが、粒度は限定的。 |
| ログの構造化 |
2 |
ログ出力は可能だが、構造化は手動設定が必要。 |
| バックアップの整合性 |
2 |
Arrow形式のファイルで整合性は保てるが、運用に工夫が必要。 |
| スナップショット対応 |
2 |
PVCを使えばVeleroで対応可能。 |
Chroma
| 評価項目 |
スコア |
理由 |
| Helmチャートの有無 |
1 |
HelmチャートやK8s向けの公式サポートはなし。 |
| 初期構成の柔軟性 |
2 |
Pythonベースで柔軟だが、K8s向けではない。 |
| ストレージ対応 |
1 |
ローカルストレージ前提で、PVC対応は非公式。 |
| 自動インデックス作成 |
2 |
自動でインデックスが作成されるが、簡易的。 |
| 非同期インデックス処理 |
2 |
非同期処理に対応しているが、制御は限定的。 |
| インデックスの即時反映 |
2 |
即時反映されるが、精度や整合性は限定的。 |
| Prometheusエクスポーターの有無 |
1 |
エクスポーターは提供されていない。 |
| メトリクスの粒度 |
1 |
メトリクス出力は基本的に未対応。 |
| ログの構造化 |
1 |
ログ出力は可能だが、構造化されていない。 |
| バックアップの整合性 |
1 |
ローカルファイルベースで整合性保証は弱い。 |
| スナップショット対応 |
1 |
PVCを使わないため、Veleroとの連携は困難。 |
結論
総合評価は以下のようになりました。
トップスコアがQdrantなので、これを採用します。
| DB名 |
合計スコア |
| Qdrant |
33 |
| PGvector |
26 |
| LanceDB |
22 |
| Chroma |
17 |
まとめ & 次のステップ
- DBの最適解はユースケース、要件によって異なります
- 我々のプロジェクトでの現在の最適解はQdrantと結論付けましたが、将来的には違う結論となる可能性もあります
- Qdrantは大手サービスの提供者でもよく採用されている有名どころなので、ノウハウの蓄積が他案件などでも活きる可能性も高く、そういう意味でも都合がよいと考えられます。
参考リンク
Discussion