LabHub

ブログ

ベクトルDB地形図 2026 — Pinecone Serverless・Turbopuffer・pgvectorscale・Qdrant・Weaviate・Vespaを一枚にまとめるディープダイブ

2026-05-14 · 23 分で読めます · #vector-database#pinecone#turbopuffer#pgvector#qdrant#weaviate#milvus#vespa#rag#japanese

한국어English日本語

プロローグ — 2年で地形ががらりと変わった

2024年春にRAGパイロットを始めたとき、ベクトルDBの選択肢は単純だった。Pineconeは高いが運用は楽。Weaviateはモジュラーだが自己ホストは骨が折れる。Chromaはノートブック用のおもちゃ。pgvectorは「小規模専用」という相場観だった。

2026年5月時点、その通説のほとんどはもう正しくない。

この記事は昨年4月の「ベクトルDB比較 — Pinecone・Weaviate・Chroma・pgvector」の続編だ。あちらは入門用の比較、これは2026年5月時点の本番運用地形をコスト・アーキテクチャ・失敗事例で一枚にまとめるディープダイブ。

流れ:

  1. 何が変わったか — 価格崩壊とオブジェクトストレージ革命
  2. マネージドSaaS — Pinecone Serverless・Turbopuffer・Zilliz Cloud
  3. OSS専用エンジン — Qdrant・Weaviate・Milvus・Vespa・Vald
  4. Postgres陣営 — pgvector + pgvectorscale + Supabase・Neon・Tiger
  5. 組み込み・分析型 — Chroma・LanceDB・DuckDB VSS
  6. 汎用DBへのベクトル後付け — MongoDB Atlas・Couchbase・Elasticsearch/OpenSearch
  7. ハイブリッド検索の標準 — BM25 + 密 + リランカー
  8. コストマトリクス — 1Mベクトルで月いくら
  9. 意思決定図 — 「pgvector vs 専用」
  10. 運用アンチパターン
  11. エピローグ — チェックリストと次回予告

1. 何が変わったか — 価格崩壊とオブジェクトストレージ革命

1-1. 価格曲線

2023〜2024年のPineconeは p1.x1 ポッドが時間 0.10 ドル前後。1億ベクトルを安定運用すると月額4桁ドルが基本だった。2024年1月に発表された Serverless アーキテクチャ が全部ひっくり返した — コンピュートとストレージの分離、コールドデータをオブジェクトストレージへ、クエリ単位課金。2026年5月の標準価格(Standardプラン):

項目単価補足
Read1M read units あたり 8.25 USD1 RU ≈ 1KB ペイロード1検索
Write1M write units あたり 2 USDアップサート・削除を含む
StorageGB・月 0.33 USDメタデータ込み
予約 capacity別途時間課金高同時実行で発動
無料枠2GB・インデックス5本プロジェクト1、SLA・RBAC・サポートなし

小規模RAG(1Mベクトル、日次数万クエリ)は月5〜15ドルに落ちた。大規模はまだ高い。請求書が突然跳ねる原因はほぼ予約 capacity ライン — そこは目を離さない。

1-2. オブジェクトストレージ革命 — Turbopuffer

Simon Eskildsen が Cursor・Notion 配下に作った Turbopuffer がやったことは単純。「真実の源はS3・GCS、SSDはキャッシュだけ」。コストは TB・月 約 70 ドル、従来のSSD三重化(約600ドル)・RAMキャッシュ系(約1600ドル)に対して1〜2桁安い。

2026年5月の運用規模:

Zillizが「ストレージが全てではない — コールドミス時のレイテンシペナルティが大きい」と反論した。しかし 本番ワークロードの大多数はコールド寄り という事実が陣営を分けた。ロングテール検索・アーカイブ・多言語インデックスではTurbopufferモデルが圧倒的に安い。

1-3. 「とりあえずPostgres」運動

Timescale(現Tiger Data)が出した pgvectorscale が決定打。pgvectorの上に StreamingDiskANN インデックスを追加。5000万ベクトル・768次元で:

そこに Statistical Binary Quantization(SBQ)と Filtered DiskANN(ラベル前置フィルタをインデックスに統合)が乗る。2025年11月に v0.9.0 で PG18 と同時インデックスビルドに対応、2026年3月に TimescaleDB 2.26.0 と一緒に Tiger Cloud で展開された。

核心は短い — すでにPostgresを運用中なら、新しいDBを入れない。

2. マネージドSaaS — Pinecone Serverless・Turbopuffer・Zilliz Cloud

2-1. Pinecone Serverless

2026年5月時点で最も無難なマネージド既定値。無料枠でプロトタイプはほぼ無料、インフラ運用負担はゼロ。弱点は2つ:

いつ選ぶか:

2-2. Turbopuffer

「オブジェクトストレージ優先」という言葉自体を作った会社。趣味インデックスから4兆ドキュメントまで一つの価格表で運用する。2026年の公開ティア:

ストレージは GB あたり約 0.02 USD(S3・GCS パススルー)、SSD キャッシュ約 0.1 USD/GB、クエリ・書き込みは使用量ベース。コールド100倍、ウォーム6〜20倍安いという主張が Cursor・Notion の運用で裏付けられる。

弱点:

いつ選ぶか:

2-3. Zilliz Cloud(Milvus 2.6 マネージド)

Zilliz Cloud は 2026年1月に Milvus 2.6.x を GA。コンピュート 時間あたり 0.096 USD、ストレージ GB・月 0.02 USD。強みは2点:

いつ選ぶか:

3. OSS専用エンジン — Qdrant・Weaviate・Milvus・Vespa・Vald

3-1. Qdrant — Rust製、フィルタが強い

Qdrantの2026年は2大事件で語れる。

強み:

弱点:

3-2. Weaviate — モジュラー + マルチベクトル

Weaviate は 2026年時点で ハイブリッド検索・ColBERTマルチベクトル・リランカーモジュール の先頭にいる。BM25F + 密ベクトルを一つのクエリで束ね、融合方式・重み付けを設定するのが一級市民。リランカー・ジェネレータがモジュールで提供されるため、RAGパイプラインをDB内に部分的に吸収できる。

いつ選ぶか:

3-3. Milvus — スケールと GPU

OSS Milvus 2.6.x はより柔軟な CAGRA 配置(GPU+CPU)、ストレージ・インデックスノードの分離、軽量メタデータサービスを取り込んだ。原則自己ホスト可能だが、本番はほぼ Zilliz Cloud に流れる。

3-4. Vespa — 実時間検索 + ベクトルハイブリッド

Yahoo から独立した Vespa は 2026 年に「AI Search Platform」へリブランド。強みは「ベクトル + BM25 + テンソル + ML ランキングを1クエリで」。Spotify の検索が実時間 HNSW をこれで回している。

特徴:

いつ選ぶか:

3-5. Vald — Yahoo Japan の OSS

Vald は Yahoo JAPAN が NGT を基盤に作った Kubernetes ネイティブの ANN エンジン。日本国内の運用ではビリオン規模をミリ秒で捌いてきた。2024年以降のグローバル盛り上がりは落ち着いたが、K8s 親和・gRPC 優先設計は今でも価値がある。日本市場、または NGT アルゴリズムに依存する文脈で候補。

4. Postgres陣営 — pgvector + pgvectorscale + Supabase・Neon・Tiger

4-1. pgvector + pgvectorscale

2026年5月時点、「とりあえずPostgres」が冗談ではない理由。

自己ホスト時の弱点:

4-2. マネージド — Supabase・Neon・Tiger Cloud

いつ選ぶか:

5. 組み込み・分析型 — Chroma・LanceDB・DuckDB VSS

5-1. Chroma — 開発者親和、Cloud 合流

Chromaは1.0を遠く越え、2026年5月時点で1.5.9。2025年8月 Chroma Cloud GA、11月 BM25・SPLADE 疎ベクトルを一級扱い、2026年1月 CMEK、2月 メタデータ配列・contains 演算子。

いまだ最も「楽な」入口。pip install chromadb で5分でRAGデモ完成。ただし1億ベクトル以上では他を選ぶべき。

5-2. LanceDB — Lance カラムナ、組み込み優先

LanceDB は Lance カラムナ形式 の上に作られたインプロセス・ベクトルDB。コアは Rust、クライアントは Python・Node・Rust・REST。ポジショニングは明確 — 「データレイクの上のベクトル」。

強み:

いつ選ぶか:

5-3. DuckDB VSS — 分析のど真ん中でベクトル検索

DuckDB の VSS 拡張は ARRAY 列の上に HNSW インデックス を作る。INSTALL vss; LOAD vss; の2行で完了。array_cosine_distance、array_negative_inner_product がインデックスで加速される。

INSTALL vss;
LOAD vss;
CREATE TABLE docs (id INTEGER, embedding FLOAT[768]);
CREATE INDEX idx ON docs USING HNSW (embedding)
  WITH (metric = 'cosine');
SELECT id FROM docs
ORDER BY array_cosine_distance(embedding, ?::FLOAT[768])
LIMIT 5;

VSSはまだ experimental で本番非推奨。しかし 分析パイプラインの中のベクトル検索(データサイエンティストがノートブックで臨時インデックスを立てて探索する)用途では既に強力。

いつ選ぶか:

6. 汎用DBへのベクトル後付け — MongoDB Atlas・Couchbase・Elasticsearch/OpenSearch

汎用DBにベクトル列・インデックスを足す流れは、2024〜2026の間に事実上の標準になった。

この陣営の価値提案は単純 — 「すでに持っているDBにベクトル列を一つ足して終わり」。運用一貫性が最大の武器。

7. ハイブリッド検索の標準 — BM25 + 密 + リランカー

2026年に「ベクトル検索だけで十分」という主張はほぼ消えた。標準RAGパイプラインは3段。

クエリ
  ├─ BM25 検索(疎)──┐
  ├─ 密ベクトル検索 ──┼──> Reciprocal Rank Fusion または加重和
  └─ (任意)ColBERT/late ┘
                          │
                          ▼
                   候補 50〜200 件
                          │
                          ▼
                 Cross-Encoder リランカー
                 (Cohere Rerank 3.5、
                  Voyage Rerank 2.5、
                  Jina Reranker v3、
                  BGE Reranker)
                          │
                          ▼
                   上位 5〜10 件 → LLM

埋め込み・リランカーの風景(2026年4月 MTEB 基準)

運用Tips:

8. コストマトリクス — 1Mベクトルで月いくら

ざっくり自社見積もり。1Mベクトル、1536次元、日次1万クエリ、JP/US マネージド標準プランまたは同等の自己ホスト。実価格は契約と負荷形状で動く。

選択肢月額目安補足
Pinecone Serverless (Standard)5〜30 USD1M-1536D なら多くの場合無料枠に収まる
Turbopuffer (Launch)64 USD 固定 + 使用量複数インデックス合計でも Launch 内
Zilliz Cloud (Serverless小)30〜80 USDCU 時間 0.096 USD + ストレージ
Qdrant Cloud25〜70 USD単一ノード基準
Weaviate Cloud25〜80 USD有効モジュール次第で変動
pgvector + pgvectorscale on Tiger20〜60 USD時系列・トランザクション併用でコスパ良
Supabase (Pro + pgvector)25 USD〜認証・Realtime 込み
Neon (サーバーレス pgvector)19 USD〜ブランチングが武器
LanceDB OSS0 USDストレージコストのみ(S3 など)
Chroma OSS0 USDインフラコストのみ
DuckDB VSS0 USDインプロセス、実験的
MongoDB Atlas Vector30〜100 USDM10 インスタンス〜
Elasticsearch (Elastic Cloud)95 USD〜BM25 + kNN

1億ベクトル区間で差が開く。Turbopuffer・pgvectorscale・自己ホスト Milvus が QPS あたりの単価で強い。10億ベクトル超は事実上分散エンジン — Milvus・Vespa・Vald が候補。

9. 意思決定図 — 「pgvector vs 専用」

                          ┌──────────────────────────────┐
                          │ 10万ベクトル未満、         │──> Chroma / LanceDB / DuckDB VSS
                          │ プロトタイプ              │
                          └──────────────────────────────┘
                                       │
                                       ▼
                          ┌──────────────────────────────┐
                          │ すでに Postgres を運用中?    │
                          └─────────────┬────────────────┘
                                        │
                          はい ◀────────┴────────▶ いいえ
                          │                          │
                          ▼                          ▼
            ┌────────────────────────┐   ┌──────────────────────────┐
            │ 10億ベクトル未満 +      │   │ インフラチームなし +     │
            │ トランザクション・JOIN │   │ 「今四半期に成果」        │──> Pinecone Serverless
            │ → pgvector +            │   └─────────────┬────────────┘
            │   pgvectorscale         │                 │
            │   (Tiger / Supabase /   │                 ▼
            │    Neon)                │   ┌──────────────────────────┐
            └────────────────────────┘   │ コールド比率高 + コスト  │──> Turbopuffer
                                         │ センシティブ              │
                                         └─────────────┬────────────┘
                                                       │
                                                       ▼
                                         ┌──────────────────────────┐
                                         │ 自己ホスト OK +           │
                                         │ フィルタ重視              │──> Qdrant
                                         └─────────────┬────────────┘
                                                       │
                                                       ▼
                                         ┌──────────────────────────┐
                                         │ ColBERT マルチベクトル +  │
                                         │ モジュラー RAG           │──> Weaviate
                                         └─────────────┬────────────┘
                                                       │
                                                       ▼
                                         ┌──────────────────────────┐
                                         │ 1億+ + GPU インフラ       │──> Milvus / Zilliz
                                         └─────────────┬────────────┘
                                                       │
                                                       ▼
                                         ┌──────────────────────────┐
                                         │ 検索が本業 +              │
                                         │ ML ランキング統合         │──> Vespa
                                         └──────────────────────────┘

既定の分岐は単純。

  1. すでに Postgres があれば pgvector + pgvectorscale を最初に試す。RAGの9割はここで終わる。
  2. 運用人員がいなければ Pinecone Serverless。無料枠が広い。
  3. コールド比率が大きければ Turbopuffer。価格が桁違い。
  4. フィルタ重視は Qdrant、モジュラーRAGは Weaviate、スケール+GPUは Milvus/Zilliz、検索が本業なら Vespa。
  5. ノートブック・CLI・組み込みは Chroma・LanceDB・DuckDB VSS。

10. 運用アンチパターン

現場でよく見る事故。正直に書いておく。

11. エピローグ — チェックリストと次回予告

立ち上げ前チェックリスト

運用を始める前に自分に投げる12問。

次回予告

次回は 「RAG 評価パイプライン・ハンズオン — RAGAS・Ragas・Phoenix・LangSmith で retriever・reranker・generator を個別に計測する」。ベクトル DB を選んだら終わり、ではない。回答品質が落ちたとき、retrieval recall・rerank precision・generation faithfulness のどこで落ちたかを分離計測できないと、運用にならない。本記事で扱った全 DB が同じ評価フレームで比較可能になる。

参考 / References

コメント

まだコメントはありません。

ログインするとコメントできます