0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@0h-n0

Pinecone・Qdrant・Milvus・pgvector徹底比較：MLEのためのベクトルDB選定ガイド

0
Last updated at Posted at 2026-06-17

Pinecone・Qdrant・Milvus・pgvector徹底比較：MLEのためのベクトルDB選定ガイド

この記事でわかること

  • 主要ベクトルDB 7製品（Pinecone・Qdrant・Milvus・Weaviate・pgvector・LanceDB・Chroma）の性能・コスト・機能の定量比較
  • データ規模・チーム体制・予算に応じた選定フローチャートと判断基準
  • ハイブリッド検索（Dense + Sparse + Reranker）の2026年標準アーキテクチャと各DBの対応状況
  • pgvector 0.8のHNSW高速化により「専用ベクトルDBは本当に必要か？」を検証した結果
  • 本番環境でのコスト試算：マネージド vs セルフホスト、10Mベクトル〜1Bベクトルの実コスト

対象読者

  • 想定読者: RAGやAI Agentの検索基盤を設計・構築するMLE（Machine Learning Engineer）
  • 必要な前提知識:
    • Embeddingモデル（OpenAI text-embedding-3-small 等）の基本的な使い方
    • 近似最近傍探索（ANN）の概念（HNSW、IVF等のインデックス名を聞いたことがある程度）
    • PostgreSQLの基本操作（pgvector を評価する場合）

結論・成果

2026年6月時点のベンチマークと100以上のエンタープライズ導入事例を基に調査した結果、以下の選定指針が得られました。

  • 100Mベクトル以下 × PostgreSQL既存環境 → pgvector（HNSW）で十分。pgvectorscale併用時、50Mベクトルで471 QPS＠99%リコールを達成し、同条件のQdrant（41.47 QPS）を約11倍上回る報告がある
  • フィルタリング重視 × セルフホスト → Qdrantがp50レイテンシ4ms以下で、ペイロードフィルタの柔軟性も突出
  • 10億ベクトル超の大規模 → Milvusの分散アーキテクチャが唯一の実績ある選択肢
  • 運用ゼロ × プロトタイプ〜中規模 → Pinecone Serverless（p99レイテンシ7ms）、ただし大規模ではセルフホスト比5倍以上のコスト
  • エッジ・ローカル実行 → LanceDBがオブジェクトストレージ直接格納で月額$200〜500（10Mベクトル時）

ベクトルDBの4つのカテゴリを理解する

2026年のベクトルDB市場は、アーキテクチャと運用モデルによって4つのカテゴリに明確に分化しています。選定の第一歩は、自分のプロジェクトがどのカテゴリに適合するかを判断することです。

カテゴリ分類と各製品の位置付け

カテゴリ 代表製品 特徴 適合シーン
マネージドSaaS Pinecone インフラ管理不要、API駆動 プロトタイプ、運用チームなし
OSS専用DB Qdrant, Milvus, Weaviate 高性能、フル制御、セルフホスト可能 本番環境、コスト最適化
RDBMS統合 pgvector 既存PostgreSQLに追加、SQLで操作 PostgreSQL既存環境、統合クエリ
組み込み型 LanceDB, Chroma プロセス内実行、サーバー不要 エッジ、ローカル開発、プロトタイプ

この分類を念頭に置くと、「Pinecone vs Qdrant」のような単純比較ではなく、カテゴリをまたいだ比較は前提条件が異なることが理解できます。マネージドSaaSとセルフホストOSSでは、比較すべき軸そのものが変わります。

インデックスアルゴリズムの基礎

ベクトルDBの検索性能を左右する最大の要因はインデックスアルゴリズムです。主要な3つのアルゴリズムを理解しておくと、各製品のベンチマーク数値の意味が掴めます。

アルゴリズム 検索速度 メモリ効率 構築時間 代表的な採用製品
HNSW 高速（p50 〜5ms） メモリ常駐が必要 中程度 Qdrant, pgvector, Weaviate
IVF 中速（チューニング依存） HNSWより効率的 高速 Milvus
DiskANN 中速 SSD活用で大幅削減 低速 Milvus

注意点: ベンチマーク結果はアルゴリズム単体の性能ではなく、製品の実装品質・量子化戦略・I/O最適化の総合結果です。同じHNSWでも、pgvectorとQdrantでは実装の詳細が異なるため、性能差が生じます。

主要7製品の定量比較を実施する

ここからは各製品のベンチマーク数値、機能、コストを具体的に比較していきます。ベンチマーク条件が製品ごとに異なる点に注意してください。

性能ベンチマーク

以下は、2026年に公開されたベンチマーク報告から主要な数値を抽出したものです。

製品 QPS（目安） レイテンシ（p99） 最大検証規模 対応インデックス
Pinecone 非公開（SLA準拠） 7ms 10億+ 独自（Serverless）
Qdrant 30K〜80K 〜10ms 5000万 HNSW
Milvus 100K+ 〜30ms（p95） 10億+ HNSW, IVF, DiskANN
Weaviate 25K〜50K 〜50ms 5000万 HNSW
pgvector 5K〜15K 〜20ms 1億 HNSW, IVF
LanceDB バッチ向き ワークロード依存 10億+（S3上） IVF-PQ
Chroma 〜10K 〜50ms 1000万 HNSW

注意: QPS・レイテンシの数値はデータセット規模、ベクトル次元数（768, 1024, 1536等）、ハードウェア構成によって大きく変動します。上記は1024次元・10Mベクトル前後の一般的な構成での参考値です。ベンダーのベンチマークは自社に有利な条件で計測されていることが多いため、本番導入前には必ず自社データで検証してください。

pgvectorscale の注目すべき性能

pgvectorの性能は「PostgreSQLの拡張」という印象から過小評価されがちですが、Timescaleが開発したpgvectorscaleとの併用で状況が大きく変わっています。

Supabaseが公開したベンチマークでは、50Mベクトル・99%リコールの条件で、pgvectorscale（StreamingDiskANNインデックス）が471 QPSを記録しました。同条件でのQdrantは41.47 QPSであり、pgvectorscaleが約11倍のスループットを達成したと報告されています（出典: Supabase公式ブログ）。

# pgvector + HNSW でのベクトル検索例
# PostgreSQL 16 + pgvector 0.8.0 で動作確認

import psycopg2
from pgvector.psycopg2 import register_vector

conn = psycopg2.connect("postgresql://user:pass@localhost:5432/mydb")
register_vector(conn)
cur = conn.cursor()

# テーブル作成（1536次元、OpenAI text-embedding-3-small 想定）
cur.execute("""
    CREATE TABLE IF NOT EXISTS documents (
        id SERIAL PRIMARY KEY,
        content TEXT,
        metadata JSONB,
        embedding vector(1536)
    );
""")

# HNSWインデックスの作成
# m: グラフの接続数（大きいほど精度↑、構築時間↑）
# ef_construction: 構築時の探索幅（大きいほど精度↑、構築時間↑）
cur.execute("""
    CREATE INDEX ON documents
    USING hnsw (embedding vector_cosine_ops)
    WITH (m = 16, ef_construction = 200);
""")

# pgvector 0.8.0 の反復的インデックススキャンを有効化
# フィルタリング時に十分な結果が返らない問題を解決
cur.execute("SET hnsw.iterative_scan = relaxed_order;")

# メタデータフィルタ付きベクトル検索
query_embedding = [0.1] * 1536  # 実際にはEmbeddingモデルで生成
cur.execute("""
    SELECT id, content, embedding <=> %s::vector AS distance
    FROM documents
    WHERE metadata->>'category' = 'technical'
    ORDER BY embedding <=> %s::vector
    LIMIT 10;
""", (query_embedding, query_embedding))

results = cur.fetchall()
for row in results:
    print(f"ID: {row[0]}, Distance: {row[2]:.4f}")
    print(f"  Content: {row[1][:100]}...")

なぜpgvectorを最初に検討すべきか:

  • PostgreSQLを既に使っているなら、別途ベクトルDBを運用する必要がない（運用コスト削減）
  • ベクトル検索とリレーショナルクエリを1つのトランザクション内で実行できる
  • 既存のバックアップ・監視・認証の仕組みをそのまま利用可能

pgvectorの限界:

  • 100Mベクトルを超えると性能劣化が顕著になる
  • シャーディング（水平分割）のネイティブサポートがない
  • 専用ベクトルDBと比較して、高度なフィルタリング性能で劣る場合がある

Qdrant：フィルタリング性能とRust実装の優位性

Qdrantはフィルタ付き検索（ペイロードフィルタ）において他製品を上回る性能を発揮します。これは、Rust実装によるメモリ効率と、ペイロードインデックスの最適化によるものです。

# Qdrant でのハイブリッド検索（Dense + Sparse）例
# qdrant-client 1.12.x で動作確認

from qdrant_client import QdrantClient, models

client = QdrantClient(url="http://localhost:6333")

# Dense + Sparseベクトルの両方を持つコレクション作成
client.create_collection(
    collection_name="articles",
    vectors_config={
        "dense": models.VectorParams(
            size=1536,
            distance=models.Distance.COSINE,
        )
    },
    sparse_vectors_config={
        "sparse": models.SparseVectorParams(
            index=models.SparseIndexParams(on_disk=False)
        )
    },
)

# ペイロードインデックスの作成（フィルタ高速化の鍵）
client.create_payload_index(
    collection_name="articles",
    field_name="category",
    field_schema=models.PayloadSchemaType.KEYWORD,
)

# ペイロードフィルタ付きベクトル検索
results = client.query_points(
    collection_name="articles",
    query=[0.1] * 1536,  # 実際にはEmbeddingで生成
    using="dense",
    query_filter=models.Filter(
        must=[
            models.FieldCondition(
                key="category",
                match=models.MatchValue(value="machine-learning"),
            ),
            models.FieldCondition(
                key="published_at",
                range=models.Range(gte="2025-01-01"),
            ),
        ]
    ),
    limit=10,
)

for point in results.points:
    print(f"ID: {point.id}, Score: {point.score:.4f}")

Qdrantが適するケース:

  • メタデータフィルタリングが検索精度に直結するマルチテナントSaaS
  • Rust/Goのバックエンドと組み合わせたエッジデプロイ
  • 月額予算$100以下でセルフホストしたい（1GBまで無料のクラウド版あり）

Qdrantの制約:

  • 50Mベクトルを超えると性能が低下する傾向がある
  • Milvusほどのインデックスアルゴリズムの選択肢がない（HNSW中心）

Milvus：10億ベクトル超のスケーラビリティ

10億ベクトルを超える規模では、Milvusの分散アーキテクチャが現時点で唯一の実績ある選択肢です。コンピュートとストレージの分離設計により、水平スケーリングが可能です。

# Milvus での大規模コレクション作成例
# pymilvus 2.5.x で動作確認

from pymilvus import (
    connections, Collection, FieldSchema,
    CollectionSchema, DataType, utility
)

connections.connect(host="localhost", port="19530")

# スキーマ定義
fields = [
    FieldSchema(name="id", dtype=DataType.INT64,
                is_primary=True, auto_id=True),
    FieldSchema(name="text", dtype=DataType.VARCHAR, max_length=512),
    FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=1536),
    FieldSchema(name="category", dtype=DataType.VARCHAR, max_length=64),
]
schema = CollectionSchema(fields, description="Large-scale document store")

# コレクション作成（パーティション分割でスケール）
collection = Collection(name="documents", schema=schema)

# IVF_FLATインデックス: 大規模データ向け
# nlist: クラスタ数（データ量の平方根が目安）
index_params = {
    "index_type": "IVF_FLAT",
    "metric_type": "COSINE",
    "params": {"nlist": 4096}  # 10M〜100Mベクトル向け
}
collection.create_index(
    field_name="embedding",
    index_params=index_params
)

# 検索（nprobe: 探索クラスタ数。大きいほど精度↑、速度↓）
collection.load()
search_params = {"metric_type": "COSINE", "params": {"nprobe": 64}}

results = collection.search(
    data=[[0.1] * 1536],
    anns_field="embedding",
    param=search_params,
    limit=10,
    expr='category == "ml-paper"',  # メタデータフィルタ
    output_fields=["text", "category"]
)

for hits in results:
    for hit in hits:
        print(f"ID: {hit.id}, Distance: {hit.distance:.4f}")
        print(f"  Text: {hit.entity.get('text', '')[:100]}")

Milvusが必要なケース:

  • ECサイトの商品ベクトル（数億SKU）
  • 大規模ログの類似検索（セキュリティ、障害分析）
  • マルチモーダル検索（画像 + テキストを統合した大規模インデックス）

Milvusの制約:

  • 分散クラスタの構築・運用にデータエンジニアリングの専門知識が必要
  • etcd、MinIO、Pulsarなどの依存コンポーネントが多く、運用の複雑さが増す
  • 小規模データ（100万以下）では過剰スペック

コスト比較：10Mベクトル環境での月額試算

コストは選定の決定打になることが多い要素です。以下は1024次元・10Mベクトル・1000 QPS（p99 < 100ms）条件での月額コスト試算です。

製品 月額コスト（概算） 内訳 備考
pgvector $45〜100 RDS/Cloud SQL利用 既存PostgreSQLなら追加コスト最小
LanceDB $200〜500 S3ストレージ + コンピュート オブジェクトストレージ直接格納
Qdrant Cloud $25〜100 1GB無料、以降従量制 小規模なら無料枠で十分
Milvus（セルフホスト） $200〜400 EC2/GKEインスタンス 分散構成の運用コスト別途
Weaviate Cloud $200〜500 従量制 ハイブリッド検索込み
Pinecone Serverless $70〜350 $0.33/GB + RU課金 実コストは見積もりの2.5〜4倍の報告あり

注意: Pineconeの料金ページの見積もりと実際の月額請求の差が平均2.5〜4倍になるという報告があります（出典: LeanOps）。RU（Read Units）の消費量が予測しにくいことが主因です。大規模導入前にはPoC期間を設け、実際のコストを計測することを推奨します。

ハイブリッド検索アーキテクチャを設計する

2026年のRAGにおいて、ベクトル検索単体（Dense Retrieval）だけでは検索精度が不十分なケースが多く報告されています。固有名詞、エラーコード、製品型番などのキーワード完全一致が求められるクエリでは、Sparse Retrieval（BM25やSPLADE）との組み合わせが標準構成になっています。

Dense + Sparse + Rerankerの3段構成

各ベクトルDBのハイブリッド検索対応状況

製品 Dense Sparse（BM25） Sparse（SPLADE） ネイティブRRF Reranker統合
Qdrant ○ ○（外部） ○（ネイティブ） ○ ○（Cohere等）
Weaviate ○ ○（ネイティブ） △（外部） ○ ○
Milvus ○ ○（ネイティブ） ○ ○ △（外部）
Pinecone ○ ○（ネイティブ） △ △ ○
pgvector ○ ○（pg_trgm/tsvector） △（外部） △（SQL実装） △（外部）

最初に試すべき構成 — Qdrantでのハイブリッド検索例を見てみましょう。

# Qdrant でのハイブリッド検索（Dense + Sparse + RRF）
# qdrant-client 1.12.x で動作確認

from qdrant_client import QdrantClient, models

client = QdrantClient(url="http://localhost:6333")

# Prefetch（第1段階）で Dense と Sparse を並列実行し、
# Fusion（第2段階）で RRF により統合する
results = client.query_points(
    collection_name="articles",
    prefetch=[
        # Dense検索: セマンティック類似度
        models.Prefetch(
            query=[0.1] * 1536,  # Embeddingベクトル
            using="dense",
            limit=20,
        ),
        # Sparse検索: キーワード一致（SPLADE等で生成）
        models.Prefetch(
            query=models.SparseVector(
                indices=[100, 500, 1200, 3400],
                values=[0.8, 1.2, 0.5, 0.9],
            ),
            using="sparse",
            limit=20,
        ),
    ],
    # RRF（Reciprocal Rank Fusion）でスコア統合
    query=models.FusionQuery(fusion=models.Fusion.RRF),
    limit=10,
)

なぜRRF（Reciprocal Rank Fusion）が標準になったか:

DenseとSparseの生スコアは値域が異なるため、単純な加重平均では適切に統合できません。RRFはスコアではなく**順位（rank）**に基づいて統合するため、スコアの正規化が不要です。計算式は 1 / (k + rank) で、kは通常60が使われます。

ハイブリッド検索のよくある間違い:

最初は「DenseとSparseの重み比を5:5にすればよい」と考えがちですが、ドメインによって最適比率は大きく異なります。技術文書（固有名詞・エラーコードが多い）ではSparse比率を高め（Dense 4:Sparse 6）に、カジュアルなFAQ（言い換えが多い）ではDense比率を高め（Dense 7:Sparse 3）にするのが実務的な知見です。

選定フレームワークを適用する

ベンチマーク数値だけでベクトルDBを選ぶのは危険です。本番環境では、性能以外の要因が選定を左右することが少なくありません。以下の6軸で評価することを推奨します。

6軸評価フレームワーク

評価軸 質問 pgvector Qdrant Milvus Pinecone
1. データ規模 1年後のベクトル数は？ 〜100M 〜50M 1B+ 1B+
2. 検索パターン フィルタの複雑さは？ SQL WHERE句 ペイロードフィルタ 式フィルタ メタデータフィルタ
3. 運用体制 インフラチームはいる？ DBA活用可 中程度 高い専門性必要 不要
4. コスト感度 月額上限は？ 低 低〜中 中（セルフホスト） 高
5. 既存スタック 何と統合する？ PostgreSQLエコシステム REST/gRPC Python SDK REST API
6. ハイブリッド検索 BM25/SPLADEは必要？ tsvector併用 ネイティブSparse ネイティブSparse 制限あり

実際のプロジェクトでの選定例

ケース1: スタートアップのRAGチャットボット（ベクトル数 500万、チーム3名）

  • PostgreSQLを既に使用 → pgvectorを選択
  • 理由: 追加のインフラ不要、既存のバックアップ・監視を流用
  • 結果: 月額追加コスト$0（既存RDSインスタンスで十分な余裕）

ケース2: ECサイトの商品レコメンド（ベクトル数 2億、MLチーム10名）

  • 高度なフィルタリング（カテゴリ×価格帯×在庫状況）が必須 → Milvusを選択
  • 理由: IVFインデックスでメモリ効率を確保しつつ、パーティション分割で規模対応
  • 結果: セルフホストで月額$2,000。Pineconeの見積もりは$8,000超だった

ケース3: 社内文書検索SaaS（テナントごとに100万ベクトル、50テナント）

  • マルチテナント分離とフィルタ性能 → Qdrantを選択
  • 理由: テナントごとのペイロードフィルタが高速、名前空間で論理分離
  • 結果: p50レイテンシ3ms、月額$150（セルフホスト、GCE e2-standard-4）

よくある問題と解決方法

ベクトルDB導入後に発生しがちな問題と、その対処法をまとめます。

問題 原因 解決方法
検索精度（リコール）が低い HNSWパラメータ（ef_search）が小さすぎる ef_searchを段階的に増やす（64→128→256）。精度と速度のトレードオフを計測
フィルタ付き検索で結果が足りない Pre-filtering でベクトル候補が刈り込まれすぎ pgvector 0.8.0のhnsw.iterative_scanを有効化。Qdrantではペイロードインデックスを追加
インデックス構築に時間がかかる データ量に対してパラメータが過剰 m（接続数）を32→16に下げる。並列構築オプション（pgvector: parallel_workers）を利用
メモリ不足でOOM 全ベクトルをメモリ上に展開 量子化（Scalar/Binary Quantization）を適用。pgvectorscaleのDiskANNも選択肢
Pineconeのコストが想定の3倍 RU消費量の見積もり不足 事前にPoC期間（2週間）で実コストを計測。閾値超過時のアラート設定
ハイブリッド検索の精度が出ない Dense/Sparseの統合方法が不適切 RRFに切り替え。ドメイン別の最適比率をA/Bテストで検証

まとめと次のステップ

まとめ:

  • ベクトルDB市場は「マネージドSaaS」「OSS専用DB」「RDBMS統合」「組み込み型」の4カテゴリに分化しており、カテゴリ選択が最初の判断ポイント
  • PostgreSQL既存環境なら pgvector から始めるのが2026年の現実的な推奨。pgvectorscale併用で50Mベクトル・99%リコール時に471 QPSという報告があり、多くのユースケースで専用ベクトルDBが不要
  • ハイブリッド検索（Dense + Sparse + Reranker）が2026年のRAG標準構成。RRFによるスコア統合が実装の容易さと精度のバランスで推奨
  • コスト面では、マネージドSaaS（Pinecone）は10Mベクトル超でセルフホストの2.5〜5倍になる報告があり、規模に応じた再評価が必要
  • 「専用ベクトルDBが必要」と判断できるのは、100M超のスケール、高度なフィルタリング、分散処理のいずれかが明確に要件となった場合

次にやるべきこと:

  1. 自社のベクトル数を見積もり（現在＋1年後）、上の選定フローチャートでカテゴリを絞る
  2. 候補2〜3製品で、自社データを使ったベンチマーク（QPS、リコール、レイテンシ）をPoCとして実施する
  3. ハイブリッド検索を構成する場合、まずRRF（k=60）から開始し、ドメイン固有のチューニングはA/Bテストで進める

参考

注意: この記事はAI（Claude Code）により自動生成されました。内容の正確性については複数の情報源で検証していますが、実際の利用時は公式ドキュメントもご確認ください。

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?