LabHub

ブログ

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

2026-05-16 · 23 分で読めます · #vector-database#pinecone#weaviate#qdrant#milvus#pgvector#lancedb#chroma#faiss#hnsw#embeddings#rag#semantic-search#ann

한국어English日本語

はじめに — 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年の論文が出発点で、多層グラフ上の貪欲探索を行う。

長所は 挿入・削除・探索がすべてグラフ操作なので動的データに強いこと。短所は メモリ使用量が大きいこと。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が標準とはいえ、他のアルゴリズムも生きている。

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

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

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

ポイントは「フリーランチはない」こと。リコールを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月時点で最も「とりあえず使える」マネージド選択肢だ。

典型的な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ラインの特徴は次の通り。

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

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ラインで:

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

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ライン:

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

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 が「特殊要件がなければ十分に良い」デフォルトに定着したことだ。

典型的な使い方:

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ツール。

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を導入せず同じクラスタでハイブリッド検索する流れが定着した。

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

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

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

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

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

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

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

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

ライブラリ直使用例(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) アプローチだ。

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

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

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

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リーダーボード上位は次の通り。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

References

原文を読む: https://www.youngju.dev/blog/culture/2026-05-16-vector-databases-pinecone-weaviate-qdrant-milvus-pgvector-lancedb-chroma-faiss-2026-deep-dive.ja

コメント

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

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