pg_vectorsearch 推出 PRISM 索引，以分區加 RaBitQ 壓縮取代 HNSW 圖索引
Timescale（Tiger Data）· 2026-10-13 發表公告 · 授權 PostgreSQL License · 目前為 alpha
Timescale 開源的 pg_vectorsearch 提供名為 PRISM 的索引存取方法，用「分區加量化」取代 pgvector HNSW 的圖結構，目標是讓大型向量索引不再需要把整張圖塞進記憶體。它可以直接建在現有 pgvector 欄位上，不必改寫或複製資料。官方公告發表於 2026-10-13，README 明確標示「僅供測試，不適合上線」。
原本的問題
pgvector 的 HNSW 搜尋是在圖上反覆做隨機讀取，每一跳的位址取決於上一個節點，CPU 常在等記憶體，效能因此高度依賴把大部分圖留在記憶體中。公告指出建索引時也有同樣問題：在 1M 向量、4 GiB 的機器上，圖放不進記憶體，建置會一直 thrashing，最後沒有完成。
規模放大後更明顯。公告說在 100M 向量時，能完成 HNSW 建置的最小機器有 512 GB 記憶體。換言之，向量資料一大，HNSW 就逼著你買更大的機器。
PRISM 的做法
PRISM 全名是 Partitioned Routing Index for Similarity Matching，概念上接近 IVFFlat，但加了三個機制，詳見 README：
- 質心樹路由：以階層式質心樹把向量分群，這棵樹常駐 PostgreSQL buffer cache，每次查詢先選出最近的幾個分區。
- RaBitQ 量化：每個向量存成約每維度一位元的編碼，連續放在 posting list 中，頁面配置針對 SIMD 計算（AVX2、AVX512、NEON）。
- 兩階段搜尋：先用 RaBitQ 的誤差界排除不可能的候選，只有剩下的才回 heap 拿完整向量重排序。
因為分區內是循序掃描，預取器跟得上，這正好避開圖索引的隨機存取。公告也提到邊界向量會多存一份到第二個分區，以保護召回率。
實測數字
以下為公告表格中的 recall@10、p50 延遲，比較對象只有 pgvector HNSW，公告沒有 IVFFlat 的數據。
| 情境 | 演算法 | 建置時間 | 索引大小 | p50 @95% |
|---|---|---|---|---|
| 1M，c8g.large（4 GiB） | PRISM | 約 3.1 分鐘 | 280 MB | 3 ms |
| 1M，c8g.large（4 GiB） | HNSW | 約 21.7 小時 | 2.05 GB | 122 ms |
| 100M，r8i.16xlarge | PRISM | 49 分鐘 | 25 GB | 4 ms |
| 100M，r8i.16xlarge | HNSW | 42 小時 | 180 GB | 8 ms |
在只有 2 GiB 的 c8g.medium 上，PRISM 仍能建完 1M 向量，HNSW 沒有完成。100M 向量放在 128 GiB 的 r8i.4xlarge，PRISM 建置 1 小時 40 分鐘、p50 為 6 ms，HNSW 同樣沒有完成。這些都是廠商自己的基準，公告未說明向量維度，1M 資料集的來源也未交代。
用法與限制
既有 pgvector 表只要加一個索引，operator class 的對應是 vector_*_ops 換成 vec32_*_ops，halfvec_*_ops 換成 vec16_*_ops：
CREATE EXTENSION pg_vectorsearch;
CREATE INDEX documents_embedding_prism
ON documents USING prism (embedding vec32_l2_ops);
SET prism.nprobe = 40; -- 0 為自動，約 95% 召回它需要 PostgreSQL 18 以上。有幾個限制會直接影響你怎麼用：
- 先載入資料再建索引，因為索引大小由建立當下的列數決定。
- 插入不會自動分裂 posting list，大量寫入後要手動執行
CALL prism_rebalance('idx');或REINDEX，維護文件說明 rebalance 目前只支援單層且關閉centroid_fastscan的索引，屬實驗功能。 - TOAST 會拖慢重排序：向量超過約 2 kB 會被 TOAST，README 建議欄位設
STORAGE PLAIN。 - README 稱升級 prerelease 版本之間可能無法升級，需要 drop 後重建；專案目前沒有發布版本。
影響範圍
受益最大的是資料量在千萬到上億筆、卻受限於 HNSW 建置記憶體的 pgvector 使用者，以及想用小機型跑向量搜尋的團隊。公告自己承認，頻繁更新的小型資料集仍然比較適合圖索引，且大量變動後召回率可能漂移。如果你的負載是持續寫入，先在測試環境量 prism_rebalance 的成本，再考慮取代 HNSW；上線前也要等它脫離 alpha。