「PoC は Pinecone でやったが、本番は既存 PostgreSQL に統合したい」——RAG が PoC を超えて本番運用に乗りはじめた企業から、こうした相談が急増しています。専用ベクトル DB は確かに高性能ですが、運用 DB が増える、トランザクション境界が分かれる、SLA が二重化する——本番では地味に効いてくる課題があります。
pgvector を使えば、既存 PostgreSQL のなかでベクトル検索を完結できます。本記事は、「pgvector を本番で使うときに何を意思決定するか」を実装担当の目線で整理した運用ガイドです。
専用ベクトル DB ではなく pgvector を選ぶ 4 つの理由
1. トランザクション境界が一致する
ドキュメントメタデータと埋め込みベクトルが同じ DB に乗るので、INSERT / UPDATE が 1 トランザクションで完結します。Pinecone を別途持つ場合、整合性を二重管理する必要が出てきます。
2. 既存の権限・監査基盤を流用できる
PostgreSQL RLS で実装する SaaS マルチテナント設計 で書いた RLS が、ベクトル検索にもそのまま適用できます。テナント分離・監査ログ・バックアップを一本化できるのは、エンタープライズ受託で大きな利点です。
3. 運用知識の継承
PostgreSQL の DBA は社内・SES市場とも豊富。「ベクトル DB の運用人材を新規採用」する必要がない、というのは中堅企業にとって極めて重要なファクターです。
4. コスト
100 万ベクトル規模なら、専用ベクトル DB の月額に対して 1/3 〜 1/5 で済むケースが多いです。
インデックス選定 — HNSW か IVFFlat か
pgvector は 2 種類のインデックスをサポートしますが、本番は基本 HNSWを推奨します。
| 観点 | HNSW | IVFFlat |
|---|---|---|
| 検索速度 | 高速 | 中速 |
| 構築時間 | 遅い（数倍） | 速い |
| メモリ消費 | 多い | 少ない |
| 動的な追加 | 強い（再構築不要） | 追加時に精度が劣化 |
| 推奨用途 | 本番運用 | 大量バッチ・初期構築 |
HNSW の実用パラメータ
CREATE INDEX ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);
-- クエリ時: 精度と速度のトレードオフを ef_search で調整
SET hnsw.ef_search = 80;m（接続数）と ef_construction（構築時の探索幅）はデフォルトで多くの用途に十分です。クエリ時の ef_search を 40〜200 で振って、想定 QPS とリコール率の最適点を見つけます。
ハイブリッド検索 — 「ベクトルだけ」では実用にならない
ベクトル検索の課題は、固有名詞や品番などの完全一致が弱いことです。本番では BM25（全文検索）とのハイブリッドが必須です。
-- 全文検索 + ベクトル検索を Reciprocal Rank Fusion で統合
WITH bm25 AS (
SELECT id, ts_rank(tsv, plainto_tsquery('japanese', $1)) AS score
FROM documents
WHERE tsv @@ plainto_tsquery('japanese', $1)
ORDER BY score DESC LIMIT 50
), vec AS (
SELECT id, 1 - (embedding <=> $2) AS score
FROM documents
ORDER BY embedding <=> $2 LIMIT 50
)
SELECT id, SUM(1.0 / (60 + rank)) AS rrf_score
FROM (
SELECT id, ROW_NUMBER() OVER (ORDER BY score DESC) AS rank FROM bm25
UNION ALL
SELECT id, ROW_NUMBER() OVER (ORDER BY score DESC) AS rank FROM vec
) merged
GROUP BY id
ORDER BY rrf_score DESC LIMIT 10;このパターンは マルチモーダル埋め込み + リランカーの企業 RAG ガイド で取り上げたリランカーと組み合わせると、より高精度になります。
スケーリング — どの段階で何が壊れるか
実装担当の観点で、規模ごとに「次に当たる壁」を一覧化します。
| 規模 | 壁 | 対応 |
|---|---|---|
| 〜 10 万件 | 特になし | 単一インスタンスで OK |
| 10〜100 万件 | HNSW のメモリ | shared_buffers を実メモリ 25%、maintenance_work_mem を増強 |
| 100〜1000 万件 | INSERT 時の HNSW 更新コスト | バッチ INSERT + CONCURRENTLY でのインデックス再構築 |
| 1000 万件超 | 単一ノードの限界 | パーティショニング or Citus / pgvecto.rs を検討 |
特に「HNSW のメモリが乗り切らない」は気付きにくく、SET 文での work_mem 調整やインデックスのページキャッシュ滞在時間を監視する必要があります。
監視 — 必ず取りたい 5 メトリクス
- クエリ平均レイテンシ（P50 / P95） — pg_stat_statements で取得
- インデックスのヒット率 — pg_statio_user_indexes
- ベクトル検索の Recall@K — オフライン評価セットを CI で回す
- コネクション数 / 待機数 — PgBouncer or Hyperdrive 経由なら必須
- 埋め込み生成 API の費用 — OpenAI / Voyage / Gemini Embedding の月額
監視の SaaS 連携は OpenTelemetry 移行ガイド のパターンがそのまま流用できます。
コスト試算 — Pinecone との 100 万ベクトル比較
| コスト要素 | Pinecone（Standard） | pgvector（RDS db.r6g.xlarge） |
|---|---|---|
| 月額 DB | 約 $70〜 | 約 $230 |
| 既存 DB に同居なら？ | 別契約必須 | 追加 0 円 |
| 運用人月 | 専門知識必要 | 既存 DBA で対応可 |
| 100 万件規模の TCO 目安 | $80〜 / 月 | 既存 DB 同居で $0 〜 数十ドル |
専用ベクトル DB の優位性は 1 億件超 × グローバル分散 の超大規模ワークロードに集約されつつあります。
まとめ — 「DB を増やさない」が運用 PoC を超えた答え
pgvector の魅力は、ベクトル検索を「特殊技術」から「PostgreSQL の機能の一つ」に降格させる点にあります。RAG が PoC を超えて本番に乗ると、運用の単純さが性能の伸びしろを上回るのが常です。
GleamHub では、Pinecone / Qdrant からの pgvector 移行 PoC、ハイブリッド検索の実装、監視基盤の整備までを伴走しています。「RAG を本番に乗せたい」「ベクトル DB の運用負荷を下げたい」といったご相談は、ぜひ お問い合わせ からお気軽にどうぞ。
