RAG用ベクトルDB、結局どれがいい? — Pinecone・Qdrant・pgvector 3タイプ比較【2026年版】
RAGを構築するとき、最初にぶつかる壁が「ベクトルデータベース、どれを使うか」だ。
選択肢は多い。Pinecone、Qdrant、Weaviate、Milvus、Chroma、pgvector — 名前を挙げるだけで疲れる。しかし設計思想で整理すると、実は3タイプに分かれる。フルマネージドSaaS、セルフホスト可能な専用DB、既存のPostgreSQLに追加する拡張。
この記事では、各タイプの代表格である Pinecone(マネージド)、Qdrant(OSS専用DB)、pgvector(PostgreSQL拡張)を、同一のドキュメントデータセット(社内FAQ約5,000件)でRAGパイプラインを組んで比較した。
結論を先に:
- すぐにRAGを動かしたい → Pinecone(インフラ管理ゼロ、APIだけで完結)
- 大規模で自由にチューニングしたい → Qdrant(Rust製の高速OSSで、クラウドもセルフホストも選べる)
- PostgreSQLを既に使っている → pgvector(追加コストゼロ、既存のSQLワークフローに統合)
3タイプ比較表
※価格は2026年7月7日時点の公式サイト情報
| 項目 | Pinecone | Qdrant | pgvector |
|---|---|---|---|
| タイプ | フルマネージドSaaS | OSS + マネージドクラウド | PostgreSQL拡張(OSS) |
| 無料枠 | Starter(2GBストレージ) | Free Forever(0.5vCPU, 1GB RAM) | 無料(PostgreSQL拡張) |
| 有料プラン | Standard $50〜/月(従量課金) | Standard $30〜200/月 | PostgreSQLのホスティング費用のみ |
| 従量課金 | 書込$4/M単位、読取$16/M単位、保存$0.33/GB/月 | vCPU/RAMベース | なし |
| セルフホスト | 不可 | ◎ Dockerで即起動 | ◎ PostgreSQL + 拡張 |
| 対応言語/SDK | Python, Node.js, Go, Java等 | Python, Rust, Go, JS等 | SQL(あらゆる言語から利用可) |
| 最大次元数 | 20,000 | 制限なし | 制限なし |
| フィルタリング | メタデータフィルタ | ペイロードフィルタ(高速) | WHERE句(SQL標準) |
| おすすめな人 | インフラを触りたくない人 | パフォーマンス重視の開発者 | PostgreSQLユーザー |
3つは同じ「ベクトル検索」をする道具だが、設計思想がまったく違う。Pineconeはインフラをすべて隠蔽し、Qdrantはベクトル検索に特化した専用エンジンを提供し、pgvectorは既存のPostgreSQLにベクトル機能を追加する。どこに運用コストを払うかの問題だ。
Pinecone — インフラゼロで始められるマネージド型
Pineconeは、ベクトルデータベースのSaaS化を最初に成功させたプレイヤーだ。APIキーを取得して、エンベディングをupsertするだけ。サーバーの管理、インデックスの最適化、スケーリング — すべてPinecone側がやってくれる。
Starterプラン(無料)は2GBのストレージを提供する。768次元のエンベディングなら約100万ベクトルが入る計算で、プロトタイプや小規模なRAGには十分だ。Standard以上では統合ストレージとサーバーレスアーキテクチャにより、アクセスパターンに応じて自動スケールする。
筆者が最も便利だと感じたのはPinecone Assistantの存在だ。ファイルをアップロードするだけで、チャンキング・エンベディング・インデックス構築を自動で行い、RAGパイプラインが完成する。コードを書かずにRAGを試せるのは、非エンジニアのプロダクトマネージャーにとっても価値がある。
ただし、コストが読みにくい。 従量課金(書込$4/M単位、読取$16/M単位、ストレージ$0.33/GB/月)は、アクセスパターンが安定するまで月額の予測が難しい。100万ベクトル程度なら月$10〜30で収まるが、1,000万ベクトルで頻繁にクエリを投げるとStandard $50/月の基本料に加えて読取コストがかさむ。
もう一つの制約は、セルフホストができないこと。データを自社インフラに置く必要があるエンタープライズにとっては、これが採用のブロッカーになる場合がある。
向いている人: RAGをすぐに動かしたいチーム、インフラエンジニアがいないチーム、プロトタイピング段階のプロジェクト
Qdrant — Rust製の速さと柔軟性を兼ね備えたOSS
Qdrantは、Rustで書かれたベクトル検索エンジンだ。Apache 2.0ライセンスのオープンソースで、docker run qdrant/qdrant で即座にローカル環境が立ち上がる。
正直に言うと、最初はPineconeの方がセットアップが楽だと思っていた。しかし実際にRAGを組んで運用してみると、Qdrantのペイロードフィルタリングの速さに評価が逆転した。 ベクトル検索とメタデータフィルタを組み合わせたクエリで、Pineconeより一貫して高速だった。HNSWインデックスとカスタマイズ可能な量子化オプション(Scalar、Product、Binary)が効いている。
Qdrant Cloudのマネージドプランも用意されている。Free Foreverプランは0.5 vCPU・1GB RAM・4GBディスクで、テスト用途には十分。Standardプランは$30〜200/月でvCPU・RAMの組み合わせを選べる。
Qdrantの際立つ特徴はマルチテナンシーのネイティブサポートだ。1つのコレクション内でテナントごとにデータを分離でき、SaaSアプリケーションでのRAG実装に適している。Pineconeでも名前空間で似たことはできるが、Qdrantの方がフィルタレベルでの分離が柔軟だ。
弱点は運用の自己責任。セルフホストの場合、バックアップ、モニタリング、スケーリングの設計は自分で行う必要がある。Qdrant Cloudを使えば軽減されるが、Pineconeほどの「お任せ感」はない。
向いている人: パフォーマンスにこだわる開発者、セルフホストでコスト最適化したい人、マルチテナンシーが必要なSaaS開発者
pgvector — 「新しいDBを増やしたくない」という合理的な選択
pgvectorは、PostgreSQLの拡張として動作するベクトル検索機能だ。CREATE EXTENSION vector; の一行で有効化でき、既存のテーブルに vector(1536) カラムを追加するだけで使い始められる。
多くの開発者にとって、これが最も現実的な選択肢だと筆者は考えている。 理由は単純で、ほとんどのWebアプリケーションは既にPostgreSQLを使っているからだ。新しいインフラを追加せず、既存のSQLスキル・ツール・バックアップ運用をそのまま活かせる。SupabaseやNeonといったマネージドPostgreSQLサービスはpgvectorをプリインストールしており、追加コストゼロで使える。
2026年にリリースされたpgvector 0.8.0では大幅な性能改善が入った。HNSWインデックスのクエリ速度が最大9倍に向上し、ストリーミングディスクインデックスにより利用可能なメモリを超える大規模データセットにも対応可能になった。以前は「pgvectorは遅い」という評判があったが、最新版ではかなり改善されている。
ただし、ベクトル検索に特化した機能では専用DBに劣る面がある。 Qdrantのような高度な量子化オプションやマルチテナンシー機能はない。フィルタリングはSQLのWHERE句で行うため、ベクトルインデックスとの統合度合いではPineconeやQdrantの方が最適化されている。
また、ベクトル数が1,000万を超えてくると、PostgreSQLの汎用的なアーキテクチャがボトルネックになりやすい。 RAGが「実験」から「本番サービスの中核機能」に昇格する段階で、専用DBへの移行を検討する分岐点が来る。
向いている人: PostgreSQLを既に使っている開発者、インフラをシンプルに保ちたい人、中小規模(100万ベクトル以下)のRAG
筆者のおすすめ — 規模で分けるのが正解
最初にPineconeでRAGのプロトタイプを作り、「これならいけそうだ」と確信が持てた段階でコスト構造を見直す — というアプローチが最もリスクが低い。
実際の判断フローはこうなる:
- PostgreSQLを既に使っていて、ベクトル数が100万以下 → まずpgvectorで始めるのが合理的。追加コストゼロで、移行判断は後でいい
- インフラを触る余裕がない、または非エンジニアが主体 → Pinecone一択。APIだけで完結する安心感は他にない
- 大規模データ、高いQPS、マルチテナンシー要件 → Qdrant。セルフホストならコストも抑えられる
多くの比較記事が「Pineconeがベスト」と結論づけているが、筆者は小〜中規模のRAGならpgvectorで十分だと思っている。 新しいインフラを追加する運用コスト(監視、バックアップ、障害対応)を考えると、既存のPostgreSQLに拡張を入れる方がトータルコストは低い。「ベクトルDBを選ぶ」という意思決定自体を不要にできるのがpgvectorの最大の強みだ。
専用DBが必要になるのは、ベクトル数が数百万を超えてクエリレイテンシが問題になったとき。その段階に来たら、Qdrantのセルフホストかクラウドを検討すればいい。
まとめ
ベクトルデータベースの選定は、機能比較よりも「自分のチームがどこに運用コストを払えるか」で決まる。インフラ管理に人手を割けないならPinecone、パフォーマンスを自分で追い込みたいならQdrant、既存のPostgreSQLに載せたいならpgvector。
3ツールとも無料枠がある。pgvectorはPostgreSQLさえあれば今すぐ試せるし、PineconeとQdrantのフリープランでも本番レベルのベクトル検索を体験できる。コードを書く前に悩む時間より、実際にエンベディングを入れてクエリを投げてみる方が、答えに早くたどり着く。
あわせて読みたい: ローカルLLM比較 — Ollama・LM Studio・Foundry Local
あわせて読みたい: LangGraph vs CrewAI vs Mastra — AIエージェントフレームワーク3強比較
関連記事
Kiro vs Augment Code 徹底比較【2026年版】仕様駆動 vs コンテキストエンジン、選ぶべきはどちらか
KiroとAugment Codeを設計思想・料金・エージェント機能で比較。規模別の選び方を解説。
Claude Code vs Kiro — 「計画してから書く」か「書きながら考える」か
Claude Code(ターミナル型)とKiro(スペック駆動IDE)を設計思想・MCP対応・料金・使い分けで比較。両方使う開発者が増えている理由を解説。
Antigravity vs Claude Code — 「無料」と「月$20」の間にある、思ったより大きな差
Google Antigravity(無料枠あり)とClaude Code(月$20〜)を料金・コード品質・サブエージェント・安定性で比較。どちらが実用的か検証する。