「ベクトルDBが要るのは分かったけれど、新しいインフラを立てるのは大変」「既にPostgreSQLは運用している」。多くの組織が、新規インフラ導入に抵抗を感じます。pgvectorは、PostgreSQLにベクトル検索機能を足すOSS拡張モジュールで、この抵抗をゼロにする選択肢です。
2021年にApache 2.0ライセンスで公開され、AWS RDS・Azure Database・Cloud SQL・Supabaseなど主要マネージドPostgreSQLでも対応が進んでいます。シンプルさとSQL運用との一体化が強みです。基本構造と使い方を整理します。
pgvectorのセットアップ
-- 拡張を有効化（一度だけ）
CREATE EXTENSION vector;
-- ベクトルカラムを持つテーブル
CREATE TABLE documents (
id BIGSERIAL PRIMARY KEY,
title TEXT,
content TEXT,
embedding vector(1536) -- OpenAI text-embedding-3-smallの次元
);これだけで、PostgreSQLにベクトル型が追加され、テーブルに格納できます。既存のPostgreSQL運用にそのまま組み込めます。
ベクトル検索のクエリ
-- 近い順に取得（cosine類似度）
SELECT id, title, content, 1 - (embedding <=> '[0.1, 0.2, ...]') AS similarity
FROM documents
ORDER BY embedding <=> '[0.1, 0.2, ...]'
LIMIT 5;
-- メタデータフィルタとの組み合わせ
SELECT id, title
FROM documents
WHERE category = 'support'
ORDER BY embedding <=> '[0.1, 0.2, ...]'
LIMIT 5;`<=>`がcosine距離、`<->`がeuclidean、`<#>`がdot productの演算子です。普通のSQLクエリにベクトル検索が混ざる感覚で、フィルタやJOINも自然に組み合わせられます。
インデックス：HNSWとIVFFlat
| HNSW | IVFFlat | |
|---|---|---|
| 検索速度 | 速い | 中 |
| 構築時間 | 遅い | 速い |
| メモリ | 多い | 少ない |
| 更新 | 許容 | 大量更新で再構築が要る |
| 推奨 | 大半のユースケース | 大規模初期構築・メモリ制約 |
-- HNSWインデックス（pgvector 0.5以降推奨）
CREATE INDEX ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);多くのユースケースではHNSWが推奨です。検索速度と更新耐性のバランスが良く、特別な理由がなければHNSWを選びます。
Pinecone/Weaviateとの比較
| pgvector | Pinecone | Weaviate | |
|---|---|---|---|
| 運用 | 既存PostgreSQLに乗る | マネージドSaaS | OSS/Cloud両方 |
| 規模 | 〜数千万ベクトル | 数億〜数十億 | 数億〜数十億 |
| SQL統合 | 強力（JOIN等可） | API経由 | GraphQL |
| 性能 | 中 | 高 | 高 |
| 費用 | PostgreSQLコストのみ | 従量課金 | OSS無料、Cloud有料 |
「中規模まで」「既存PostgreSQLを活用」「SQL中心」ならpgvectorが圧倒的に手軽です。数億ベクトル超の超大規模では専用ベクトルDB（Pinecone/Weaviate）の性能優位が出ます。
マネージドPostgreSQLでの対応
- AWS RDS：PostgreSQL 15以降でpgvectorサポート
- Azure Database for PostgreSQL：拡張を有効化可能
- Google Cloud SQL：拡張サポート
- Supabase：pgvectorが標準提供
- Neon：サーバーレスPostgreSQLでサポート
各マネージドサービスでサポートが進んでおり、特別な対応なくpgvectorを使えます。
運用上のハマりどころ
- 性能の限界：数千万ベクトル超で検索性能が辛くなる。専用ベクトルDBへの移行を検討。
- メモリ要件：HNSWはメモリ多めに使う。PostgreSQLのshared_buffersとの兼ね合いに注意。
- 大規模初期構築の時間：HNSW構築は時間がかかる。バッチで時間外に行う。
- 近似検索の精度：HNSWは近似検索なので100%正確ではない。`ef_search`パラメータで精度と速度のトレードオフを調整。
向く・向かない場面
- 向く：既にPostgreSQL運用、データ量が中規模まで、SQL中心、運用シンプル化、コスト最小化
- 向かない：数億〜超大規模（→Pinecone / Weaviate）、PostgreSQL未導入、ベクトル検索が業務の主要要件で性能優位が必要
まとめ
- pgvectorはPostgreSQLにベクトル検索を足すOSS拡張モジュール。
- 既存PostgreSQLにそのまま乗り、SQL運用と一体化できる。
- HNSWインデックスで高速ベクトル検索、メタデータフィルタ・JOINも自然に組める。
- 主要マネージドPostgreSQL（RDS、Cloud SQL、Azure、Supabase等）でサポート。
- 中規模までは最有力の選択肢。超大規模なら専用ベクトルDBに移行検討。
全体像はベクトルDBとLLM向けデータ基盤、隣接はPinecone とは・Weaviate とは。pgvector導入の壁打ちは、DE-STKの初回相談（30分・無料）もご利用ください。
よくある質問（FAQ）
Q. pgvectorは何ベクトルまで実用的？
A. ハードウェアにもよりますが、数百万〜数千万ベクトル程度は実用的に動きます。1億超になると、性能チューニングが必須で、本格的にはPinecone/Weaviateの方が向きます。「自社のデータ量と将来予測」を踏まえて選びます。
Q. PostgreSQLの論理レプリケーションでpgvectorは流せる？
A. 流せます。ベクトル型もVARLENA型扱いなので、論理レプリケーションで他のPostgreSQLにレプリ可能です。Read Replicaにベクトル検索を寄せる、というアーキテクチャも組めます。論理レプリケーションの詳細はPostgreSQL論理レプリケーションを参照してください。
Q. dbtでpgvectorのテーブルを管理できる？
A. できます。dbtのモデルで`vector(N)`型のカラムを宣言し、Embedding計算済みのデータをロードする運用が組めます。「dbtでSilver/Goldを作り、Embedding計算してpgvectorカラムに保存」というパイプラインが現実的です。dbtの基本はdbt実装ガイドを参照してください。
Q. pgvectorのインデックス更新は？
A. HNSWはINSERT/UPDATEに対応し、ベクトルが追加されると自動的にインデックスが更新されます。ただし、大量の更新があると徐々に性能が劣化することがあり、定期的なREINDEXが現実的な運用です。バッチで大量データを入れる場面では、インデックスを一旦DROPして全件INSERT後にCREATEするのが速いです。