ベクトル DB 比較：Pinecone / Weaviate / pgvector / Qdrant

ベクトル DB は、文章や画像を数値の並び（埋め込みベクトル）に変えて保存し、「意味が近いもの」を高速に探すための専用データベースです。RAG（検索拡張生成）や推薦・類似検索の土台になります。本記事は Pinecone / Weaviate / pgvector / Qdrant を軸に、規模・既存スタック・検索方式・コストの 4 観点で「自分の場合どれを選ぶか」を、図とともに具体的に整理します。

FIG.1　文書を埋め込みに変換して索引化し、問い合わせベクトルと「意味が近い」上位を返す

01ベクトル DB が解く問題

普通のデータベースは「完全一致」や「範囲」で探すのが得意です。一方、AI の埋め込みは数百〜数千次元の数値ベクトルで、「意味の近さ」を距離（コサイン類似度や内積など）で測ります。全件と総当たりで距離計算すると遅すぎるため、ベクトル DB は HNSW（グラフ型）や IVF（クラスタ分割）といった索引で近似最近傍探索（ANN）を行い、精度を少し譲る代わりに大幅に高速化します。

「近似」である点が重要です。ANN は必ずしも厳密な正解上位を返すとは限らず、どれだけ取りこぼさないかを示す Recall と速度（QPS・レイテンシ）はトレードオフの関係にあります。索引のパラメータ調整は、この両者のバランス取りそのものです。

024 つの主役と、その立ち位置

選択肢は多いものの、出発点としては次の 4 つを押さえれば十分です。フルマネージドで素早く始めたいか、既存の PostgreSQL に乗せたいか、大規模・低レイテンシを最優先するか——立ち位置が異なります。

製品	立ち位置と向いている人
Pinecone	フルマネージド・サーバーレス型。インフラを持たず使った分だけ課金。運用を任せて素早く本番化したい場合。
Weaviate	OSS＋マネージドクラウド。キーワード＋ベクトルのハイブリッド検索が 1 クエリで完結。検索体験を作り込みたい場合。
pgvector	PostgreSQL 拡張。既存の DB にテーブル 1 つでベクトル検索を足せる。最小コスト・最小構成で始めたい場合。
Qdrant	Rust 製 OSS。フィルタ付き検索とレイテンシに強い。pgvector で頭打ちになり「次」へ移る定番の移行先。

このほか、超大規模向けの Milvus / Zilliz Cloud、軽量で開発用の Chroma や LanceDB、既存検索基盤に足す Elasticsearch / OpenSearch も実務でよく登場します。ただし最初の選定は上記 4 つの軸で考えると迷いません。

03規模で見る現実的なライン

「何件のベクトルを扱うか」で適材は変わります。次は 2026 年時点の感覚的な目安です（埋め込みは 1,536 次元 float を想定。実際は次元数・フィルタ要件・予算で前後します）。