Qdrant vs Chroma vs pgvector: セルフホスト型RAGに最適なベクトルDBの選び方

Qdrant vs Chroma vs pgvector: セルフホスト型RAGに最適なベクトルDBの選び方

Qdrant vs Chroma vs pgvector の選択は、以下の3つのトレードオフに集約されます。「専用設計による速度」「プロトタイピングの簡易性」、それとも「PostgreSQL環境内での完結」か。どのアプローチも機能しますが、重要なのは、どのトレードオフがあなたのRAGパイプラインに適合するかです。

クイックサマリー：どのベクトルデータベースを選ぶべきか？

Qdrantを選ぶ場合: 高度なフィルタリングやマルチテナンシーを備えた本番環境レベルのベクトル検索が必要で、別途サービスを実行することに抵抗がない場合。

Chromaを選ぶ場合: プロトタイピング段階であり、設定不要のローカル開発を望む場合、またはアイデアから動作するRAGまでを1時間以内に実現したい場合。

pgvector（+ pgvectorscale）を選ぶ場合: すでにPostgreSQLを実行しており、インフラを追加せずにベクトル検索を導入したい場合。特に、pgvectorscaleのStreamingDiskANNインデックスによってパフォーマンスギャップが埋まった現在では有力な選択肢です。

RAGアプリケーションをゼロから構築している場合、この記事の残りが適切な基盤選びのお手伝いをします。

パフォーマンス：各データベースはどれくらい高速か？

文書数が数千を超えると、パフォーマンスが重要になります。ここで3者の違いが顕著になります。

Qdrant

Qdrantはベクトル検索専用に設計されています。Rust実装とカスタムHNSWインデックスにより、一貫して低レイテンシを実現し、ベンチマークでは同時実行負荷下でもクエリレイテンシが約94msを示しています。スカラー、バイナリ、製品量子化をサポートし、ベクトルを圧縮して検索を高速化しながら、再現率（Recall）を95%以上に維持します。

Qdrantが真に輝くのはフィルタ付き検索です。近傍探索を先に行ってからフィルタリングするデータベースとは異なり、Qdrantのフィルタ対応HNSWはグラフ走査中にメタデータの制約を尊重します。つまり、category = "technical" や date > 2025-01-01 などのフィルタとベクトル検索を組み合わせる際にも、再現率が低下しません。

Chroma

Chromaの1.0リリースではコアがRustで書き直され、元のPython実装と比較して書き込みとクエリが3〜5倍高速化されました。2025年8月のアップデートではbase64ベクトルエンコーディングが追加され、スループットがさらに70%向上しました。

100万ベクトル未満のデータセットであれば、Chromaは確かに高速です。ネットワークオーバーヘッドなしでPythonプロセス内に埋め込んで実行できるため、ローカルでの反復作業が迅速に行えます。ただし、これはシングルノードのデータベースであり、組み込みのシャーディングやレプリケーションはありません。

pgvector + pgvectorscale

これがダークホースです。HNSWを使用した標準的なpgvectorは、順次スキャンよりも5,250倍高速であり、pgvector 0.8.0では反復インデックススキャンが追加され、以前のバージョンを悩ませていた過剰フィルタリング問題が解決されました。

しかし、真の主役はpgvectorscaleです。Timescaleのこの拡張機能は、MicrosoftのDiskANN研究に触発されたStreamingDiskANNインデックスを追加し、インデックスをRAMではなくディスク上に保存します。5000万件のCohere埋め込み（768次元）のベンチマークでは、pgvectorscaleは99%の再現率で471 QPSを達成しました。これは同じ再現率レベルでのQdrantの41 QPSよりも11.4倍高いスループットであり、Pineconeのストレージ最適化インデックスよりもp95レイテンシが28倍低い結果です。

注意点としては、これらのベンチマークは強力なEC2インスタンスを使用していたことです。結果はハードウェアに依存します。しかし、傾向は明確です。PostgreSQLはベクトル検索において「まあまあの選択肢」ではなくなり、真に競争力のあるものになっています。

結論: 純粋なベンチマーク数値では pgvector + pgvectorscale が勝利。 フィルタ付き検索のパフォーマンスでは Qdrant が勝利。Chroma はプロトタイプには十分高速ですが、大規模化向けには設計されていません。

セットアップと開発者体験

ゼロからベクトル処理まで、どれくらいの速さで到達できるでしょうか？

Qdrant: DockerとGo

Qdrantには独自のコンテナが必要です。

docker run -p 6333:6333 -v $(pwd)/qdrant_storage:/qdrant/storage qdrant/qdrant

その後、REST APIまたは公式SDK（Python、Rust、Go、TypeScript）を介してベクトルを挿入します。

from qdrant_client import QdrantClient
from qdrant_client.models import VectorParams, Distance

client = QdrantClient(url="http://localhost:6333")
client.create_collection(
    collection_name="documents",
    vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
)

localhost:6333/dashboard にあるQdrantのダッシュボードは素晴らしい機能で、コレクションの閲覧、クエリの実行、ペイロードの視覚的な検査が可能です。開発から本番への移行パスはクリーンです。ローカルのDockerセットアップは、本番サーバーやQdrant Cloud上でも同一に動作します。

Chroma: pipインストールで完了

Chromaは簡易性の点で他を大きく引き離しています。

import chromadb

client = chromadb.Client()  # In-memory, zero config
collection = client.create_collection("documents")
collection.add(
    documents=["Your RAG document here"],
    ids=["doc1"]
)

Docker不要。サーバー不要。ベクトルを提供しない場合、埋め込み生成も自動的に行います。RAGプロトタイプの場合、pip install chromadb から動作する検索までを10行未満のコードで実現できます。

永続化が必要になったら、chromadb.PersistentClient(path="./chroma_data") に切り替えます。マルチプロセスまたはネットワークアクセスのためにChromaにはサーバーモードがありますが、その時点では簡易性の優位性が失われ始めます。

pgvector: SQL一辺倒

スタックにすでにPostgresがある場合、pgvectorは一行で済みます。

CREATE EXTENSION vector;

CREATE TABLE documents (
  id SERIAL PRIMARY KEY,
  content TEXT,
  embedding vector(1536)
);

CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

すべてがSQLです。埋め込みはアプリケーションデータと同じトランザクション内に存在します。同期パイプラインも、別々の認証情報も、監視すべき追加サービスもありません。すでに本番環境でPostgreSQLを実行しているなら、これが最小抵抗の経路です。

TimescaleのDockerイメージや、それをサポートするマネージドPostgresプロバイダーを使用している場合、pgvectorscaleの追加は簡単です。

CREATE EXTENSION vectorscale;
CREATE INDEX ON documents USING diskann (embedding);

欠点？ SQLは、QdrantのペイロードフィルタリングDSLやChromaのPythonらしいAPIほど使い勝手が良いわけではありません。また、埋め込みパイプラインは自分で管理する必要があります。pgvectorは埋め込みを生成してくれません。

結論: 最速のプロトタイピングでは Chroma が勝利。 Postgresがすでにスタックにある場合は pgvector が勝利。DX（開発者体験）と本番環境対応のバランスでは Qdrant が最も優れています。

スケーリングと本番環境への対応

プロトタイピングは一つのことです。数百万のベクトルを一貫したレイテンシで処理するRAGパイプラインを実行することは別のことです。

Qdrant: 水平スケーリングのために設計

Qdrantは开箱即出で水平シャーディングをサポートしています。高可用性のために構成可能なレプリケーション係数を用いて、コレクションを複数のノードに分散できます。2026年のロードマップには、さらなるスケーリングのための読み書き分離とブロックストレージ統合が含まれています。

マルチテナンシーはファーストクラスの機能です。ペイロードベースのフィルタリングを使用してテナントごとにデータをパーティション分割でき、個別のコレクションを作成する必要がないため、リソース使用効率が保たれます。複数のユーザーを扱うAIエージェントメモリシステムにとって、これは大きな利点です。

運用面のストーリーも堅牢です。組み込みのバックアップ、Prometheus用のメトリクスエンドポイント、WALベースのクラッシュリカバリを備えています。Qdrantは本番環境でのセルフホストを対象に設計されています。

Chroma: シングルノードの限界

Chromaはその限界について正直です。簡易性とローカル開発に焦点を当てたシングルノードのデータベースです。組み込みのシャーディング、レプリケーション、クラスタリングはありません。

Chroma Cloudは2026年初頭にサーバーレスの分散型マネージドオプションとして一般提供開始となり、自身で実行する代わりに水平スケーリングをそこに委譲できるようになりました。しかし、セルフホスト型のオープンソースとしての物語は依然として「1台のサーバー、1つのChromaインスタンス」が中心です。データセットが1台のマシンに収まる場合（次元数に応じて数百万ベクトルまで）、それは問題ありません。それを超えると、セルフホスト型Chromaは壁にぶつかり、Chroma Cloudへの移行か、別のソリューションへの移行を選択することになります。

pgvector: Postgresと共にスケール

pgvectorはPostgreSQLの鍛え上げられたスケーリングの歴史を継承しています。読み取りレプリカ、PgBouncerによる接続プーリング、論理レプリケーションを利用できます。NeonなどのサーバーレスPostgresプラットフォームのようなマネージドプロバイダーは、垂直スケーリングをほぼ effortless にします。

pgvectorscaleのStreamingDiskANNインデックスは、スケーリングのための鍵となる解法です。インデックスをRAMではなくディスク（SSD）に保存するため、 otherwise 高価な高メモリインスタンスを必要とする大規模なデータセットを処理できます。5000万ベクトルにおいて、それは専用設計のベクトルデータベースとすでに競合しています。

制限は水平シャーディングです。PostgreSQLはQdrantのようにネイティブにシャーディングしません。Citusのような解決策は存在しますが、複雑さを増します。1億ベクトル未満のほとんどのセルフホスト型RAGワークロードでは、pgvectorscaleによる垂直スケーリングで十分です。

結論: 水平スケーリングとマルチテナンシーでは Qdrant が勝利。 既存のPostgresインフラを活用できる点では pgvector が勝利。Chroma は本番規模には設計されていません。

セルフホストのコスト

3つすべてがオープンソースで、実行自体は無料です。真のコストはインフラとエンジニアリング時間です。

pgvectorには構造的なコスト優位性があります。すでにPostgresに支払っている場合、専用リソースが必要になるまでベクトル検索の追加は事実上無料です。追加のコンテナも、追加の監視も、追加のバックアップ戦略も不要です。

Qdrantのリソース使用量は機能セットに対して効率的ですが、それは別個のサービスです。もう一つのインフラピースを実行・監視するための運用オーバーヘッドを考慮に入れる必要があります。

Chromaはプロトタイプ段階では最も安価（インフラゼロ）ですが、シングルノードで処理できる範囲を超えてスケーリングしようとすると、最も高コストな経路になります。

クラウドプラットフォームへのデプロイに関しては、Qdrantとpgvectorの両方がStraightforwardなDockerベースのデプロイメントを持っています。Chromaも動作しますが、その主な売りである埋め込み型の簡易性は失われます。

結論: 総所有コスト（TCO）では pgvector が勝利。 スタックからサービス全体を排除します。Qdrantは提供される機能に対して妥当な価格です。Chromaのコストストーリーはプロトタイピング期間中のみ有効です。

フィルタリングとハイブリッド検索

RAGは単に「最も近いベクトルを見つける」だけではありません。類似度検索をメタデータフィルタ、日付範囲、アクセス制御、場合によってはキーワードマッチングと組み合わせる必要があります。

Qdrant: フィルタリングの王者

Qdrantのペイロードフィルタリングは、後ではなくHNSW走査中に発生します。これは重要な違いです。ポストフィルタリングでは、要求した数より結果数が少なくなる可能性があります。プリフィルタリングは、制約に一致する k 件の結果を得られることを保証します。

フィルタリングDSLは表現力豊かです。

from qdrant_client.models import Filter, FieldCondition, MatchValue

results = client.search(
    collection_name="documents",
    query_vector=embedding,
    query_filter=Filter(
        must=[
            FieldCondition(key="category", match=MatchValue(value="engineering")),
            FieldCondition(key="year", range=Range(gte=2024)),
        ]
    ),
    limit=10,
)

Qdrantは同じクエリ内でdenseベクトルとsparseベクトルの両方を使用したネイティブハイブリッド検索もサポートしており、セマンティック理解とキーワード精度を組み合わせる際に有用です。

Chroma: 基本的だが使用可能

Chromaは where 句によるメタデータフィルタリングをサポートしています。

results = collection.query(
    query_embeddings=[embedding],
    where={"category": "engineering"},
    n_results=10,
)

単純なケースでは機能しますが、フィルタリングはベクトル検索の後に行われます。制限の厳しいフィルタと小規模なデータセットの場合、期待より少ない結果が返される可能性があります。sparseベクトルのサポートや組み込みのハイブリッド検索はありません。

pgvector: SQLがあなたのスーパーパワー

pgvectorはフィルタリングのためにSQLの全能力を継承しています。

SELECT content, embedding <=> $1 AS distance
FROM documents
WHERE category = 'engineering'
  AND created_at > '2024-01-01'
  AND content @@ to_tsquery('RAG & retrieval')
ORDER BY distance
LIMIT 10;

最後の行は、ベクトル類似度をPostgreSQLの組み込み全文検索と単一のクエリで組み合わせています。外部の検索エンジンは不要です。usersテーブルと結合してアクセス制御を行ったり、結果を集計したり、CTEを使用したり、SQLができることなら何でも可能です。

pgvector 0.8.0の反復スキャンも役立ちます。初期のHNSWスキャンで十分なフィルタ結果が返されない場合、部分的なセットを返すのではなく、自動的に検索を継続します。

結論: 大規模な複雑なメタデータフィルタリングでは Qdrant が勝利。 ハイブリッド検索の柔軟性（SQL + 全文検索 + ベクトルを1クエリで）では pgvector が勝利。Chromaのフィルタリングはプロトタイプ用にのみ適切です。

使用すべき時期：決定フレームワーク

こちらが決定木のバージョンです。アプリはすでにPostgresを使用していますか？ はいの場合、pgvectorから始めてください。成長しすぎた場合に後で移行できます。いいえの場合、プロトタイピングですか、それとも本番環境向けですか？ プロトタイピングならChroma。本番環境ならQdrant。

「シンプルに始めて、後で移行する」というアプローチは、3つすべてが標準的な埋め込み形式をサポートしているため有効です。それら間でのベクトルの移動は、アーキテクチャの書き換えではなく、データ移行です。

pgvectorscale要因：なぜPostgresが追いついているか

多くのチームの計算式を変えるため、これについて少し掘り下げる価値があります。

pgvectorscale以前、pgvectorに対する批判は常に「100万ベクトル未満では正常に動作するが、スケールしない」というものでした。それは真実でした。HNSWインデックスは完全にRAM上に存在し、データセットが利用可能なメモリを超えると、パフォーマンスは急落します。

StreamingDiskANNはこの方程式を変えます。グラフインデックスをRAMではなくSSDに保存することで、pgvectorscaleは99%の再現率で5000万ベクトルを471 QPSで処理できます。Statistical Binary Quantization (SBQ) は精度の損失を最小限に抑えてベクトルを圧縮し、積極的な圧縮であっても再現率は98.6%から96.5%にしか低下しません。

実際的な影響：Postgres上でRAGパイプラインを実行しているチームは、「事態が深刻になったとき」に専用ベクトルデータベースへの移行を計画する必要がなくなりました。多くのワークロードにおいて、pgvector + pgvectorscaleは真剣な選択肢です。

とはいえ、pgvectorscaleは銀の弾丸ではありません。これはTigerData（旧Timescale）の拡張機能であるため、彼らのDockerイメージまたはそれをバンドルするプロバイダーが必要です。2026年のリリースでは、MicrosoftのFiltered DiskANN研究に触発されたラベルベースのフィルタ付きベクトル検索がStreamingDiskANNに追加され、フィルタ付きクエリにおけるQdrantの長年のリードを狭めました。しかし、マルチテナント分離やネイティブなsparseベクトルサポートが必要な場合、Qdrantはまだ優位にあります。

Techsyがベクトルデータベースを選択する方法

クライアントのためにRAGパイプラインを構築する際、私たちの評価プロセスは以下のようになります。

1. 既存のスタックの監査。 チームがすでにPostgresを実行している場合、pgvectorがデフォルトの開始点です。明確な理由がない限り、インフラの複雑さを追加する意味はありません。
2. クエリパターンのプロファイリング。 高カーディナリティフィールドを使用した重いメタデータフィルタリング？ それはQdrantに向かいます。単純なセマンティック検索？ pgvectorまたはChromaで問題ありません。
3. スケール軌道の見積もり。 500万ベクトル未満で留まる？ どのオプションでも機能します。5000万+を計画？ ステップ2に応じてpgvectorscaleまたはQdrant。
4. チームの運用能力の確認。 2人のスタートアップがQdrantクラスターを管理すべきではありません。pgvectorを搭載したマネージドPostgresプロバイダーが通常正しい選択です。

私たちは3つすべてで本番環境のRAGシステムを構築してきました。正直な答えは、データベースの選択は、チャンキング戦略、埋め込みモデル、および取得パイプラインの設計ほど重要ではないということです。異なるチャンクサイズをテストするよりもQdrant vs pgvectorの議論に時間を費やしている場合、あなたは間違ったものを最適化しています。

RAGパイプラインの設計にお困りですか？ ベクトルストアの選択と取得設計は、私たちのAI統合サービスの一部です。お問い合わせいただければ、適切な基盤の選択とその周りの層の構築をお手伝いします。

よくある質問

pgvectorは本番環境のRAGに十分ですか？

はい、特にpgvectorscaleを使用する場合。StreamingDiskANNインデックスは、ベンチマークで専用ベクトルデータベースを上回るスループットレベルで、99%の再現率を持ちながら5000万+ベクトルを処理します。すでにPostgresを実行している場合、RAGのために別個のベクトルデータベースを追加する理由はほとんどありません。

Chromaは数百万のベクトルにスケールできますか？

Chromaは十分なRAMがあればシングルノードで数百万のベクトルを処理できますが、組み込みの水平スケーリングはありません。1台のマシンで保持できる範囲を超えるデータセットの場合、Qdrant、pgvector、またはマネージドサービスに移行する必要があります。

Qdrantはキーワードとのハイブリッド検索をサポートしていますか？

はい。Qdrantは同じコレクション内でdenseベクトルとsparseベクトルの両方をサポートしています。セマンティック類似度（dense）とキーワードマッチング（sparse）を組み合わせたハイブリッドクエリを実行し、それらの間の重み付けを制御できます。

各データベースにはどれくらいのRAMが必要ですか？

ベクトル数と次元数によります。大まかなガイドとして：1536次元の100万ベクトルは、HNSWを使用したQdrantまたはpgvectorで約6GBを占めます。ChromaはPythonのオーバーヘッドのため、わずかに多く使用します。pgvectorscaleのDiskANNインデックスは、インデックスをSSDに保存することでRAMの必要性を劇的に減らします。

後でこれらのデータベース間を移行できますか？

はい。3つすべてが標準的な浮動小数点配列で動作するため、ベクトルは移植可能です。インデックスを再作成し、クエリ層を適応させる必要がありますが、それはデータ移行であり、書き換えではありません。Qdrantの公式移行ツールのようなほとんどの移行ツールがこのプロセスを簡素化します。

LangChainおよびLlamaIndexと最も相性が良いのはどれですか？

3つすべてがLangChainおよびLlamaIndexとの公式統合を持っています。Chromaはチュートリアルでよくデフォルトとして使用されるため、開始するには最もスムーズです。Qdrantおよびpgvectorの統合は、本番環境使用のために同等に成熟しています。エコシステムのより広範な視点については、最高のRAGツールに関するガイドをご覧ください。

pgvectorとpgvectorscaleのどちらを使用すべきですか？

両方を使用してください。pgvectorはコアの vector タイプとHNSWインデックスを提供します。pgvectorscaleは大規模化におけるより良いパフォーマンスのために上にStreamingDiskANNを追加します。これらは代替品ではなく、補完的な拡張機能です。

Qdrantはセルフホストで無料ですか？

Apache 2.0ライセンスの下で完全に無料です。Qdrant Cloudは有料のマネージドオプションで、無料の1GBティアから始まります。セルフホスティングの場合、コンピューティングインフラのコストのみを支払います。

MilvusやWeaviateはどうですか？

どちらも堅実な代替案です。MilvusはGPUアクセラレーションを備えた非常に大規模（10億+ベクトル）でより強力です。Weaviateには素敵な組み込みのベクトル化パイプラインがあります。しかし、1億ベクトル未満のセルフホスト型RAGの場合、Qdrant、Chroma、およびpgvectorは、運用の複雑さが少ない状態で、大多数のユースケースをカバーします。

pgvectorは本番環境で並行RAGクエリを処理できますか？

はい。PostgreSQLは並行ワークロードのために設計されています。pgvectorは接続プーリング（PgBouncer）、読み取りレプリカ、およびMVCC並行性制御を継承します。高スループットのRAGの場合、pgvectorを接続プーラーと組み合わせ、shared_buffers と effective_cache_size をチューニングしてください。

最終結論

全体として: ほとんどのセルフホスト型RAGパイプラインにとって、pgvector + pgvectorscale が現実的な選択です。十分に高速で、数千万のベクトルまでスケールし、スタックをシンプルに保ちます。あなたはすでにSQLを知っています。あなたのチームはすでにPostgresを管理しています。サービスが1つ減るということは、午前2時に壊れるものが1つ減るということです。

高度なフィルタ付き検索、マルチテナンシー、またはベクトル検索がコア機能（支援機能ではない）である製品を構築している場合、Qdrant が正しい投資です。それが最も機能豊富なオープンソースベクトルデータベースであることには理由があります。

Chroma はプロトタイピングツールとしての地位を獲得しています。それを使用してRAGアプローチを検証し、異なるチャンキング戦略をテストし、取得品質を反復改善してください。本番環境の準備ができたら、他の2つのうちスタックに適合する方に移行してください。

最良のアドバイス？ 議論をやめて構築を始めましょう。Postgresがあるならpgvectorを選び、ないならQdrantを選び、RAGパイプラインを動作させてください。ベクトルストアは後でいつでも切り替えられます。埋め込みモデル、チャンク戦略、および取得ロジックの方がはるかに重要です。

ソース

• Qdrant Benchmarks
• Chroma 1.0 Release: 4x Faster
• pgvectorscale: StreamingDiskANN for PostgreSQL
• pgvector Is Now Faster than Pinecone at 75% Less Cost
• pgvector 0.8.0: Iterative Index Scanning
• Qdrant Pricing