Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

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

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

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

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

Pinecone Serverless が価格曲線を崩した。無料枠 2GB・インデックス5本、標準価格は read 1M あたり 8.25 ドル、write 1M あたり 2 ドル、ストレージ GB/月 0.33 ドル。小規模RAGは実質無料。
Turbopuffer がS3上に2.5兆ドキュメントを乗せ、「オブジェクトストレージ + SSDキャッシュ」を業界標準パターンに引き上げた。Cursor・Notionが本番運用中。
pgvectorscale(Timescale改めTiger Data)が StreamingDiskANN を投入。Cohere 5000万ベクトル・768次元の自己ホストで、Pinecone s1 比 p95 28 倍低レイテンシ、75% 安い。
Qdrant はv1.17でRocksDBを丸ごと撤去、自社ストレージエンジンgridstoreへ。2026年3月にシリーズB 5000万ドル調達。
DuckDB VSS 拡張が分析ワークフローの中にHNSWを差し込んだ。「データパイプラインの中でベクトル検索」が現実に。
Vespa は「AI Search Platform」としてリブランド。Spotifyが実時間HNSWを本番で回している。
ハイブリッド検索(BM25 + 密 + リランカー)は事実上の標準。Cohere Rerank 3.5・Voyage Rerank 2.5・Jina Reranker v3・BGE-M3 がそれぞれ正当な位置を占めた。

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

流れ:

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

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

1-1. 価格曲線

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

項目	単価	補足
Read	1M read units あたり 8.25 USD	1 RU ≈ 1KB ペイロード1検索
Write	1M write units あたり 2 USD	アップサート・削除を含む
Storage	GB・月 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月の運用規模:

ドキュメント 4 兆+
秒間書き込み 1000 万+、クエリ 2.5 万+
2024年7月時点でクエリ単価を最大 94% 引き下げ

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

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

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

p95 レイテンシ: Pinecone s1 比 28 倍低い
スループット: 16 倍高い
AWS EC2 自己ホスト時 99% recall でコスト 75% 削減

そこに 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つ:

ロックイン: インデックス形式は外部と互換性がない。移行は一つずつアップサート。
高同時実行で請求書ジャンプ: 予約 capacity 課金が別計測。エージェントが秒間数十クエリ叩くワークロードで突然跳ねる。

いつ選ぶか:

インフラチームのいないスタートアップ + 1M〜10M ベクトル
「今四半期に結果を出す」運用人員ゼロ
マルチリージョン・HA が SLA 要件

2-2. Turbopuffer

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

Launch: 月 64 USD
Scale: 月 256 USD
Enterprise: 別途

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

弱点:

レイテンシ分布: キャッシュミスで S3 フェッチが入って p99 がスパイクする。実時間レコメンドには非推奨。
エコシステム: Pinecone・Qdrant ほど統合・チュートリアルは厚くない。

いつ選ぶか:

100M+ ベクトル + コールド比率が高い
コスト敏感な検索・アーカイブ
「クエリ 200ms くらいなら許容」

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

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

GPUインデックス CAGRA(NVIDIA): 1億ベクトルを単一GPUノードで数十万QPS
GPU/CPUハイブリッド配置: GPUでグラフ構築、CPUで検索

いつ選ぶか:

100M〜10B ベクトル + GPUインフラを確保できる
分当たり数万クエリのマルチテナント SaaS
Spark・NVIDIA RAPIDS など既存パイプラインと組み合わせ

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

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

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

v1.17でRocksDB撤去: 自社ストレージgridstoreに置換。v1.15からv1.17への直接アップグレードは不可、1段ずつ。
シリーズB 5000万ドル(2026年3月): エンタープライズ営業を本格化。

強み:

ペイロードフィルタがインデックスと統合: category = 'X' AND created_at > '2026-01-01' のような精密フィルタで Weaviate・Pinecone より速い事例が多い。
Rustネイティブ: メモリ安全 + 単一バイナリ配布。Helm チャート1行で完結。
シャーディング・レプリケーション: 自己ホストでも運用しやすい。

弱点:

モジュラーRAG(Weaviateのリランカー・ジェネレータモジュールのような)はない。外部パイプラインが必要。

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

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

いつ選ぶか:

GraphQL 親和、「DB が RAG パイプラインの一部を担う」が許容
ColBERT v2 のような late-interaction マルチベクトル
ハイブリッド検索を1クエリで

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 をこれで回している。

特徴:

テンソルストレージ: テキスト・画像・数値の多次元表現を一箇所に
ランキング関数が一級市民: ML ランキングがDB側で実行
運用難度が最高: Vespa は軽くない。フルスタックの検索チームが要る。

いつ選ぶか:

検索が本業のチーム
レコメンド・ランキング・ハイブリッドを1クエリに束ねたい
Lucene・Solr 出身のメンバーがいる

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」が冗談ではない理由。

pgvector 0.9.x: HNSW + IVFFlat。トランザクション・JOIN・JSONB と同じ場所で扱える。
pgvectorscale: StreamingDiskANN インデックス。5000万ベクトル・768次元で Pinecone s1 比 p95 28 倍低、75% 安い。
Filtered DiskANN: ラベル前置フィルタをインデックス内に。マルチテナントRAGの「tenant_id = X AND 埋め込み類似」が速い。
SBQ(Statistical Binary Quantization): メモリ占有を1/32まで圧縮。

自己ホスト時の弱点:

HNSWビルドに時間がかかる(数千万ベクトルで数十分〜数時間)。
HA・レプリケーションは Postgres 運用の延長 — 楽ではない。
VACUUM・pg_repack 戦略をベクトルインデックス視点で再設計する必要がある。

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

Supabase: pgvector を一級市民として扱う BaaS。認証・Realtime・Edge Functions まで一式。1億ベクトルまで費用対効果が良い。
Neon: サーバーレス Postgres + pgvector。ブランチング・コピーオンライトが RAG 実験で強い。
Tiger Cloud(旧 Timescale): pgvectorscale を一級で運用する場所。時系列+ベクトルが最もなめらか。

いつ選ぶか:

すでに Postgres 運用中 + 1B ベクトル未満
トランザクション・関係データと同じトランザクションで扱う必要がある
インフラチームが新DB導入を拒否(現実)

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。ポジショニングは明確 — 「データレイクの上のベクトル」。

強み:

インプロセス + ゼロコピー: サーバなしで速い
カラムナ分析: ベクトル・テキスト・メタデータを1ファイルに、SQL・DataFrame で問い合わせ
バージョニング: Lance 形式がトランザクションとバージョン管理を持つ

いつ選ぶか:

ノートブック・CLI・ローカル RAG
データレイク(S3・GCS)の上にベクトルを置きたい
マルチモーダル ML ワークフロー

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

いつ選ぶか:

データ分析パイプライン + 臨時ベクトル検索
「ETLを1回回し、インデックスを作り、検索し、レポートを書く」

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

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

MongoDB Atlas Vector Search: マネージド。ドキュメント+ベクトルを同じコレクションに。ドキュメントDBユーザーには楽。
Couchbase Vector Search: 同じくマネージド。FTS+ベクトル。
Elasticsearch/OpenSearch kNN: BM25+密ベクトルのハイブリッド。運用負担はあるが、すでに ES を運用しているなら自然な選択。
Redis Stack のベクトルインデックス: キャッシュ・セッション+ベクトル。小規模ホットデータで速い。

この陣営の価値提案は単純 — 「すでに持っている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 基準)

埋め込み — voyage-3-large(Voyage AI): retrieval ほぼ単独首位
NV-Embed-v2: MTEB 全体平均で1位級
OpenAI text-embedding-3-large: 汎用既定値
Cohere embed-v3 + Rerank v3.5: ペア運用で強い
BGE-M3: 100以上の言語、多言語の自己ホスト標準
Nomic Embed v2: 多言語・低コスト
Jina Reranker v3: BEIR nDCG@10 で 61.94、188ms
Cohere Rerank 3.5 / Voyage Rerank 2.5: 平均 600ms 前後

運用Tips:

BM25を切るな。固有名詞・コード・略語で密ベクトルは弱い。
リランカーは必ず cross-encoder。bi-encoder を2回回すのは違う。
埋め込みモデルは入れ替わる。完全再インデックスのコストを最初から織り込む。

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

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

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

既定の分岐は単純。

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

10. 運用アンチパターン

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

埋め込みモデルのサイレント差し替え: text-embedding-ada-002 から voyage-3-large に変えて再インデックスを忘れると、コサイン空間がずれて検索品質が崩壊する。必ず再インデックス + A/B 検証。
BM25をオフ: コード・固有名詞・略語で密ベクトルは弱い。社内wikiで K8s・pgbouncer・RAGAS がヒットしないのはほぼこれ。
リランカーを飛ばす: top-50 候補を cross-encoder で再順位付けしないと、RAG 回答品質の30%以上を捨てている。
HNSW の M・ef_construction を既定値のまま: 小規模では差が見えないが、1M を超えると recall に差が出る。次元・分布・クエリ形状でチューニング。
フィルタをインデックス外で: Qdrant・pgvectorscale の強みは フィルタをインデックス内に。マルチテナント RAG では tenant_id をペイロードフィルタとしてインデックスに含める。
メタデータに BLOB: ベクトル DB に本文・画像を入れると read unit が爆発。参照のみ置いて本体はオブジェクトストレージ。
リトライ・バックオフなし: マネージド SaaS は 429 を返す。指数バックオフ + ジッターは必須。
モニタリング=平均レイテンシだけ: p50 はあまり意味がない。p95・p99・recall@k を並べる。
ロックインを軽視: Pinecone の移行は一つずつアップサート。埋め込み元データは常に S3・GCS にも別保管。
「RAGだから全部インデックスに突っ込む」: 検索プールの50%がノイズなら、どのDBを使っても回答品質は崩れる。チャンク・選別戦略がDB選定より先。

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

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

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

次回予告

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

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

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

1-1. 価格曲線

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

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

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

2-1. Pinecone Serverless

2-2. Turbopuffer

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

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

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

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

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

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

3-5. Vald — Yahoo Japan の OSS

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

4-1. pgvector + pgvectorscale

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

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

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

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

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

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

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

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

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

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

10. 運用アンチパターン

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

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

次回予告

参考 / References