pgvectorが『専用ベクトルDB不要』を実現する
pgvectorはPostgreSQLにベクトル型と類似度検索インデックスを追加するOSS拡張モジュールで、2025年以降『PostgreSQLですべて完結』する流れの中核を担っています。Pinecone・Weaviate・Qdrant等の専用ベクトルDBから移行するケースが増加し、運用負荷の削減・データの単一管理・既存PostgreSQL運用ノウハウの活用といったメリットが評価されています。本番運用では数千万〜数億ベクトルでも実用的なパフォーマンスを発揮します。
採用すべき5つのシグナル
- RAGアプリで既にPostgreSQLを使っている
- 専用ベクトルDB（Pinecone等）の料金が運用規模で重い
- データを単一DBで管理し、トランザクション境界をまとめたい
- SQL/JOINでベクトル検索結果と他データを統合したい
- 運用ノウハウがPostgreSQLに集中している
Pinecone/Weaviate/pgvector比較
Pinecone: マネージドSaaS・スケール容易・料金中程度・SQL統合難。
Weaviate: OSS・ハイブリッド検索強い・運用負荷あり。
Qdrant: OSS・Rust製・高速・自前運用必要。
pgvector: PostgreSQL統合・SQL統合自然・運用知識再利用・3億ベクトルまで実績。
使い分け: 10億ベクトル超なら専用DB、それ以下ならpgvectorで十分実用。
インデックス選定（実務目安）
- IVFFlat: 古いインデックス・大規模で性能不安定。新規はHNSW優先
- HNSW: 2023年から導入・高速・高精度。推奨デフォルト
- パラメータ:
m=16・ef_construction=64から開始、データ量に応じて調整 - 性能: 1000万ベクトル・1536次元でクエリ50〜100ms（HNSW）
- ディスク容量: ベクトル本体+HNSW索引で約1.5〜2倍のストレージ
実装の基本パターン
(1) 拡張インストール: CREATE EXTENSION vector
(2) カラム定義: embedding vector(1536)
(3) 索引: CREATE INDEX ON items USING hnsw (embedding vector_cosine_ops)
(4) 検索: SELECT * FROM items ORDER BY embedding <=> '[...]' LIMIT 10
(5) ハイブリッド検索: ベクトル検索 + 全文検索を組み合わせ
本番運用の3つの注意点
- インデックス構築時間: 1000万ベクトルで数時間。本番ロード前にインデックス作成
- 更新コスト: HNSW索引は更新が重い。バッチ書き込み推奨
- メモリ要件: HNSW索引はメモリに乗ると最速。RAM計画必要
採用判断の境界
pgvectorが向く: 1億ベクトル以下・PostgreSQL中心スタック・SQL統合重視。
専用DBが向く: 10億ベクトル超・極限の低レイテンシ要件・水平スケール頻繁・マネージド運用重視。
30日学習プラン
- 1週目: pgvectorインストール・OpenAI Embedding+検索の基本実装
- 2週目: HNSW索引チューニング・クエリ性能計測
- 3週目: ハイブリッド検索（全文+ベクトル）・RAG実装
- 4週目: 本番デプロイ・運用監視・スケール検証
関連リンク
RAG構築は RAG構築ガイド、PostgreSQL深掘りは PostgreSQL深掘り、ベクトル検索ツール選定は ベクトルDB選び方 を参照してください。AIアプリは Vercel AI SDK深掘り もどうぞ。