2026 年のベクトル DB 市場の構図
- 年末まで「とりあえず Pinecone」だった局面は明確に終わった。2025 年の Pinecone Serverless への強制移行で料金体系が書き換わり、その一方で pgvector が 0.7 → 0.9 で一気に実用レベルへ追いつき、Qdrant は GPU インデックス構築を安定版に昇格させ、Weaviate はマルチテナンシーとハイブリッド BM25 を標準装備にした。Chroma 1.0 もようやく GA に達し、開発体験の良さで local-first のユースケースを取り戻している。
KGA では過去 12 か月で、日本国内の金融・製造・SaaS 顧客合計 14 プロジェクトでベクトル DB 選定に関わった。このうち 8 件が pgvector、3 件が Qdrant、2 件が Weaviate、1 件が Pinecone となり、2024 年の「Pinecone 7、Qdrant 3、pgvector 2、その他 2」からポートフォリオは大きく shift した。本稿では 5 種の 2026 年 4 月時点版を、100M ベクトル（1024 次元）規模のベンチマークと実運用の肌感で並べる。
インデックスアルゴリズム: HNSW vs IVF vs その他
ベクトル検索の核は ANN（近似最近傍）インデックスの選択だ。2026 年の実装地図は次のように整理できる。
- HNSW (Hierarchical Navigable Small World): メモリ上の多層グラフ。pgvector、Qdrant、Weaviate、Chroma、Pinecone の全てで第一選択。パラメータは `M`（各ノードの接続数）と `ef_construction`（構築時の探索幅）、クエリ時の `ef_search`。
- IVF (Inverted File Index): セントロイドでデータをバケット化。pgvector が ivfflat／ivfpq として提供。メモリ効率は良いが再現率と p99 が HNSW に劣るため 2026 年時点では新規採用は少ない。
- ScaNN / SPANN: Google 系の量子化ベース ANN。Vertex AI Vector Search と一部 OSS で採用。ディスク常駐データに強い。
- DiskANN / Vamana: ディスク常駐 HNSW の変種。Milvus 2.5 と Qdrant の on-disk モードが採用。1 ノードで数十億ベクトルを扱う場合の本命。
pgvector 0.9 で追加された HNSW iterative scan は、フィルタ条件付きクエリで再現率が落ちる従来の問題を解決した。`hnsw.iterative_scan = strict_order` を有効にすると、WHERE 条件を満たすまでグラフ探索を継続する。これまで「HNSW + WHERE」は ef_search を 10 倍以上に上げないと再現率が 80% 台に落ちていたが、iterative scan で 95% 以上を安定維持できる。
```sql -- pgvector 0.9 での HNSW + フィルタ CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops) WITH (m = 32, ef_construction = 200);
SET hnsw.iterative_scan = strict_order; SET hnsw.max_scan_tuples = 50000;
SELECT id, content, 1 - (embedding <=> $1::vector) AS similarity FROM documents WHERE tenant_id = $2 AND created_at > NOW() - INTERVAL '30 days' ORDER BY embedding <=> $1::vector LIMIT 20; ```
Qdrant 1.12 の目玉は GPU 上での HNSW 構築の安定化だ。A100／H100 上で 100M ベクトルの初期構築が 8 時間から 35 分に短縮された。推論時の検索自体は CPU のままだが、再インデックスのダウンタイムが劇的に縮む。
100M ベクトルでの p99 レイテンシ実測
KGA の検証クラスタ（1024 次元 float32、100M ベクトル、メモリ常駐、k=20）での計測値は次のとおり。
- pgvector 0.9 on Postgres 17 (r7i.16xlarge): ef_search=100 で再現率 97%、p50=18ms、p99=62ms。WHERE フィルタ付きでも p99=95ms に収まる。
- Qdrant 1.12 (i4i.8xlarge × 3, quantization int8): 再現率 96%、p50=6ms、p99=24ms。量子化で RAM は 1/4 に圧縮。
- Weaviate 1.28 (m7i.8xlarge × 3, PQ 有効): 再現率 95%、p50=9ms、p99=38ms。マルチテナント越しでも劣化はほぼ無い。
- Chroma 1.0 (単一ノード r7i.16xlarge, DuckDB ベース): 再現率 94%、p50=22ms、p99=110ms。100M は単ノードの実用限界。
- Pinecone Serverless (s1 pods 相当の抽象層): 再現率 95%、p50=30～45ms、p99=140ms。リージョン間差が大きい。
Qdrant の低レイテンシは scalar / product quantization のネイティブ実装によるところが大きい。int8 量子化で精度を 1～2% 譲りつつ、メモリフットプリントを 4 倍圧縮できるため、同一ハード上で 4 倍のベクトルを収容できる。pgvector でも halfvec 型（float16）は使えるが、int8 レベルの圧縮はまだ実験的。
シャーディングとマルチテナンシー戦略
数千テナントを抱える SaaS で頻繁に問題になるのがテナント分離だ。選択肢は 3 つある。
- テナント別コレクション／インデックス: 強い分離。テナント数が数百までなら Qdrant、Weaviate のマルチテナント機能が最適。
- 単一インデックス + メタデータフィルタ: シンプル。pgvector では Row-Level Security と組み合わせられるため、PostgreSQL 既存権限基盤と親和性が高い。
- ハイブリッド（ホットテナントは専用、ロングテールは共有）: 100 テナントが全トラフィックの 90% を食うような分布で有効。
Weaviate 1.28 の `multi-tenancy: true` モードでは、テナントごとに shard を持ち、ホット／コールドでメモリ／ディスクを自動振り分けする。10 万テナントを 10 ノードで運用する構成でも p99 は 50ms 以下を維持できる。
```python # Weaviate v4 クライアントでのマルチテナント from weaviate.classes.config import Configure, Multi
client.collections.create( name="Documents", multi_tenancy_config=Configure.multi_tenancy( enabled=True, auto_tenant_creation=True, auto_tenant_activation=True, ), vector_index_config=Configure.VectorIndex.hnsw( ef_construction=256, max_connections=32, quantizer=Configure.VectorIndex.Quantizer.pq(segments=128), ), )
collection = client.collections.get("Documents").with_tenant("acme-corp") collection.data.insert({"text": "...", "vector": embedding}) ```
ハイブリッドサーチ: BM25 + Dense
純粋なベクトル検索はキーワード一致で勝つべきクエリ（型番、固有名詞、略語）で負ける。2026 年時点、本番 RAG はほぼ全て BM25 と Dense のハイブリッドを採用する。
- pgvector: PostgreSQL のネイティブ全文検索（tsvector）と RRF（Reciprocal Rank Fusion）を SQL レベルで組む。
- Qdrant 1.12: `sparse-dense hybrid search` がネイティブ。SPLADE や BM25 ベクトルをそのまま混ぜられる。
- Weaviate 1.28: `hybrid()` クエリ一発。alpha パラメータで BM25:Dense の比率を制御。
- Pinecone Serverless: sparse-dense インデックスが統合済み。
Qdrant のハイブリッド実装例:
```python from qdrant_client import QdrantClient, models
client.query_points( collection_name="docs", prefetch=[ models.Prefetch(query=dense_vec, using="dense", limit=50), models.Prefetch(query=sparse_vec, using="bm25", limit=50), ], query=models.FusionQuery(fusion=models.Fusion.RRF), limit=20, ) ```
Pinecone Serverless の料金実態
Pinecone の 2025 年の料金改定で、読み書き単位課金（Read Unit／Write Unit）がコストの大部分を占めるようになった。100M ベクトル、1 日 500 万クエリ、月次 1000 万 upsert の想定で試算すると、Pinecone Serverless は約 $18,000/月、同規模の Qdrant セルフホスト（i4i.8xlarge × 3）は AWS 費用で約 $7,800/月、pgvector on RDS は $5,200/月となる。
マネージドの工数削減効果が月 $10,000 超の人件費に相当するかは組織次第だが、2026 年の流れとしては「PoC は pgvector で始め、100M を超えたら Qdrant セルフホストか Weaviate Cloud に移行、マルチリージョン冗長が必要な最終段階でのみ Pinecone」というパターンが定着している。
選定判断フローチャート
- 既存 PostgreSQL 資産がある、10M ベクトル以下 → pgvector 0.9
- 100M 以上、レイテンシ厳しい、セルフホスト許容 → Qdrant 1.12
- SaaS のマルチテナント、GraphQL で組みたい → Weaviate 1.28
- ローカル開発・プロトタイプ、ノートブック中心 → Chroma 1.0
- マルチリージョン SLA、運用チーム最小化 → Pinecone Serverless
ベクトル DB は 2026 年、「どれを選んでも動く」フェーズに入った。差が出るのは運用の手触りと TCO だ。KGA では半年前の選定を振り返ると、pgvector で始めた案件の 7 割はそのまま本番まで運用できており、「迷ったら pgvector、成長したら移行」が健全な初手と言える。