ローカルLLM RAG用ベクトルDB比較 2026年版:Qdrant / Milvus / Weaviate / Chroma / pgvector を埋め込み次元・速度・運用で選ぶ

結論:個人〜小規模検証は Chroma で即起動、本番ローカルRAG は Qdrant、すでにPostgresを動かしているなら pgvector、ハイブリッド検索が必須なら Weaviate、1億ベクトル超の大規模なら Milvus。 どれも HNSW を実装し似たレシピで使えますが、運用コスト(Docker 1個か k8s か)、ハイブリッド検索の有無、既存スタックとの相性で選択が分かれます。本記事は5択の差を、100万チャンク級の RAG 用途を基準に整理します。

RAG のハードウェア側は「ローカルRAG構築向けPC構成ガイド 2026年版」と「24時間稼働 ローカル LLM サーバー構築ガイド 2026年版」で扱っていますが、「ソフト側のベクトルDBどれ選ぶか」は別問題で、必ずぶつかります。本記事はそこを埋めます。

5択の立ち位置を一枚で

DB	一言で	言語	デプロイ	主な対応index	ハイブリッド検索	主な用途
Chroma	Python で即起動・最軽量	Python	Python直 / Docker	HNSW	△(自前実装)	個人検証・プロトタイプ
pgvector	Postgres 拡張・既存DBに同居	C	PostgreSQL 拡張	HNSW / IVFFlat	△(全文検索と組合せ)	既存Postgres運用・中小規模本番
Qdrant	Rust製・Docker1個で本格派	Rust	Docker / バイナリ	HNSW + sparse	◎(2024〜ネイティブ)	本格RAG・100万〜1,000万級
Weaviate	モジュール式・ハイブリッド最強	Go	Docker / k8s	HNSW	◎(BM25 内蔵)	ハイブリッド前提・モジュール拡張
Milvus	C++製・分散・超大規模	C++	Standalone / k8s	HNSW / IVF / DiskANN	○	1億ベクトル超・分散運用

「左ほど軽い」「右ほど大規模・本格」のグラデーションです。RAG の最初の1本は Chroma か pgvector で十分、規模が育って初めて Qdrant / Weaviate / Milvus を検討する、という順番が無駄が出ません。

Chroma:Python から即起動

import chromadb
client = chromadb.PersistentClient(path="./chroma_db")
col = client.get_or_create_collection("docs")
col.add(documents=["text1", "text2"], ids=["1", "2"])
hits = col.query(query_texts=["query"], n_results=3)

• 強み:pip install chromadb の1行で導入、別プロセス不要、ファイル永続化、ノートブック検証からそのまま延長できる
• 弱み:1,000万級では遅くなる、ハイブリッド検索は自前、運用ツール(管理UI・監視)が薄い
• 適正規模:〜10万チャンク(快適)、〜100万(動くが他のDBが速い)、それ以上は別DB推奨

「RAG をまず動かしたい」最初の一本として最短。長期運用や複数アプリ共有では別DBへ移る前提で使うのが穏当です。

pgvector:既存PostgresにRAGを足す

CREATE EXTENSION vector;
CREATE TABLE docs (id bigserial, content text, emb vector(1536));
CREATE INDEX ON docs USING hnsw (emb vector_cosine_ops);
SELECT content FROM docs ORDER BY emb <=> '[0.1,0.2,...]' LIMIT 3;

• 強み:既存Postgres の認証・バックアップ・接続プール・JOIN がそのまま使える、運用コストの追加がほぼゼロ、トランザクション内で埋め込み更新と関連レコード更新が一貫
• 弱み:超大規模(数千万〜)では index ビルド時間とメモリが効く、ハイブリッド検索は ts_vector(全文)と組み合わせるが Weaviate ほど洗練されていない
• HNSW vs IVFFlat:100万以下なら HNSW が定番(低レイテンシ高リコール)、5,000万超でメモリ・ビルド時間が痛くなるなら IVFFlat に逃げる
• 適正規模:〜100万チャンク(快適)、〜1,000万(チューニング前提で実用)、それ以上は専用DB推奨

既存DBに「テーブル追加するだけでRAG が動く」価値が大きい。アプリ側がすでに Postgres を使っているなら、別ストアを増やさず pgvector に寄せるのが運用上一番安い選択です。

Qdrant:Rust製・本格RAGの本命

from qdrant_client import QdrantClient
from qdrant_client.models import VectorParams, Distance, PointStruct
c = QdrantClient(url="http://localhost:6333")
c.create_collection("docs", vectors_config=VectorParams(size=1536, distance=Distance.COSINE))
c.upsert("docs", points=[PointStruct(id=1, vector=[0.1]*1536, payload={"text":"..."})])
hits = c.search("docs", query_vector=[0.1]*1536, limit=3)

• 強み:Rust 製で低レイテンシ・低メモリ、Docker 1個で起動、HNSW + sparse vector ネイティブサポート、ACORN アルゴリズムでフィルタ付きHNSW が高速
• 弱み:Postgres のような既存運用基盤との統合は別物として扱う必要がある
• 公開ベンチでの位置:1M〜10M ベクトル帯で P99 12ms 級と速度評価が高く、Weaviate / Milvus より単一ノードでは優位の報告が多い
• 適正規模:〜10万(オーバースペック)、100万〜1,000万(本領発揮)、それ以上(複数ノードまたは Milvus 検討)

本気のローカル RAG を組むなら Qdrant が穏当。Docker 1個で動く軽さと、本格機能(sparse / hybrid / フィルタ)の両立が強み。

Weaviate:モジュール式・ハイブリッド検索の本命

import weaviate
c = weaviate.Client("http://localhost:8080")
c.batch.add_data_object({"text":"..."}, class_name="Doc")
res = c.query.get("Doc", ["text"]).with_hybrid(query="検索語", alpha=0.5).with_limit(3).do()

• 強み:BM25(キーワード) + dense vector のハイブリッド検索を組み込みでサポート、alpha パラメータで配分を 0(キーワードのみ)〜1(ベクトルのみ)で調整、リランキング・ベクトル生成・分類などモジュール拡張が豊富
• 弱み:Go ランタイム+モジュール構成で起動が他より重い、Qdrant ほどの単純速度は出ない場面がある
• 適正規模:〜10万(オーバースペック)、100万〜1,000万(本領発揮)、それ以上(クラスタ構成)
• 使いどき:ハイブリッド検索が必須(法務・医療文書など固有名詞検索が効く用途)、ベクトル化・リランクをDB内で完結したい

ハイブリッド検索を「自前で BM25 と dense を別々に取得→マージ」する手間が嫌いなら Weaviate が最短です。

Milvus:C++製・分散・超大規模向け

• 強み:C++ 製で超大規模・分散運用に対応、HNSW / IVF / DiskANN(SSD 配置)など複数 index タイプ、1 億ベクトル超のシングルクラスタ運用実績、Zilliz Cloud という商用ホスト版あり
• 弱み:standalone でも依存(etcd / minio など)が多く、Qdrant のような単一バイナリ感は無い、k8s 前提の運用知識が要る
• 適正規模:100万(オーバースペック)、1,000万〜1 億(本領発揮)、1 億超(他に競合無し)
• 使いどき:全社ドキュメント・大規模ナレッジ・多テナント検索など個人ユースを超える規模

個人ユースで Milvus を選ぶ理由はほぼ無い。1 億ベクトルを超える、または分散運用が前提の規模で初めて検討する DB です。

100万チャンク時の比較レンジ

「1,536次元 × 100万ベクトル」(OpenAI text-embedding-3-small / BGE-M3 / Nomic Embed v2 などの主流次元)を基準に、公開ベンチ報告のレンジを整理します。

DB	P95 latency	メモリ使用	index ビルド時間	必須リソース
Chroma	30〜80ms	6〜8GB	5〜15分	Python プロセス 1 個
pgvector (HNSW)	10〜30ms	8〜12GB	10〜30分	PostgreSQL 1 インスタンス
Qdrant	5〜15ms	5〜7GB	5〜15分	Docker 1 コンテナ
Weaviate	10〜25ms	7〜10GB	8〜20分	Docker / k8s
Milvus standalone	8〜20ms	10〜15GB	8〜20分	Docker compose 3〜4 コンテナ

数値はベンチサイト・ブログ報告のレンジで、HW(CPU / メモリ / ストレージ)と HNSW パラメータ(ef_construction / M 等)で大きく動きます。100万級なら全DBが「実用には十分」の帯で、選定はレイテンシより運用コスト・既存スタックとの相性で決めるべきです。

メモリ使用量は HNSW index 自体が「ベクトル次元 × 件数 × 4byte(float32) + グラフ構造のオーバーヘッド」で支配されます。1,536次元 × 100万 ≒ 6GB が素のベクトル分、index でさらに 1.5〜2 倍に膨らむ、と覚えておくと見積もりが早いです。

埋め込みモデルとの組み合わせ

2026年時点の主流埋め込みは次の通りです。次元数によってDB側のメモリ消費が直接変わるため、ペアで考える必要があります。

モデル	次元	100万件のメモリ目安	特徴
OpenAI text-embedding-3-small	1,536	6GB	商用API、コスト安
BGE-M3	1,024	4GB	多言語OSS、HuggingFace で定番
Nomic Embed v2	768	3GB	軽量OSS、CPU 推論可
Qwen3-Embedding-8B	4,096	16GB	MTEB 70.58 首位級、要 GPU
mxbai-embed-large	1,024	4GB	英語強い、定番

「Qwen3-Embedding-8B(4,096次元)で 100万件」は素のベクトルだけで 16GB、index 込みで 25GB 級になります。埋め込みの次元が大きいと DB 側のメモリも線形に増えるため、精度と運用コストのバランスで埋め込みを選んでください。

埋め込みモデル自体のローカル運用と VRAM 配分は「ローカルRAG構築向けPC構成ガイド 2026年版」で詳しく扱っています。

LangChain / LlamaIndex からの接続

各DB は LangChain / LlamaIndex の VectorStore 抽象に対応しています。差し替えコストは小さく、初期は Chroma で書いて Qdrant / pgvector に移行するのも容易です。

# LangChain + Qdrant の例
from langchain_qdrant import Qdrant
from langchain_community.embeddings import OllamaEmbeddings
emb = OllamaEmbeddings(model="nomic-embed-text")
vs = Qdrant.from_documents(docs, embedding=emb, url="http://localhost:6333", collection_name="docs")
hits = vs.similarity_search("query", k=3)

# LlamaIndex + pgvector の例
from llama_index.vector_stores.postgres import PGVectorStore
vs = PGVectorStore.from_params(host="localhost", port=5432, database="rag",
                                user="postgres", password="...", table_name="docs", embed_dim=1536)

LangChain / LlamaIndex の VectorStore 抽象を介して書いておけば、DB を入れ替えるコストは初期検証 → 本番移行の段階でほぼ吸収できる。最初のDB選定で迷ったら、まず Chroma か pgvector で動かして、規模が見えてきた段階で本格DB に移るのが現実解です。

埋め込みを Ollama / llama.cpp / LM Studio など各ランタイムから取り出す手段の比較は「ローカルLLM実行ツール比較 2026年版」を参照してください。

用途別の選び方

判断は「規模」「既存スタック」「ハイブリッド検索の必要性」の3軸で割り切るのが最短です。

個人検証・ノートブック作業

• Chroma 一択
• pip install で1分で動く、ファイル永続化でノートブックを閉じてもデータが残る
• 1万〜10万チャンクの個人ナレッジには十分

すでに PostgreSQL を運用中

• pgvector 一択
• 既存の認証・バックアップ・接続プールがそのまま使える
• 100万〜1,000万チャンクまでは HNSW で十分実用

本格ローカル RAG(小規模法人・100万〜1,000万チャンク)

• Qdrant
• Rust製の速度、Docker 1個の運用簡便さ、フィルタ付きHNSW が速い
• Postgres を使っていない・ハイブリッド検索が必須でない、なら穏当

ハイブリッド検索が必須(法務・医療・固有名詞検索)

• Weaviate
• BM25 + dense のフュージョンを alpha 1 つで調整、モジュール拡張で機能追加が早い

1 億ベクトル超・分散運用

• Milvus
• 個人ユースを超えた規模でのみ検討、k8s 前提の知識が必要

まとめ:規模と既存スタックで決まる

• Chroma:個人検証・プロトタイプの最初の一本
• pgvector:既存Postgres運用中なら追加コストほぼゼロで RAG が乗る
• Qdrant:本格ローカル RAG・100万〜1,000万級の本命、Docker 1 個運用
• Weaviate:ハイブリッド検索(BM25+dense)が必須の用途で最強
• Milvus:1 億ベクトル超・分散運用に振り切った超大規模向け

ベクトルDB は「どれが最速か」より「自分の運用と既存スタックに何が合うか」で決まる領域です。100万チャンク級ならどれも実用十分の速度が出ます。最初は Chroma か pgvector で動かして、規模・要件が見えてから Qdrant / Weaviate / Milvus に移るのが、無駄が出ないルートです。

---

あなたに合うPCを診断する

用途や予算をもう少し細かく入力すると、3つの候補構成を提案します。

→ 診断スタート

関連記事

• ローカルRAG構築向けPC構成ガイド 2026年版:ハード構成・VRAM配分の判断軸
• ローカルLLM実行ツール比較 2026年版:Ollama / LM Studio / llama.cpp / vLLM の使い分け
• 24時間稼働 ローカル LLM サーバー構築ガイド 2026年版:自宅サーバーで RAG を常時稼働させる構成
• ローカルLLMを動かすPCの最低スペック 2026年版:RAG 全体の入口、まずどれくらいの PC が必要か