ベクターデータベース 2026 完全ガイド - Pinecone · Weaviate · Qdrant · Milvus · pgvector · LanceDB · Chroma · FAISS · DiskANN 徹底解説

はじめに — 2026年5月、ベクターDBは「汎用インフラ」になった

2023年までベクターデータベースは「RAGを作りたいけれどembeddingをどこに入れる?」という問いに答えるための新興カテゴリだった。2026年5月の今、その問いは決着した。RAGは成熟し、ベクター検索はあらゆるOLTP/OLAP DBで標準オプションとなり、ハイブリッド検索(BM25 + dense vector + リランカ)が標準になった。

本稿はマーケティングマトリクスではない。「今のプロダクションでどのベクターDBがどの位置にあるか」を正直に書く。Pinecone Serverless v3、Weaviate 1.30、Qdrant 1.13、Milvus 2.5 + Zilliz Cloud、Chroma、LanceDB、pgvector 0.8 + pgvectorscale 0.6 + ParadeDB、Vespa、OpenSearch k-NN、Redis Vector、MongoDB Atlas Vector、Couchbase、SingleStore、Turbopuffer、Marqo、Vald、NGT、FAISS、ScaNN、DiskANN、Annoy、DuckDB VSS、sqlite-vec、jinaのHnswLib利用まで、実APIと一緒に比較する。

ベクターDB 2026の地形 — 5つのトラックに分解する

まず全体像。2026年のベクターDB市場は次の5トラックに分かれた。

1. 専業(ピュアプレイ)ベクターDB: Pinecone、Weaviate、Qdrant、Milvus、Chroma、LanceDB、Turbopuffer、Marqo
2. リレーショナルDBのベクター拡張: pgvector + pgvectorscale、ParadeDB、SingleStore、Oracle 23ai、SQL Server 2025
3. 検索エンジンのベクター拡張: Elasticsearch dense_vector、OpenSearch k-NN、Vespa、Solr
4. 汎用NoSQLのベクター拡張: MongoDB Atlas Vector、Redis Vector、Couchbase、DynamoDB(2025 GA)
5. 組み込み / ライブラリ: FAISS、ScaNN、DiskANN、Annoy、NGT、HnswLib、Vald、DuckDB VSS、sqlite-vec

同じANNアルゴリズム(多くはHNSW)を使っていても、運用モデル、価格、マルチテナンシ、ハイブリッド検索のサポートで大きく分かれる。下からトラックごとに見る。

ANNアルゴリズム 1 — HNSWが事実上の標準になった理由

ANN(Approximate Nearest Neighbor)の2026年の標準は HNSW(Hierarchical Navigable Small World) だ。Yu. Malkov と D. Yashunin による2016年の論文が出発点で、多層グラフ上の貪欲探索を行う。

• レイヤー0: すべてのノード。最も密な近傍接続。
• 上位レイヤー: 確率的にノードを昇格させる。上に行くほどスパースになる。
• 探索: 最上位レイヤーから始めて貪欲に下る。各レイヤーで ef サイズの候補キューを保つ。

長所は 挿入・削除・探索がすべてグラフ操作なので動的データに強いこと。短所は メモリ使用量が大きいこと。1億の768次元float32ベクター + HNSW(M=16)で約350GBのRAMを消費する。

Pinecone、Weaviate、Qdrant、Milvus、pgvector 0.8、Elasticsearch、OpenSearch、Redis、Chroma、LanceDB、Vespaのすべてが既定または選択肢としてHNSWを提供する。

ANNアルゴリズム 2 — IVF · IVF-PQ · DiskANN · ScaNN の居場所

HNSWが標準とはいえ、他のアルゴリズムも生きている。

• IVF(Inverted File Index): k-meansで空間を nlist セルに分割し、クエリでは nprobe セルだけ見る。MilvusとFAISSのクラシック選択肢。
• IVF-PQ: IVF + Product Quantization。ベクターをPQコードに圧縮しメモリを1/8〜1/32に削減。10億超では必須。
• DiskANN(Microsoft Research): NVMe SSD向けのグラフインデックス。10億ベクターを単一ノードで配信。pgvectorscaleのStreamingDiskANNが採用。
• ScaNN(Google): 非対称量子化 + 木の組み合わせ。TensorFlow親和。精度/速度カーブが優秀。
• Annoy(Spotify): 乱択射影フォレスト。mmap親和。静的インデックス向き。
• NGT(Yahoo Japan): ONNGグラフ。Valdクラスタの中核。

簡易ピッカーは次の通り。

• 1千万ベクター未満、動的書き込み: HNSW
• 1億超、メモリ圧迫: IVF-PQ または DiskANN
• 読み取り専用の大規模: ScaNN、Annoy

リコール vs レイテンシ vs コスト — ann-benchmarksの現実

ann-benchmarks.com の2026年5月のデータをGIST-960-1Mで圧縮すると次の通り。

• HNSW(M=16、ef=200): recall@10 0.99、p99 1.2ms、RAM 4GB
• IVF-PQ(nlist=4096、nprobe=64、m=32): recall@10 0.93、p99 0.9ms、RAM 0.5GB
• DiskANN(R=64、L=100): recall@10 0.98、p99 4ms、RAM 1GB + SSD
• ScaNN(reorder=200): recall@10 0.99、p99 0.6ms、RAM 3GB

ポイントは「フリーランチはない」こと。リコールを0.95から0.99に引き上げると、レイテンシは2〜5倍、メモリは1.5〜3倍になるのが普通だ。プロダクションでは recall@10 = 0.95 で十分な場合が多い。

Pinecone Serverless v3 — マネージドのデフォルト

Pineconeは2024年1月にServerlessをGAし、2025年Q4にv3で ストレージとコンピュートの完全分離を完成させた。2026年5月時点で最も「とりあえず使える」マネージド選択肢だ。

• インデックス作成にはdimension、metric(cosine/dotproduct/euclidean)、cloud(aws/gcp/azure)、regionだけ指定。
• バックエンドは独自ANN(HNSW亜種 + パーティショニング)。ユーザには見せない。
• 価格は ストレージ + 読み取り単位(RU) + 書き込み単位(WU) の3点。コールドインデックスはほぼ無料。
• マルチテナンシは namespace 単位。namespaceごとにRU課金が独立。
• 2025年以降、sparse(BM25)+ denseハイブリッドを1級サポート。
• 2026年Q1にColBERT風のlate interactionをベータ追加。

典型的なPython使用は次の通り。

from pinecone import Pinecone, ServerlessSpec

pc = Pinecone(api_key="pc-...")

pc.create_index(
    name="rag-prod-2026",
    dimension=1024,
    metric="cosine",
    spec=ServerlessSpec(cloud="aws", region="us-east-1"),
)

index = pc.Index("rag-prod-2026")

index.upsert(
    vectors=[
        {"id": "doc-1", "values": [0.01] * 1024, "metadata": {"tenant": "acme", "lang": "ja"}},
    ],
    namespace="tenant-acme",
)

result = index.query(
    vector=[0.01] * 1024,
    top_k=10,
    namespace="tenant-acme",
    filter={"lang": {"$eq": "ja"}},
    include_metadata=True,
)

Pineconeの最大の強みは「運用負荷ゼロ」、弱みは価格予測の難しさ。RU/WU課金なのでトラフィックが跳ねれば請求書も跳ねる。

Qdrant — Rustベースのセルフホスト王者

QdrantはRustで書かれたOSSベクターDBで、セルフホスティング・トラックで最も人気がある。2026年5月時点の1.13ラインの特徴は次の通り。

• HNSW + scalar/product quantization(int8、binary、PQ)の組み合わせ。binary quant + reorderでディスク・メモリを4〜32倍節約。
• Payloadインデックス: keyword、integer、float、geo、full-text、datetimeのインデックスを内蔵。pre-filter時はRDBのように動く。
• Sparse + denseベクターの同時検索 + RRF/DBSFフュージョン。
• マルチベクター(ColBERT等のlate interaction)を1級サポート。
• 分散クラスタ(シャーディング + Raft)と Qdrant Cloud マネージドの両方を提供。

コレクション作成とクエリ例。

from qdrant_client import QdrantClient
from qdrant_client.models import (
    Distance, VectorParams, PointStruct, Filter, FieldCondition, MatchValue,
)

client = QdrantClient(url="http://qdrant:6333", api_key="q-...")

client.create_collection(
    collection_name="rag_prod",
    vectors_config=VectorParams(size=1024, distance=Distance.COSINE),
)

client.upsert(
    collection_name="rag_prod",
    points=[PointStruct(id=1, vector=[0.01] * 1024, payload={"lang": "ja", "tenant": "acme"})],
)

hits = client.search(
    collection_name="rag_prod",
    query_vector=[0.01] * 1024,
    query_filter=Filter(must=[FieldCondition(key="lang", match=MatchValue(value="ja"))]),
    limit=10,
)

Qdrant CloudはGCP/AWS/Azureでマネージドを提供し、メモリ/ディスクベースの価格でPineconeより予測しやすい。セルフホストもHelm chartで提供されK8sに馴染む。

Weaviate — モジュール + ハイブリッドの強者

WeaviateはGoで書かれたOSSベクターDBで、モジュールシステムと 1級のハイブリッド検索が強みだ。2026年5月の1.30ラインで:

• モジュール: text2vec-openai、text2vec-cohere、text2vec-jina、multi2vec-clip、generative-openai、reranker-cohereなど多数。embedding生成をDB内で完結。
• Hybrid search: BM25 + dense + Reciprocal Rank Fusionを1行で。
• マルチテナンシ: テナントごとにインデックスディレクトリを分離。数万〜数十万テナントにスケール。
• Weaviate Cloud Services(WCS) がマネージド。Hybrid Cloud(BYOC)は2025年Q4にGA。
• Generative検索: 検索結果をLLMに直送してRAG応答を返すワンライン。

スキーマ作成とハイブリッド検索の例。

import weaviate
from weaviate.classes.config import Configure, Property, DataType

client = weaviate.connect_to_local()

client.collections.create(
    name="Doc",
    properties=[
        Property(name="content", data_type=DataType.TEXT),
        Property(name="lang", data_type=DataType.TEXT),
    ],
    vectorizer_config=Configure.Vectorizer.text2vec_openai(model="text-embedding-3-large"),
    generative_config=Configure.Generative.openai(model="gpt-4.1-mini"),
)

docs = client.collections.get("Doc")
result = docs.query.hybrid(
    query="ベクターデータベース比較",
    alpha=0.5,
    limit=10,
)

Weaviateの強みは「embedding + 検索 + 生成」を1システムで終えられること。短所はモジュール依存が複雑でセルフホスト運用コストが上がること。

Milvus 2.5 + Zilliz Cloud — 大規模 + GPU の王者

MilvusはLF AI & Data Foundation配下の大規模ベクターDBで、十億〜百億ベクター規模で最も検証されている。2026年5月の2.5ライン:

• 分散アーキテクチャ: query node、data node、index node、coordが分離。K8sネイティブ。
• インデックス選択肢: HNSW、IVF、IVF-PQ、DiskANN、GPU-CAGRA、GPU-IVF-PQ。
• GPUインデックス: NVIDIA cuVS / RAFTベースのGPU-CAGRA。CPU比10〜100倍のスループット。
• ハイブリッド検索: BM25 + dense + RRF、複数ベクターフィールド、partition_keyベースのマルチテナンシ。
• Zilliz Cloud: Milvus作者陣によるマネージド。AWS/GCP/Azureの全リージョン。

コレクション作成とハイブリッド検索例は次の通り。

from pymilvus import MilvusClient, DataType

client = MilvusClient(uri="http://milvus:19530", token="root:Milvus")

schema = client.create_schema()
schema.add_field("id", DataType.INT64, is_primary=True, auto_id=True)
schema.add_field("dense", DataType.FLOAT_VECTOR, dim=1024)
schema.add_field("sparse", DataType.SPARSE_FLOAT_VECTOR)
schema.add_field("tenant", DataType.VARCHAR, max_length=64)

idx = client.prepare_index_params()
idx.add_index("dense", index_type="HNSW", metric_type="COSINE", params={"M": 16, "efConstruction": 200})
idx.add_index("sparse", index_type="SPARSE_INVERTED_INDEX", metric_type="IP")

client.create_collection("rag", schema=schema, index_params=idx)

Milvusのアイデンティティは「エンタープライズ大規模」だ。1億未満のワークロードでは運用負荷が大きく、Pinecone / Qdrant / Weaviateの方が向く。

pgvector + pgvectorscale + ParadeDB — Postgresが「十分に良い」陣営

2026年の興味深い潮流は Postgres + pgvector が「特殊要件がなければ十分に良い」デフォルトに定着したことだ。

• pgvector 0.8: HNSW + IVFFlatインデックス。2025年にbinary quantization、halfvec(16ビット)が追加。
• pgvectorscale 0.6(Timescale): StreamingDiskANNインデックス + 統計的binary quantization。pgvector比で10〜100倍速いフィルタ検索。
• ParadeDB: Postgres上のBM25(pg_search)+ ベクターの結合。ハイブリッド検索がPostgresで完結。
• Supabase、Neon、Aurora、Cloud SQL: いずれもpgvectorを既定提供。

典型的な使い方:

CREATE EXTENSION IF NOT EXISTS vector;
CREATE EXTENSION IF NOT EXISTS vectorscale;

CREATE TABLE doc (
    id bigserial PRIMARY KEY,
    tenant_id uuid NOT NULL,
    content text NOT NULL,
    embedding vector(1024) NOT NULL
);

CREATE INDEX ON doc USING diskann (embedding vector_cosine_ops);
CREATE INDEX ON doc (tenant_id);

SELECT id, content, 1 - (embedding <=> $1) AS score
FROM doc
WHERE tenant_id = $2
ORDER BY embedding <=> $1
LIMIT 10;

長所は トランザクション、JOIN、権限、バックアップがそのままPostgresであること。短所は1億ベクター超でHNSWメモリ圧迫が厳しく、マルチテナンシをRLSで解くとインデックス効率が落ちる点。

Chroma · LanceDB — 組み込み / ローカル トラック

プロダクション単一ノードまたはノートブックでRAGプロトタイプを作るとき、最もよく使われる2ツール。

• Chroma: Python / JS優先。単一プロセス組み込み、またはHTTPサーバ。SQLite + DuckDB + HNSWLibの組み合わせ。2026年Q1にdistributedモードがベータ。
• LanceDB: Rust製。Apache Arrow + Lanceファイル形式ベース。S3/GCS上にそのまま乗せても動く。組み込み + サーバ両対応。マルチモーダル親和。

LanceDBの売りは「S3に .lance ファイル1個で完了」。専用マネージドはまだないが、LanceDB Cloud(ベータ)とSageMaker統合が増えている。

import lancedb

db = lancedb.connect("s3://my-bucket/lance-db")
tbl = db.create_table(
    "docs",
    data=[{"id": 1, "vector": [0.01] * 1024, "lang": "ja"}],
    mode="overwrite",
)
tbl.create_index(metric="cosine", index_type="IVF_HNSW_SQ", num_partitions=256)

hits = tbl.search([0.01] * 1024).where("lang = 'ja'").limit(10).to_list()

Elasticsearch · OpenSearch · Vespa — 検索エンジン トラック

既存のBM25検索エンジンがdense vectorを本格サポートし、別途ベクターDBを導入せず同じクラスタでハイブリッド検索する流れが定着した。

• Elasticsearch 8.x〜9.x: dense_vector フィールド + HNSW。_search 内で knn + query(BM25)結合のハイブリッド。ELSER(Elastic Learned Sparse Encoder)で自社sparse vectorも提供。
• OpenSearch 2.x〜3.x: knn プラグイン。FAISS / Lucene / NMSLibバックエンドを選択。AWS OpenSearch Serviceでマネージド。
• Vespa: Yahoo製でOSS化された検索エンジン。tensor表現が1級。マルチベクター、マルチステージランキングが強み。Spotify Discover Weekly、Yahoo Mailで採用。

既存検索クラスタを持つ組織が最初に試す経路だ。短所は専業ベクターDBに比べてインデックススループット / メモリ効率が劣る点。

NoSQLのベクター拡張 — Mongo · Redis · Couchbase · SingleStore · DuckDB · SQLite

運用データが既に入っているDBがベクター対応すれば運用は最もシンプル。

• MongoDB Atlas Vector Search: Atlas専用の検索インデックス(Lucenベース)。$vectorSearch aggregationステージ。
• Redis 8 Vector Search: HNSW + flat。Redis Stack / Redis Enterprise。インメモリでms未満の応答。
• Couchbase Vector Search: 2024 GA。SQL++内でベクタークエリ。
• SingleStore: 分散SQL DB + ベクター。分析 / 検索 / トランザクションを1クラスタで。
• DuckDB VSS拡張: in-process分析 + HNSW。DataFrame / Parquetにそのままインデックス。
• sqlite-vec: Alex GarciaによるSQLite拡張。モバイル / エッジRAG向け。

このトラックの共通点は「ベクター用に別クラスタを作らない」こと。1億未満で本業がOLTPなら最も合理的な選択になることが多い。

新興トラック — Turbopuffer · Marqo · Vald · NGT · Tair Vector

マネージド / 特化市場でも新規参入が増えた。

• Turbopuffer: S3に乗せたサーバレスベクターDB。価格が非常に低く(ストレージ + クエリ単位課金)、コールドデータに強い。2025年にNotionが採用して注目。
• Marqo: embedding + 検索を1パッケージで提供。マルチモーダル親和。cloud + セルフホスト。
• Vald(Yahoo Japan / LY): K8sネイティブのNGTベース分散ベクターDB。LINE検索で使用。
• NGT(Yahoo Japan): グラフベースのANNライブラリ。ONNG、PANNG、QGなどの変種。
• Tair Vector(Alibaba Cloud): Redis互換 + ベクター。中国市場のデフォルト。

FAISS · ScaNN · DiskANN · Annoy · HnswLib — ライブラリ トラック

DBではなくライブラリとして自前でインデックスを扱うトラック。研究や組み込みでは今も中核。

• FAISS(Meta): C++/Python。IVF、HNSW、IVF-PQ、GPU FAISS。Meta内部 + 学術界のデフォルト。
• ScaNN(Google): TensorFlow親和。非対称量子化。精度/速度比が優秀。
• DiskANN(Microsoft): SSD親和グラフ。pgvectorscale、Milvusが採用。
• Annoy(Spotify): 乱択射影。mmap親和。静的インデックス向き。
• HnswLib: HNSWアルゴリズム著者によるシンプルなHNSWライブラリ。Chroma、Jina、Weaviateの初期バックエンド。
• NGT(Yahoo Japan): グラフベース。日本 / 韓国で採用事例が多い。

ライブラリ直使用例(FAISS):

import numpy as np
import faiss

d = 1024
nb = 100000
xb = np.random.random((nb, d)).astype("float32")
xq = np.random.random((1, d)).astype("float32")

index = faiss.IndexHNSWFlat(d, 32)
index.hnsw.efConstruction = 200
index.add(xb)
index.hnsw.efSearch = 64

D, I = index.search(xq, 10)
print(I, D)

ハイブリッド検索 — BM25 + dense + RRF + リランカが標準になった理由

2024年以降明確になった事実は dense vector単独では不足ということだ。キーワード(名前、ID、コード)マッチに弱く、OOD(out-of-domain)クエリで崩れやすい。2026年標準は次の4段パイプラインだ。

1. BM25検索(sparse)で top-50〜100。
2. Dense vector検索で top-50〜100。
3. RRF(Reciprocal Rank Fusion) または重み付き和で候補100〜200を整理。
4. リランカ(Cohere Rerank 3.5、Voyage Reranker 2、BGE Reranker v2-m3、Jina Reranker v2)でtop-10。

RRFの式はシンプルだ。

def rrf(rankings: list[list[str]], k: int = 60) -> dict[str, float]:
    scores: dict[str, float] = {}
    for ranking in rankings:
        for rank, doc_id in enumerate(ranking, start=1):
            scores[doc_id] = scores.get(doc_id, 0.0) + 1.0 / (k + rank)
    return scores

リランカはcross-encoder構造でクエリと文書ペアを同時に見る。検索点数比NDCG@10が5〜15%上がるのが普通。Cohere Rerank 3.5は100文書リランキングで約80ms、価格は1,000クエリあたり$2程度。

マルチベクターとColBERT · ColPali — 新しい精度の基準

文書1つを単一ベクターに圧縮すると詳細が失われる。そこで登場したのが マルチベクター(multi-vector) アプローチだ。

• ColBERT v2(Stanford 2022 → 2024 PLAID最適化): 文書トークンごとのベクターを全保存 + クエリトークンとlate interaction(MaxSim)。dense single-vector比でNDCGが大きく改善。
• ColPali(2024): Vision Transformerでページ画像をパッチベクターの束に埋め込み。PDF / スライドRAGに革新的。
• ColQwen2: ColPaliのQwen2-VLバックボーン版。

問題はストレージだ。トークンごとにベクターを保存するとデータセットが50〜200倍に膨らむ。Qdrant、Vespa、Weaviate、ParadeDBがマルチベクターをネイティブ対応し、Pineconeは2026年Q1にベータ追加。

フィルタ検索 — pre-filter vs post-filter、そしてメタデータインデックス

ベクター検索はほぼ常にメタデータフィルタと一緒に使う(「tenant_id = X AND lang = ja」)。

• Post-filter: ANN検索後にフィルタ。候補不足のリスク。
• Pre-filter: フィルタを先に適用してからANN。Qdrant / Weaviate / Milvus / pgvectorが得意。
• インデックス付きフィルタ: メタデータ自体にインデックスを作り結合検索。

Pinecone、Weaviate、Qdrant、Milvus、Elasticsearchはメタデータインデックスを自前で作る。pgvectorはPostgresのB-tree / GINインデックス依存。マルチテナンシが大きいワークロードならpre-filter性能を常にベンチマークすべき。

Embeddingモデル選択 — OpenAI vs Cohere vs Voyage vs BGE vs E5 vs Jina

ベクターDBをいくら選んでもembeddingが悪ければ検索品質は崩れる。2026年5月のMTEBリーダーボード上位は次の通り。

• OpenAI text-embedding-3-large(3072d、matryoshka 256 / 1024 / 3072)。バランスが良い。
• Cohere Embed v4(1024d、マルチモーダル、多言語、matryoshka)。
• Voyage 3 / Voyage 3-large(1024d、ドメイン特化 + 一般が優秀)。
• BGE-M3(1024d、dense + sparse + ColBERTを同時出力、OSS)。
• E5-Mistral-7B-instruct(4096d、OSS)。
• gte-Qwen2-7B-instruct(3584d、OSS)。
• Jina Embeddings v3(1024d、多言語、late chunking対応)。

選択基準は(1)多言語が必要か、(2)matryoshkaで次元削減が必要か、(3)セルフホストが必要か、(4)コスト上限はどこか。韓国語 / 日本語環境ではBGE-M3、Cohere v4、Jina v3、multilingual-e5-largeが安全な選択。

RAG固有パターン — chunking · contextual retrieval · parent-child

ベクターDBの上にRAGを乗せるとき2026年標準のパターン:

• Chunking: トークン300〜800 + 50トークンオーバーラップが最も一般的。意味ベース分割(semantic chunking)も人気。
• Contextual retrieval(Anthropic 2024発表): チャンクごとに「このチャンクはどの文書のどこか」をLLMに短く書かせてembedding前にprepend。検索失敗率を半分近く削減。
• Parent-child: 小さなチャンクで検索し、親チャンク / 文書をLLMに渡す。
• Query expansion: HyDE(仮想応答を生成してembedding)、multi-query、query rewriting。
• Reranking: top-100 → top-10のcross-encoderリランキングはほぼすべてのRAGで推奨。

これらはDBに依存しないが、マルチベクター / sparse対応の有無がどのパターンを楽に使えるか決める。

GPUベクターインデックス — RAFT · cuVS · NVIDIA加速

NVIDIA RAPIDSの cuVS(RAFTの後継)が2025年にGAし、GPUベクターインデックスが本格化した。

• CAGRA: GPU向けグラフANN。HNSW比でビルドが10倍以上速く、クエリもGPUで5〜50倍速い。
• GPU IVF-PQ: 十億ベクターのインデックス構築を時間単位から分単位に短縮。
• Milvus GPU CAGRA、FAISS GPUモジュール、RAPIDS cuVSが採用。Pinecone、Weaviate、QdrantはコアエンジンとしてはGPUを使わない(クエリ時はCPUが主流)。

学習ではなく検索段階でもGPUが意味を持つ転換点が2025〜2026年だ。ただしコスト構造上、単一ノード1億ベクター未満ではCPU + HNSWが依然優位。

コスト経済学 — Pinecone vs Weaviate Cloud vs セルフホストQdrant

おおよその月額比較(2026年5月、1億ベクター1024d、p50 50ms目標):

• Pinecone Serverless: 約$2,500〜$4,000(ストレージ + 平均トラフィック)。
• Weaviate Cloud Serverless: 約$2,000〜$3,500。
• Zilliz Cloud(Milvus): 約$1,500〜$3,000。
• Qdrant Cloud: 約$1,200〜$2,500。
• Turbopuffer: 約$300〜$800(コールドワークロード)。
• セルフホストQdrant on K8s(EKS、4 x r6i.2xlarge): インフラ約$1,200 + 運用人件費。
• セルフホストpgvector(Aurora Serverless v2): 約$700〜$1,500。

価格はトラフィック形状で4〜10倍ぶれる。コールドRAGならTurbopuffer / pgvectorが優位、常時ホットならセルフホストQdrantが最安になりがち。

韓国の採用事例 — Naver、Kakao、Toss、Karrot

韓国IT市場の2026年5月のベクターDB状況。

• Naver Clova: 独自HyperCLOVA X RAGインフラ。Milvus亜種 + 自社embeddingと推定。
• Kakao Brain: pgvector + 自社embeddingモデルでKoGPT応用RAG。
• Toss: 検索チームがVespaベースのマルチステージランキングを構築。ベクターは社内インデックス。
• Karrot(당근): マーケットプレイス推薦にFAISS + 自社embedding。Qdrant適用事例も発表。
• Samsung SDS、LG CNS: 社内RAGにPineconeまたはWeaviateマネージドの利用事例。
• 韓国スタートアップ(チャットボット / 検索): Qdrant、Weaviate、pgvectorが最も一般的。

韓国語embeddingはBGE-M3、Cohere Embed v4、multilingual-e5-largeが事実上の標準候補。韓国語特化モデル(KoSimCSE等)はドメインが狭いときに強み。

日本の採用事例 — Vald(LY)、NGT(Yahoo)、メルカリ、LINE検索

• Yahoo Japan / LYコーポレーション: NGTライブラリの開発、Vald分散ベクターDBをOSS化。LINE検索 / 推薦で使用。
• メルカリ: セマンティック検索にElasticsearch + 自社embedding、一部ワークロードはVespa。
• CyberAgent: 広告推薦にFAISSベース自社システム。
• 楽天: 商品検索でSolr / Elastic + 自社embeddingを結合。
• Preferred Networks: 社内RAGでQdrant導入事例を発表。

NGTは韓国でも知られるライブラリだが、Valdクラスタを直接運用する事例は日本国内でもLY / Naverレベルに限られる。メルカリのVespa採用は検索コミュニティで頻繁に引用される。

意思決定ガイド — ワークロード別の推奨

最後にワークロード別の推奨を単純化する。

• ノートブック / 単一ノードRAGプロト: Chroma、LanceDB、DuckDB VSS、sqlite-vec
• モノリシックSaaS、1億ベクター未満、Postgres運用中: pgvector + pgvectorscale(+ ParadeDB)
• K8sセルフホスト、1億〜10億ベクター: Qdrant、Weaviate、Milvus
• 運用負荷最小化のマネージド: Pinecone Serverless、Qdrant Cloud、Zilliz Cloud、Weaviate Cloud
• 10億ベクター超、GPUインデックス必須: Milvus GPU(CAGRA)、Vespa、自社FAISSインフラ
• コールドワークロード、価格最適化: Turbopuffer、pgvector、LanceDB on S3
• 検索クラスタがすでにある: Elasticsearch dense_vector、OpenSearch k-NN、Vespa
• OLTP DB内で完結させる: MongoDB Atlas Vector、Redis Vector、Couchbase、SingleStore
• 組み込み / モバイル: sqlite-vec、LanceDB embedded
• ハイブリッド検索 + リランキングを1級サポート: Qdrant、Weaviate、Vespa、Milvus、ParadeDB
• マルチベクター(ColBERT / ColPali)1級サポート: Qdrant、Vespa、Weaviate、ParadeDB

「デフォルトを決めて例外だけ動かす」原則を適用すると、2026年5月時点で新規RAGのデフォルトは (A) Postgres + pgvector + pgvectorscale または (B) Qdrantマネージド が最も安全。

References

• Pinecone — Serverless v3 マネージドベクターDB
• Weaviate — モジュール + ハイブリッド + 生成検索
• Qdrant — Rustベース OSSベクターDB
• Milvus — 大規模分散ベクターDB
• Zilliz Cloud — Milvusマネージド
• Chroma — 組み込みベクターDB
• LanceDB — Arrowベースのマルチモーダルベクターストア
• pgvector — Postgresベクター拡張
• pgvectorscale — StreamingDiskANN
• ParadeDB — Postgres BM25 + ベクター
• Vespa — Yahoo検索エンジン
• OpenSearch k-NN — k-NNプラグイン
• Elasticsearch dense_vector — ベクター検索
• Redis Vector Search — インメモリベクター検索
• MongoDB Atlas Vector Search — Atlasベクター検索
• Turbopuffer — S3上のサーバレスベクターDB
• Marqo — embedding + 検索
• Vald — Yahoo Japan分散ベクターDB
• NGT — Yahoo Japanグラフ ANN
• FAISS — Metaベクターライブラリ
• DiskANN — Microsoft SSDグラフインデックス
• ScaNN — Google ANN
• Annoy — Spotify静的 ANN
• HnswLib — HNSW参照実装
• Cohere Rerank — Rerank 3.5
• Voyage Reranker — Voyage Reranker 2
• MTEB Leaderboard — embeddingベンチマーク
• ann-benchmarks — ANNアルゴリズムベンチマーク
• ColBERT — late interaction
• ColPali — ビジョンマルチベクター
• Anthropic Contextual Retrieval — チャンク文脈化