pgvectorとはPostgreSQLにベクトル検索を載せる拡張

2026年6月3日

pgvectorはAndrew Kaneが2021年から開発しているPostgreSQLのオープンソース拡張で、vectorという新しい型と、L2距離・コサイン距離・内積などの演算子、IVFFlatおよびHNSWインデックスを追加します。ベクトル検索専用DBを別途運用せず、既存のPostgreSQL資産の上で類似度検索を始められる手軽さから、Supabase、Neon、AWS Aurora、Google AlloyDBなど主要マネージドサービスにも標準で組み込まれるまでに普及しました。本稿ではpgvectorの設計と限界、運用パターンを整理します。

この記事の目次

vector型とインデックスの仕組み
ハイブリッド検索とSQL統合の妙味
スケールの限界と現実的な戦略
運用ベストプラクティス
まとめ

vector型とインデックスの仕組み

pgvectorはCREATE EXTENSION vector;を実行することでインストールされ、vector(1536)のように次元数を指定したカラム型を提供します。演算子<->がL2距離、<#>が内積、<=>がコサイン距離に対応し、ORDER BY embedding <-> $1 LIMIT 10のようにSQLだけで近傍検索を書ける点が他のベクトルDBと大きく異なります。

v0.5以降はHNSWインデックスがネイティブで実装され、構築時にm/ef_construction、検索時にef_searchパラメータを設定できます。従来のIVFFlatに比べてリコールと速度の両立がしやすく、OpenAIのtext-embedding-3-smallの1536次元程度であれば、数百万件のテーブルでも十分実用的なレイテンシで応答できる、というのが普及の理由のひとつです。

ハイブリッド検索とSQL統合の妙味

pgvectorの真価は「PostgreSQLの他機能と素直に組み合わせられる」ことにあります。tsvectorを使った全文検索、pg_trgmによるあいまい検索、JSONBの属性フィルタといった既存機能とベクトル類似度を同じトランザクション内で評価できるため、結合表現を活かしたハイブリッド検索が書きやすい構造です。

RRFのような複雑な融合ランキングをSQLで実装する例も増えており、ベクトル検索と通常のCRUDアプリケーションを単一データベースで完結させたい場合は、他のベクトルDBよりも開発・運用コストを大きく下げられます。SupabaseがpgvectorをRAGのリファレンス実装に据えていることもあり、JavaScript/TypeScriptのフルスタックフレームワークと組み合わせやすい点も普及を後押ししています。

スケールの限界と現実的な戦略

PostgreSQLは元来OLTP向けに最適化されており、ベクトルインデックスを単一ノードでスケールさせる際の上限はMilvusやQdrantのようなネイティブベクトルDBに比べると低くなります。目安としては数百万〜数千万件規模までが快適に扱える範囲で、それを超える場合はパーティショニング、レプリケーション、外部キャッシュ層の併用などが必要です。

とはいえRAGの現場では「ユーザの数千ファイル分のチャンク」のようにコレクション規模が比較的小さいケースが多く、pgvectorで十分実用的という現実があります。10億規模で運用したい場合はpgvectorscaleやTimescale、Citusといった拡張で水平分散させる選択肢があり、PostgreSQLエコシステムの厚みを生かせる点は他のベクトルDBにはない優位性です。

運用ベストプラクティス

実務では、ベクトル次元数とインデックスパラメータを慎重に決めることが最重要です。HNSWは構築時にメモリを多く必要とするため、データ投入をバッチで行い、maintenance_work_memを一時的に大きく設定するなど、PostgreSQL本来のチューニング知識が活きます。Vacuum/Analyzeのスケジュールも忘れずに整えておかないと、近傍検索のリコールが徐々に劣化する事象が起きえます。

また、量子化版のhalfvec（半精度）やbit（バイナリ量子化）が新しいバージョンで提供され始めており、メモリ使用量を半分以下に減らしながら検索精度を保てるようになっています。「既存PostgreSQLを最大限活かしつつ、ベクトル検索もモダンに」を実現したい場合、pgvectorは2026年時点でもっとも合理的な選択肢のひとつです。