世界を動かす技術を、日本語で。

Pg_vectorsearch: pgvectorのIVFFlatおよびHNSWよりも高速なインデックス

2026年10月14日原文(github.com)

概要

  • PostgreSQL向け高性能近似最近傍(ANN)検索拡張機能 の紹介
  • PRISMインデックス による大規模ベクトルデータ(1億件超)への高速検索対応
  • pgvector互換性 を持ち、既存テーブルにもシームレスに導入可能
  • SIMD最適化・RaBitQ量子化 など最新技術の採用
  • α版のためテスト用途推奨、既知の制限やメンテナンス方法に注意

PostgreSQL拡張機能「pg_vectorsearch」概要

  • 高性能ANN検索 を実現するPostgreSQL拡張機能
  • バージョン:α版 (テスト用、商用利用非推奨)
  • プレリリース間のアップグレード非対応、拡張機能やインデックスの再作成が必要
  • 既知の問題点 はchangelog参照

PRISMインデックスの特徴

  • IVFスタイルの階層型ルーティング を持つPRISMインデックス
    • 100M+ベクトル対応
    • 階層セントロイドツリー によるクラスタリング
    • RaBitQ量子化 で2段階検索時の理論的誤差保証
    • SIMD最適化距離計算 (AVX2, AVX512, NEON対応)
    • 動的更新 (挿入・更新・削除)に対応、prism_rebalanceでリスト分割
  • pgvector互換性 :既存vectorやhalfvecカラムにそのままインデックス作成可能
  • C言語実装 による高性能とPostgreSQLとのシームレスな統合

性能面の強み

  • IVFFlatやHNSWより高速 なクエリ・インデックス構築
    • 同等リコール率でHNSWより高速、必要メモリは1/4
  • ベクトルはRaBitQで量子化、SIMD最適化ページレイアウトで高速距離計算
  • 量子化誤差範囲を利用し不要な再ランクを削減

クエリフロー

  1. セントロイドツリー探索 で近傍クラスタ特定(バッファキャッシュ活用)
  2. 候補ベクトル抽出 (ポスティングリスト走査、非同期I/O)
  3. RaBitQ二段階フィルタリング (推定→誤差判定→再ランク)
  4. 完全精度で再ランク
  5. k個の最も近い近傍を返却

利用方法

  • インストール :まず拡張機能をビルド・インストール(PostgreSQL 18+、C11コンパイラ、Meson必須)
  • 2つの利用パターン
    • ネイティブ型 :新規テーブルやpgvector未使用時、vec32(float32)/vec16(float16)カラムを利用
    • 既存pgvectorテーブル :vectorやhalfvecカラムにも直接インデックス作成可能
  • 同一テーブル・スキーマでpgvector/pg_vectorsearch共存可

サンプルSQL(ネイティブ型)

  • CREATE EXTENSION pg_vectorsearch;
    CREATE TABLE items (
      id serial PRIMARY KEY,
      embedding vec32(3) STORAGE PLAIN
    );
    INSERT INTO items (embedding)
      SELECT ARRAY[i::real, (i % 7)::real, (i % 5)::real]::vec32
      FROM generate_series(1, 1000) i;
    CREATE INDEX ON items USING prism (embedding vec32_l2_ops);
    SET prism.nprobe = 40;
    SELECT * FROM items ORDER BY embedding <-> '[3,1,2]' LIMIT 5;
    
  • vec16型利用でストレージ半減も可

サンプルSQL(既存pgvectorテーブル)

  • CREATE EXTENSION vector;
    CREATE TABLE documents (
      id bigserial PRIMARY KEY,
      body text,
      embedding vector(384)
    );
    CREATE INDEX documents_embedding_hnsw ON documents USING hnsw (embedding vector_l2_ops);
    CREATE EXTENSION pg_vectorsearch;
    CREATE INDEX documents_embedding_prism ON documents USING prism (embedding vec32_l2_ops);
    EXPLAIN (COSTS OFF)
      SELECT id, body FROM documents
      ORDER BY embedding <-> (SELECT embedding FROM documents WHERE id = 42) LIMIT 10;
    DROP INDEX documents_embedding_hnsw;
    
  • 従来のクエリはそのまま利用可能、PRISMインデックスが優先される

演算子クラス

  • 距離指標ごとに演算子クラスを選択
    • L2距離(<->):vec32_l2_ops / vec16_l2_ops
    • 内積(<#>):vec32_ip_ops / vec16_ip_ops
    • コサイン(<=>):vec32_cosine_ops / vec16_cosine_ops
  • pgvectorのvector_<metric>ops→vec32<metric>_ops、halfvec→vec16

チューニング

  • デフォルトは大規模ベンチマークで最適化済み
  • prism.nprobe の調整が主
  • 詳細なパラメータ・トレードオフはtuning guide参照

メンテナンス

  • 挿入時は該当ポスティングリストに追加、リストは自動分割なし
  • prism_rebalance手続きでリスト分割可能
  • 詳細・制限事項はmaintenance guide参照

ビルド要件

  • PostgreSQL 18+(開発ヘッダ必須)
  • GCC 11+またはClang 14+、Meson
  • CBLAS(オプション、RaBitQ高速化)

ドキュメント・参考文献

  • Tuning :パラメータ・GUC・デフォルト・トレードオフ
  • Maintenance :リバランス・リスト分割
  • Architecture :設計・データ構造
  • SIMD :ビルドオプション・距離計算
  • Development :ビルド・テスト・CI
  • 研究論文 :RaBitQ(SIGMOD 2024)、SPFresh(SOSP 2023)、SPANN(NeurIPS 2021)、ScaNN for AlloyDB
  • 関連プロジェクト :pgvector、pgvectorscale(DiskANNベース)
  • ライセンス :The PostgreSQL License

注意事項・制限

  • α版のため本番利用非推奨
  • プレリリース間のアップグレード不可、再作成が必要
  • 既知の問題点・制限はchangelog参照

まとめ

  • pg_vectorsearchはPostgreSQL向け最先端ANN検索拡張
  • PRISMインデックスで大規模・高速・省メモリを実現
  • 既存pgvector環境への導入も容易
  • 今後の安定化・機能拡張に期待

Hackerたちの意見

フィルタリングはサポートされてるの? 編集: ポストフィルタリングだけみたいだけど、どうやってみんな効率的にテナントやユーザー、権限のスコープをこのインデックスで実装してるのか理解できないな。

└

マルチテナントテーブル用のマルチカラムインデックスは、将来のリリースで予定されてるよ。

└

LanceDBは、DataFusionを通じてプッシュダウンやリスト/配列のメンバーシップをサポートしてるよ。

└

メモをチェック、クライアントごと、ユーザーごと、プロジェクトごとに1つのデータベース…とかね。

└

パーティショニングは簡単な部分だと思うし、Postgresから自然に出てくるよね。でも、ベクトルデータベースで最近のバイアスをどうやって実現してるの?私たちのアプローチは高コストか、すごくハッキーなものばかりなんだよね。

今、VectorChordを使ってるんだけど、めっちゃ気に入ってる!速いバックアップディスクのおかげで、Postgresのコストが半分になったよ。低RAMのベクトルインデックスツールに競争が出てきてワクワクしてる。RAMageddonは、最新のNVMeドライブがどれだけ速いかを活かす方法を見つけるインセンティブを生み出してるみたいだね!

└

私はpg_vectorsearchの主な貢献者です。両方試してみたら、体験談や改善点を教えてください!

残念ながら、クラウドプロバイダーがマネージドPostgresで提供しないと、あまり多くの人が使えないよね…

└

もし管理されたものが欲しいなら、Tiger Cloudに移るのもアリだよ :) これはPostgreSQLライセンスだから、私たちのpg_textsearchと同じで、すでにGoogleのAlloyDBやMicrosoftのHorizonDBに採用されてるから、希望はあるよ!

PRISMのダークサイド!リポジトリの画像は、ピンク・フロイドの「ダークサイド・オブ・ザ・ムーン」に100%インスパイアされてるよ。

└

SynthIDがAIによって生成されたって報告してるよ。

SQLiteがこういうのをサポートしてくれたらめっちゃいいのに。

Hacker Newsで議論の続きを見る