Tech Teardown 025｜pg_vectorsearch：Timescale 公式のベクトル検索新インデックス、1 億ベクトル 6 ミリ秒

10月13日、Timescale（現在はTiger Dataに改名）はGitHubで新しいリポジトリpg_vectorsearchをオープンソース化しました。これはPostgreSQLの近似最近傍検索拡張であり、核心は自社開発のPRISMインデックスです。翌日にはHacker Newsに掲載され、約200件の「いいね」と50件のコメントが寄せられました。その人気の理由は三つあります：出資者はTimescaleDBを開発する老舗のPostgreSQLチームであり、公式ブログでの宣伝もかなり刺激的でした（1億個のベクトル、95%の再認識率、P50の遅延が6ミリ秒であり、対照的なHNSWは同じ仕様のマシンではインデックスを構築できない）。また、pgvectorの主流な技術路線とは異なる技術路線を選択しています：グラフインデックスを使わず、パーティションインデックスを使用します。しかし、最も重要な点を最初に置きます：READMEのステータスバーには「Meant for testing, not production」と記載されており、テスト用のみで、実際の運用には使用しないよう注意が促されています。この記事では、従来の方法で6つのセクションに分けて説明します。

一、それは何か

pg_vectorsearchはPostgreSQLの高性能ANN（近似最近傍）検索拡張であり、PRISMというインデックスアクセス方法を提供します。正式名称はPartitioned Routing Index for Similarity Matchingです。これはIVF式インデックスであり、ベクトル空間を重心に基づいてクラスターに分割し、検索時には最も可能性が高い少数のクラスターのみをスキャンします。これは「パーティションスキャン」の流派であり、pgvectorのHNSWのような「グラフ上での探索」の流派ではありません。設計の背景はリポジトリのAGENTS.mdに記載されています：GoogleのScaNN for AlloyDBやMicrosoftのSPANNからインスピレーションを得て、ベクトルフォーマットはpgvectorの規格を維持しています。

その特徴には3つの点があります。第一に、これはTimescaleが公式にリリースしたものであり、同じチームが2024年にpgvectorscale（DiskANNグラフインデックス、HN上の前のコメンテーターが作者の一人であると述べていました）をオープンソース化しました。これはPostgreSQLのベクトル検索における2回目の取り組みであり、ブログではpgvectorscaleがメンテナンスモードに移行し、リソースが新しいインデックスに集中していると明確に発表されています。第二に、これはpgvectorと互換性があり、代替わりするものではありません：既存のvector/halfvec列を書き換えたりコピーしたりする必要なく、直接PRISMインデックスを構築できます。pgvectorの演算子で書かれたクエリは正常に動作します。また、vec32/vec16の2種類の型を持っており、pgvectorをインストールせずに独立して運用できます。第三に、これはアルファバージョンであり、プレビュー版間でアップグレードの道がない可能性があります。公式にはdropと再構築の準備を整えるよう推奨されています。

一言で位置づけると：これは「ゼロマイグレーションコストでの試験」に適したパーティショニングベクトルインデックスであり、技術的な方向性は刺激的ですが、エンジニアリングの成熟度はまだ低いです。

二、リポジトリ構造

まず、小さな誤りを訂正します：GitHubの言語タグではこのリポジトリがRustとしてマークされていますが、実際には純粋なC拡張です。srcディレクトリ内の.cファイルの44006行目を含む全てのコードは第三者コードではありません。.cファイルは合計62575行、.hファイルは合計13303行です（リポジトリの表示内容による）。ライセンスは緩やかなPostgreSQL Licenseで、構築にはPostgreSQL 18+、GCC 11またはClang 14以上、Mesonビルドシステムが必要です。選択可能なリンクとしてCBLAS加速のRabitQコーディングがあります。

src下のモジュール構造は、アルゴリズムの階層構造に明確に対応しています：algoにはクラスタリングと距離計算が、indexにはインデックスの構築とスキャンが、quantには量子化が、pgにはPostgreSQLのベースライン層が、standaloneには独立したエンジンが配置されています。algo内ではkmeansの3つのバリエーション（lloyd、elkan、hamerly）およびhkmeans階層クラスタリングが見られます。クラスタリングはインデックスを構築する核心的なステップであり、3つのアルゴリズムはそれぞれ異なるデータサイズに適しています。quant内にはrabitqとfastscanの2つの実装があり、それぞれavx2、avx512、neonの3つのSIMDバージョンをサポートしています。index内のcentroid_build、centroid_search、posting_build、posting_scan、posting_splitなどのファイルは、「重心木」と「逆順表」という2つのデータ構造の読み書きパスを明確に分けています。

もう一つの注目すべき構造的特徴は、リポジトリ自体が持つAI支援開発設定です：.claude/skills下にはbuild-feature、create-pr、git-workflow、profiling、release、review、security-review、testingの8つのスキルファイルがあり、さらにAGENTS.mdとCLAUDE.mdが存在し、このプロジェクトがClaude Codeのワークフローに従って開発されていることが記載されています。コードがAIによって生成されたかどうかは作者によって明言されていませんが、ここではリポジトリ自体がこの設定を持っている事実を述べています。公式のC拡張がagentワークフロー設定を直接リポジトリに置いている点は、コード量よりも観察に価値のあるプロジェクト実践です。

三、メカニズムの分解

PRISMのクエリパスは5ステップです：まず階層重心木を通じて最も近いいくつかのクラスタを探し（木は常駐バッファキャッシュを使用）、次にこれらのクラスタのposting listをスキャンして候補を得る（非同期I/O）、その後RabitQを使用して2段階フィルタリングを行い、最後に生存者に対してピークツリー内の全精度ベクトルで再配置し、k個の最も近いノードを返します。

3つの技術的支柱を一つずつ分解します。第一にパーティションルーティングです：ベクトル空間はkmeansによってクラスタに分けられ、クラスタは浅い重心木として組織されます。クエリ時には上から下へとルーティングが行われ、ごく一部のパーティションのみが接触されます。これはIVFFlatの概念と同じであり、違いは木構造のルーティングによって「どのクラスタをスキャンするか」という作業自体が速くなる点です。ブログではPRISMがScaNNのようなSOARオーバーフロー技術を実装していることも言及されています：境界ベクトルは隣接する2番目のクラスタに同時に保存され、少しのストレージで recallを得ることができます。

第二はRaBitQの量化であり、SIGMOD 2024の論文からのもので、理論的な誤差範囲を含む二値量化が特徴です。各量化ベクトルには誤差範囲が付いており、検索時にはまず推定距離を計算し、誤差範囲を利用して「前kに入ることが不可能な」ベクトルを直接除外します。残りの少数の候補のみがフロントテーブルで全精度の再配置が必要です。誤差範囲は経験的な閾値ではなく、数学的な保証であり、これが一般的な二値量化方案との重要な違いです。posting listのページレイアウトもSIMD距離計算のために特別に設計されています。

第三はSIMDとエンジニアリングの統合です：距離計算カーネルはAVX2、AVX512、NEONの3つの命令セットでそれぞれ実装されており、同じコードがPostgreSQL拡張とstandaloneエンジンに組み込まれています。これにより、データベースのボトルネックを分離してアルゴリズムを単独でテストすることが容易になります。重心木はPostgreSQLの共有バッファキャッシュを利用し、ベクトルデータはディスクページシステムを通じて処理され、MVCCとストリームコピーも設計目標に含まれています。

調整パラメータは極限まで簡素化されています：クエリ側にはprism.nprobe（スキャンするクラスタ数）のみがあり、デフォルトでは0で自動的に値が選択されます。約95%の回収率を目指し、大きくすると回収率が、小さくすると速度が変わります。更新については、ベクトルをルートに当たったposting listに追加し、listは自動的に分割されることはなく、公式にはprism_rebalanceストレージプロシージャを提供しており、過度に大きなパーティションを手動で分割するか、直接REINDEXで再構築できます。

四、数字と検証

以下のベンチマークの数字はすべてTiger Dataの公式ブログ（2026-10-13）からのもので、公式の数値です。第三者による独立した再検証はありませんので、信頼する際にはこの割引を考慮してください。

大規模シナリオ：1億個のCohereベクトルを使用し、2台のAWSインスタンスで比較を行いました。r8i.4xlarge（16 vCPU/128 GiBメモリ）とr8i.16xlarge（64 vCPU/512 GiB、時価は4倍高価）です。PRISMは小規模なマシンで索引を作成するのに1時間40分かかり、95%の回収率でP50遅延は6ミリ秒、99%の回収率では21ミリ秒です。HNSWはこのマシンでは全く索引を作成できず、大規模なマシン（512 GiB）に移して42時間かけて索引を作成しました。95%の回収率では8ミリ秒でしたが、99%の回収率では利用可能な遅延には達しませんでした。同じ大規模なマシンでPRISMは49分で索引を作成し、P50は4ミリ秒（95%）/19ミリ秒（99%）でした。公式はまた、大規模なマシンで作成されたHNSW索引を小規模なマシンでクエリする試みも行いましたが、95%の回収率では単一のクエリが1秒を超えてしまいました。結論として、HNSWはこの規模では大容量メモリなしではクエリできないということです。

小シーン：100万ベクトルに対して、PRISMは2GiBのメモリを搭載したc8g.medium上で99%のRECALL率と15ミリ秒の遅延を実現している。HNSWでは2倍のメモリが必要で、遅延は392ミリ秒であり、公式発表では23倍以上の遅さとなっている。インデックスを構築するには4GiBのメモリが必要で、PRISMでは約3分、HNSWでは約21.7時間かかる（図形を構築中にメモリに格納できないため不安定になる）。ベースラインの公式発表にも一言触れておく：HNSWはpgvectorの16ビット半ベクトルを使用しており、これが彼らのテストでHNSWの最適なバランスであると公式は述べている。

公式自身がCHANGELOGの「Known issues」に短板を記載している：頻繁な書き込みによりRECALL率が変動し、パーティションは自動的に再分割されず、手動でのprism_rebalanceまたはREINDEXが必要である。公式は将来的に自動化を計画している。インデックスの次元上限は1968。削除時には墓碑のみが作成され、インデックスページの空間は回収されない。WHEREフィルタを含むクエリでは、LIMITより少ない行が返される可能性があり、スキャンでは候補を再検索しない（つまり後ろのフィルタのみ）。LIMITがwork_memの許容範囲を超える場合、ソートバウントは静的に切り捨てられる。HNのコメントセクションでも後ろのフィルタに疑問を持ち、複数テナントや権限隔離シナリオでこの種のインデックスをどのように使用するかについて質問があったが、公式は正面から回答していない。あるコメンテーターの初期実験でも次元上限に注意が払われていた。

五、判断

3点に注目すべき点がある。

第一に、選択肢の方が数字よりも重要である。HNSWは過去数年間のベクトル検索の標準的な答えであり、GoogleのScaNN、MicrosoftのSPANN、turbopufferの新世代エンジンも「パーティション+量化+SIMDスキャン」に移行している。その理由は、順番にメモリをスキャルトする方が現代のCPUにとって優しく、グラフのトラバースはランダムアクセスであるからだ。PRISMはPostgreSQLエコシステムにおけるこの路線の最新の進化である。公式の数字が半分になるとしても、「小さなメモリのマシンで大きなインデックスをサポートできる」という構造的な利点はグラフインデックスでは得られない：HNSWのグラフは基本的にメモリ内に常驻する必要があり、PRISMの量化されたposting listはディスク上に安心して置かれ、必要な時にスキャルトできる。

第二に、pgvectorとの互換性が賢明な実装戦略である。ユーザーにテーブルやクエリ、オペレーターの移行を強いることなく、既存の列に追加のインデックスを構築することで比較テストが可能であり、試行錯誤のコストはほぼゼロである。これはまた「それがpgvectorを置き換えるかどうか」という問いにも答えている：そうではない。それはpgvectorエコシステム内の取り外可能なインデックスバックエンドのようである。コメントセクションで、なぜ直接pgvectorにPRを提出しないのかと質問があるが、公式は回答していない。しかし、pgvectorscaleからメンテナンスモードへの移行を見ると、Timescaleが求めているのは自分でイテレーションのペースをコントロールできる独立した製品である。

第三に、alphaの短板は実際のものであり、単なるバージョン番号の謙虚さではない。複数テナントのSaaSにおいて、後ろのフィルタのみが「まずこのテナントに属さない候補をスキャルトしてから捨てる」ことを意味する。フィルタ条件が厳しければ厳しいほど効率が悪くなる。これはCHANGELOGが認め、コメントセクションで問いかけられ、公式がまだ解決していない痛点である。1968の次元上限は高次元モデルの一部を排除している。churnシナリオでは手動でrebalanceを行う必要があり、運用負荷は実際に存在する。これらに加えて「事前発売バージョンはスムーズなアップグレードができない」という点も、未成熟なリストを構成している。

ちょっとしたエンジニアの観察：公式のC拡張リポジトリには、Claude Codeワークフロー設定が完全に含まれています（8つのスキルファイルとAGENTS.md）。これは、AIを活用した開発が、従来最も保守的な分野であるデータベースコアにまで進出していることを示しています。コードの品質は最終的にはテスト結果で判断されますが、リポジトリに設定を追加する行為自体が、インフラ構築を行うすべてのチームにとって見る価値があります。

六、誰が、どのように使うか

テストに適した環境：ベクトルサイズが千万から億単位で、HNSWのメモリ使用量に悩まされている、PostgreSQL内での運用を望む（ビジネスデータとのJOINやシングルトランザクション更新が必要）、そしてアルファリスクを受け入れることができるチームに適しています。pgvectorを既に使用している場合は、CREATE EXTENSION pg_vectorsearchの後、既存のベクトル列上で直接CREATE INDEX…USINGprismを実行し、EXPLAINを使って新しいインデックスが使用されているか確認します。2つのインデックスを共存させて一定時間比較した後、満足してHNSWを削除します。オペレーターの対応関係は、vector_l2_opsからvec32_l2_opsに変更され、halfvecはvec16に変更されます。L2、内積、コサインの3種類の距離がサポートされています。

最適化は1つの設定で済みます：prism.nprobeはデフォルトで約95%のrecallを自動的に調整します。より高いrecallが必要ならば設定を大きくし、より低い遅延が必要ならば小さくします。頻繁にデータが書き込まれるデータベースでは、prism_rebalanceを運用計画に含めるか、定期的にREINDEXを行います。公式には、空のテーブルにインデックスを作成してからデータを追加することを推奨していません。多くのデータが削除される場合は、インデックススペースが自動的に回収されないことに注意してください。

生産環境での推奨事項は1つだけです：beta版がリリースされるのを待ちます。公式のロードマップには、自動的なrebalance、フロー式フィルタリング検索（WHEREとORDER BYを組み合わせて候補を継続的に生成）、物理コピーとバックアップ復元の強化テストが含まれており、これらは現在最も問題がある点に対応しています。現在最も合理的な方法は、実データをテスト環境で実行し、結果をGitHubにフィードバックすることです。公式ブログの言葉を借りれば、「もしあなたの結果が私たちのものと異なる場合は、issueを開いてください。私たちが調査します」。

それを使用しない開発者にとっても、このリポジトリは読む価値があります：src/algoには3種類のkmeansバリエーションのエンジニアリング実装があり、quantにはSIMDを使用した3種類のRaBitQコーディングがあり、AGENTS.mdには完全なC拡張開発ガイドラインがあります。これらはすべて、データベースコアエンジニアリングの第一級の教材です。

情報源

• リポジトリとドキュメント：github.com/timescale/pg_vectorsearchのREADME、CHANGELOG（0.1.0, 2026-10-13）、AGENTS.md、srcディレクトリ構造およびコード行数（10〜15のリポジトリを検証、find+wcによる統計）
• benchmarkの全数字（1億/100万ベクトル、遅延、インデックス作成時間、マシン仕様、halfvecベースライン）：Tiger Data公式ブログ「Announcing pg_vectorsearch」（tigerdata.com, 2026-10-13）、すべて公式情報、本文に記載あり
• 既知の問題（churnの変動、1968次元の上限、後処理フィルタリング、空間の再利用不可、work_memの切り捨て）：CHANGELOG 0.1.0 Known issues 原文
• HNの議論（約200▲/50コメント、後処理フィルタリングに関する疑問、次元の上限の実測値、pgvectorscaleの作者の登場）：HNストーリーとコメント池、2026-10-14に掲載、コメントは伝聞として扱う
• 「ScaNN/SPANNからのインスピレーション」「pgvectorscaleの前作とメンテナンスモード」：AGENTS.mdの自述と公式ブログ
• 星数は正確な値を取っていない、本文は「公式の新発表/発表日数」の基準で処理する