データと文書

Timescale、PostgreSQL向け高性能ベクトルインデックス「pg_vectorsearch」をリリース

Timescaleは、PostgreSQLにおける近似最近傍探索を高速化するPRISMインデックスを導入するアルファ版拡張機能「pg_vectorsearch」を公開しました。

机の上のガラスの立方体の中に描かれたベクトルデータ構造のイラスト
この記事用に生成されたイラスト

英語の原文から自動翻訳されました。

Timescaleは、ベクトルデータに対する近似最近傍探索(ANN)を高速化するために設計された新しいPostgreSQL拡張機能「pg_vectorsearch」をリリースしました。2026年10月14日に公開されたこのアルファ段階のツールは、既存のHNSWやIVFFlatなどのソリューションを上回る速度とメモリ効率を目指した「PRISMインデックス」を導入しています。本リリースは、既存のリレーショナルデータベース内でスケーラブルなベクトル基盤を必要とする、検索拡張生成(RAG)システムを開発するエンジニアを対象としています。

何が起きたか

今回のリリースの中核となるのは、PRISMインデックスです。これは「Partitioned Routing Index for Similarity Matching」(類似性マッチングのためのパーティション化ルーティングインデックス)の略称であり、PostgreSQL内部との密接な統合を実現するためC言語で実装されています。発表によると、PRISMはクエリ実行およびインデックス構築の両方において、pgvectorのIVFFlatおよびHNSWインデックスよりも大幅に高速です。1億個のベクトルを含むデータセットを用いたベンチマークでは、PRISMはグラフベースのHNSWと同等のリコール率を達成しつつ、メモリ使用量はわずか4分の1に抑えられ、より高速なクエリ応答を実現しました。

この拡張機能は動的更新に対応しており、インデックス全体の再構築を行わずに挿入、更新、削除が可能です。ただし、メンテナーは現在このソフトウェアがアルファステータスであり、本番環境での使用ではなくテスト目的であることを明確に述べています。プレリリース間でのアップグレードができない場合があるため、プロジェクトの進化に伴い、拡張機能とそのインデックスを削除して再作成することを計画しておくことを推奨します。既知の問題点は変更履歴(changelog)で追跡されています。

仕組み

PRISMは階層型セントロイドツリーを使用してベクトルをクラスタに分割し、このルーティング構造をメモリ内に保持するためにPostgreSQLバッファキャッシュを利用します。このアプローチにより、システムはデータセット全体をスキャンすることなく、関連するクラスタを迅速に特定できます。最も近いクラスタが特定されると、システムはポスティングリストをスキャンして候補ベクトルを生成します。これらのリストはSIMD距離計算用に最適化されており、対応ハードウェア上で計算を加速するためにAVX2、AVX512、NEON命令を活用しています。

主要な技術的特徴の一つは、RaBitQ量子化の使用です。この手法は理論的な誤差境界付きでベクトルをエンコードし、二段階の検索プロセスを可能にします。第一段階では距離を推定し、誤差境界を利用して最近傍になり得ないベクトルを除外します。このフィルタリングステップにより、テーブルヒープに格納されているフル精度ベクトルに対して再ランキングが必要な候補数が大幅に削減されます。最終ステップでは、この効率的なフィルタリングと再ランキング処理を経て、k個の最近傍が返されます。

主な詳細

  • インデックスタイプ: PRISM(Partitioned Routing Index for Similarity Matching)。階層型ルーティングを採用したIVFスタイルのインデックスです。
  • 量子化: 効率的な二段階検索フィルタリングのために、理論的な誤差境界を持つRaBitQ量子化を使用します。
  • ハードウェアアクセラレーション: 距離計算は、AVX2、AVX512、NEONなどのSIMD命令向けに最適化されています。
  • 互換性: 既存のpgvector vector および halfvec 列を直接インデックス化するか、ネイティブの vec32 および vec16 タイプを使用できます。
  • メンテナンス: 動的な挿入、更新、削除に対応しており、ポスティングリストの分割は prism_rebalance プロシージャを通じて管理されます。
  • ステータス: テストを目的としたアルファリリースです。プレリリース間のアップグレードには、インデックスの削除と再作成が必要になる場合があります。

なぜ重要なのか

AIアプリケーションを構築するエンジニアにとって、データセットの成長に伴いベクトル検索のパフォーマンスがボトルネックになることがよくあります。HNSWなどの従来のグラフベースインデックスは大量のメモリを消費し、インフラコストを増加させます。PRISMがHNSWが必要とするメモリの一部で1億個のベクトルを処理できることを示すことで、この拡張機能はよりコスト効率の高いスケーリングへの道を提供します。これにより、チームはトランザクションデータと同じPostgreSQL内にベクトルデータを保持でき、アーキテクチャが簡素化され、個別のベクトルデータベースサービスへの依存が減ります。

既存のpgvectorテーブルとの互換性は、移行において特に重要です。開発者は新しいインデックスをテストするためにスキーマやアプリケーションロジックを書き直す必要がありません。pgvectorと一緒にpg_vectorsearchをインストールし、既存の列にPRISMインデックスを構築できます。これにより、初期アルファ段階であっても、新しいインデックス方式の採用に伴う運用複雑さを正当化するほどのパフォーマンス向上が見込めるかを評価するための参入障壁が低くなります。

実施可能なこと

  • PostgreSQL 18以降と、GCC 11+やClang 14+などのGNU C11コンパイラをインストールして環境を準備してください。
  • Mesonビルドシステムを使用してソースから拡張機能をビルドしてください。その際、必要なPostgreSQL開発用ヘッダーファイルが存在することを確認してください。
  • 既存の vector または halfvec 列にPRISMインデックスを作成することで、非本番データセットで拡張機能をテストしてください。
  • prism.nprobe パラメータを試して、特定のワークロードにおけるクエリ速度とリコール精度のトレードオフを調整してください。
  • 既知の問題点については変更履歴を監視し、新しいプレリリースバージョンをテストする際にインデックスの削除と再作成ができるよう準備しておいてください。
  • 動的な挿入および更新操作中のインデックスパフォーマンス維持のために prism_rebalance プロシージャの評価を行ってください。

Bytechapストアのツール

続きを読む

すべての記事