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点満点）。用途によって最適解は変わるため、各製品の寸評を必ず読んでほしい。
スペック比較表：性能・ライセンス・適性が一目で分かる
ランキングの根拠を表で並べる。star数・実装言語・ライセンス・最新リリースはGitHub APIで実測した値（2026-08-26取得）、レイテンシは10M件規模の公開ベンチマーク（p99）の概数である。実測できる列と、構成次第で動く列を混ぜないのがこの表の読み方だ。
| 製品 | ★（実測） | 言語 | ライセンス | 最新リリース | p99(10M)※ | ハイブリッド検索 | 向いている規模 |
|---|---|---|---|---|---|---|---|
| Qdrant | 34,191 | Rust | Apache-2.0 | v1.19.0（2026-08-05） | 約12ms | ◎ ネイティブ | 数万〜数億 |
| pgvector | 22,743 | C | PostgreSQL License | （PostgreSQL拡張として提供） | 規模依存 | △ 全文検索と併用 | 〜数百万 |
| Milvus | 45,788 | Go/C++ | Apache-2.0 | v3.0.0（2026-07-29）／v2系は v2.6.22（2026-08-04） | 約18ms | ◎ ネイティブ | 数千万〜10億+ |
| Weaviate | 16,754 | Go | BSD-3-Clause | v1.39.1（2026-08-25）／v1.38系は v1.38.12（2026-08-25） | 約16ms | ◎ ネイティブ | 数十万〜数億 |
| Chroma | 29,147 | Rust（旧Python） | Apache-2.0 | 1.5.9（2026-05-05） | — | △ | 〜数十万（検証） |
※ p99レイテンシのみ公開ベンチマークの概数で、構成・ハードウェア・インデックス設定で容易に倍以上動く。製品選定の一次根拠にはせず、必ず自分のデータで測り直すこと。他の列はGitHub APIの実測値。
この表から読み取れる、2026年6月時点との差分が2つある。
① Chromaの実装言語はPythonではなくRustになっている。 「手軽に試せるPython製」という以前の紹介は現状と合わない。GitHub API上の主要言語はRustで、コア部分が書き直された結果だ。「プロトタイプ用のPythonライブラリ」という前提で選ぶと、ビルドや配布の勘所が変わる点に注意したい。ただし Python クライアントから使う体験そのものは維持されており、利用者側のAPIが変わったわけではない。
② Milvusはv3.0.0というメジャーバージョンに乗っている（2026-07-29）。5製品の中で唯一メジャー版が上がっており、v2系の記事・チュートリアルをそのまま踏襲すると差異を踏む可能性が高い。10億件規模を狙ってMilvusを選ぶ場合は、参照するドキュメントがv3系かどうかを最初に確認してほしい。
③ MilvusとWeaviateは「最新版」が1本に決まらない。 今回の再取得で分かったことだが、この2製品は安定版のラインを2本並行で維持している。GitHub APIで「作成日が最も新しいリリース」を取ると、Milvusは v2.6.22（2026-08-04）、Weaviateは v1.38.12（2026-08-25）が返る。しかし各リポジトリが latestRelease として指しているのは Milvus v3.0.0（2026-07-29）／Weaviate v1.39.1（2026-08-25） のほうだ。
つまり新しいメジャー/マイナー版が出たあとも、旧ラインへのパッチが後日リリースされ続けるため、日付順に並べると旧ラインが先頭に来る。
この2製品では、リリース日の新しさとバージョンの新しさが一致しない。CIでバージョンを自動追従させている場合、日付順で取ると意図せず旧メジャーラインに固定される／逆にメジャー更新を踏むといった事故が起きうる。
latestRelease（あるいは明示的なバージョン指定）で取ること。裏を返せば旧ラインが保守され続けている＝すぐの移行を強制されないということでもあり、Milvus v2系を使っているなら v3.0.0 の登場だけを理由に慌てて上げる必要はない。
star数の順位も直感とずれることがある。最多はMilvus（45,788）で、Qdrant（34,191）はその次だ。ただしstarは「話題になった量」であって性能でも運用実績でもない。pgvectorが22,743と控えめに見えるのは、PostgreSQLの拡張という性格上、PostgreSQL本体の利用者数がそのまま数字に出ないためで、実際の導入数を過小評価しやすい代表例である。
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） — 主要製品の特性・選定指針
