RAGを作るとき、ほとんどのチームが最初に詰まるのが「どのベクトルデータベースを使うか」だ。Qdrant、Milvus、Weaviate、Chroma、そしてPostgreSQL拡張のpgvector——選択肢は多いが、判断軸は実はそれほど多くない。
この記事は、主要5本をRAG用途のランキング形式で評価し、性能・ライセンス・運用コストの違いと選び方を2026年最新版で整理する。各製品の公式リポジトリと公開ベンチマークを一次情報とした。
- Postgresを使っているなら、まず pgvector。新しいインフラを増やさずベクトル検索を足せる
- 専用DBが必要なら Qdrant が基準。オープンソース最速で、開発から本番まで素直に伸びる
- 10億件超の超大規模だけ Milvus。Chromaはプロト用、Weaviateは埋め込み内蔵が欲しいとき
RAGそのものの仕組みと実装手順は LightRAG入門ガイド もあわせてご覧ください。
ベクトルデータベースの選び方：まず3タイプに分ける
ベクトルデータベースは「有名だから」で選ぶと運用で詰まる。出発点は、自分の導入フェーズと規模を3タイプのどれに当てはめるかだ。
・既存DB拡張型（pgvector） … すでにあるPostgreSQLにベクトル型を足す。導入ハードルが最も低く、数十万〜数百万件規模なら実用十分
・専用型（Qdrant / Weaviate / Milvus） … ベクトル検索のために設計されたDB。数千万件以上、ミリ秒レイテンシが必要ならこちら
・軽量・組み込み型（Chroma） … プロトタイピングやローカル検証向け。本番大規模には向かない
この分岐をフローにすると次のようになる。
運用している?} B -->|Yes| C{規模は
1000万件未満?} C -->|Yes| D[pgvector
で開始] C -->|No| E{10億件を
超える?} B -->|No| E E -->|Yes| F[Milvus] E -->|No| G[Qdrant
が基準] G --> H{埋め込み生成も
内蔵したい?} H -->|Yes| I[Weaviate
も候補] H -->|No| G
RAG用ベクトルデータベース ランキング2026
主要5本を「RAG実装での総合的な扱いやすさ」で順位付けした。スコアは性能・運用コスト・エコシステム・導入の容易さを編集部で総合評価したもの（10点満点）。用途によって最適解は変わるため、各製品の寸評を必ず読んでほしい。
スペック比較表：性能・ライセンス・適性が一目で分かる
ランキングの根拠を表で並べる。レイテンシは10M件規模の公開ベンチマーク（p99）の概数。
| 製品 | 言語 | ライセンス | p99(10M) | ハイブリッド検索 | 向いている規模 |
|---|---|---|---|---|---|
| Qdrant | Rust | Apache-2.0 | 約12ms | ◎ ネイティブ | 数万〜数億 |
| pgvector | C | PostgreSQL | 規模依存 | △ 全文検索と併用 | 〜数百万 |
| Milvus | Go/C++ | Apache-2.0 | 約18ms | ◎ ネイティブ | 数千万〜10億+ |
| Weaviate | Go | BSD-3 | 約16ms | ◎ ネイティブ | 数十万〜数億 |
| Chroma | Python | Apache-2.0 | — | △ | 〜数十万（検証） |
⭐ Star数は概数（2026年6月時点）。最新値は各リポジトリを参照。レイテンシは構成・ハードウェアで変動する。
Qdrantを5分で動かす：最短クイックスタート
「迷ったらQdrant」を実際に確かめる。Dockerで起動し、Pythonからベクトルを投入して検索するまでを最短手順で示す。
- Dockerで起動公式イメージを
docker runするだけ。6333番でREST/gRPCが立ち上がる。 - クライアントを導入
pip install qdrant-client。Python以外にもRust/Go/TS公式クライアントがある。 - コレクション作成＋投入ベクトル次元と距離関数（Cosine等）を指定してupsert。
- 類似検索クエリベクトルでtop-kを取得。これがRAGの「検索」部分になる。
まずDockerで起動する。
docker run -p 6333:6333 -p 6334:6334 \
-v $(pwd)/qdrant_storage:/qdrant/storage \
qdrant/qdrant
起動とヘルスチェックの実際の出力はこうなる。
docker run -p 6333:6333 qdrant/qdrant _ _ __ _ __| |_ __ __ _ _ __ | |_ / _` |/ _` | '__/ _` | '_ \| __| INFO Qdrant gRPC listening on 6334 INFO Qdrant HTTP listening on 6333 INFO Actix runtime found; starting in Actix runtime curl -s localhost:6333/healthz healthz check passed
続いてPythonからコレクションを作り、ベクトルを投入して検索する。
from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams, PointStruct
client = QdrantClient(url="http://localhost:6333")
# コレクション作成（埋め込み次元=384, コサイン類似度）
client.recreate_collection(
collection_name="docs",
vectors_config=VectorParams(size=384, distance=Distance.COSINE),
)
# ベクトル投入（実際は埋め込みモデルの出力を入れる）
client.upsert(
collection_name="docs",
points=[
PointStruct(id=1, vector=[0.12, 0.03, ...], payload={"text": "RAGとは"}),
PointStruct(id=2, vector=[0.08, 0.11, ...], payload={"text": "ベクトル検索"}),
],
)
# 類似検索（RAGの「検索」フェーズ）
hits = client.query_points(
collection_name="docs",
query=[0.10, 0.05, ...],
limit=3,
).points
for h in hits:
print(h.score, h.payload["text"])
参考までに、pgvectorで同じことをやる場合はSQLだけで完結する。
-- 拡張を有効化してテーブルにベクトル列を足す
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE docs (id bigserial PRIMARY KEY, text text, embedding vector(384));
-- 類似検索（<=> はコサイン距離演算子）
SELECT text, 1 - (embedding <=> '[0.10,0.05, ...]') AS score
FROM docs
ORDER BY embedding <=> '[0.10,0.05, ...]'
LIMIT 3;
この「専用クライアントを覚えるか、SQLで済ませるか」の差が、Qdrantとpgvectorの体験差そのものだ。
本番投入で詰まりやすい3つの落とし穴（クリックで展開）
1. インデックス未設定で遅い：投入直後はフルスキャンになりがち。Qdrantはセグメント最適化、pgvectorはHNSW/IVFFlatインデックスの作成を忘れずに。
2. 埋め込み次元の不一致：コレクション作成時の次元と、埋め込みモデルの出力次元がズレると投入時にエラー。モデルを変えたら作り直す。
3. 距離関数の選び間違い：多くの埋め込みモデルはコサイン類似度前提。L2やドット積を選ぶと検索品質が落ちる。モデルのドキュメントに従う。
マネージドかセルフホストか：運用コストで決める
性能が拮抗してくると、最後の決め手は運用体制になる。
・少人数・インフラ専任なし … マネージド（Qdrant Cloud / Zilliz Cloud / Pinecone）で運用負荷を外す。月額は乗るが、人件費とダウンタイムリスクを考えれば総コストは下がりやすい
・データ主権・コスト最適化が重要で運用リソースあり … Apache-2.0のQdrant・Milvusをセルフホスト。クラウド費用を自分でコントロールできる
・既にマネージドPostgres（Aurora / Azure）を使っている … pgvectorをそのまま乗せる。可用性・バックアップは既存の仕組みに乗る
RAGのデータ量は運用しながら増える。最初に「移行できる構成」を選んでおくことが、3か月後の自分を救う。Chromaで検証 → Qdrantで本番、pgvectorで開始 → 限界が来たら専用DB、といった移行パスを最初から想定しておきたい。
結論：判断軸は「Postgres運用の有無」と「規模」の2つだけ
- ・Postgresを使っている & 1000万件未満 → pgvectorで始める
- ・専用DBが必要 → オープンソース最速のQdrantが基準
- ・10億件超の超大規模 → Milvus、埋め込み内蔵が欲しい → Weaviate
- ・アイデア検証 → Chromaで素早く、本番は専用DBへ移行
ベクトルDBが決まったら、次はRAGパイプライン本体だ。データ取り込みから検索・生成までの作り方は、フレームワーク別に LangChain解説 や RAGFlow で深掘りしている。エージェントの長期記憶としてベクトル検索を使う設計に踏み込むなら、AIエージェントフレームワーク比較 も参考になる。
参照ソース
・Qdrant 公式リポジトリ（qdrant/qdrant） — Rust製ベクトル検索エンジンの一次情報
・pgvector 公式リポジトリ（pgvector/pgvector） — PostgreSQL拡張の仕様・v0.9変更点
・Vector Database Benchmarks 2026（CallSphere） — p99レイテンシ等の公開ベンチマーク
・Best Vector Databases in 2026（Firecrawl） — 主要製品の特性・選定指針
