在数据库领域，图索引的神话正出现裂痕。Timescale发布了基于C语言的PostgreSQL原生扩展pg_vectorsearch，推出全新的PRISM索引访问方法，直接在性能图表上击穿了行业惯性。
官方测试显示，在1亿条Cohere向量的基准环境下，PRISM索引的构建耗时仅需49分钟，体积只有25 GB。同等召回率下，pgvector的HNSW索引不仅需要耗费42小时构建，体积更膨胀到180 GB。
路线的反叛：为什么放弃图索引
过去两年，以HNSW为代表的图索引被视作向量检索的标准答案。但只要数据量迈向亿级门槛，图索引的弱点就会暴露无遗。节点间的连接指针极其耗费内存，且多层图的跳表结构让动态构建变成了I/O瓶颈。
Timescale此前曾寄希望于基于StreamingDiskANN的pgvectorscale，试图通过固态硬盘卸载图索引压力。但图连通性与召回盲区的矛盾难以在关系型引擎内抹平。官方已经明确宣布，pgvectorscale将进入维护模式，全部研发重心全面转移至PRISM。
所谓技术演进，往往不是在同一条死胡同里硬凿，而是退回旧路重新换一副轮子。
PRISM在架构上彻底放弃了图结构，回归到了类似倒排聚类的IVF思想，但给它装上了两项现代算法。具体包括分层质心树路由，以及SIGMOD 2024提出的RaBitQ量化。
这套流水线的关键在于RaBitQ具备严格的数学误差界限。系统能先用压缩极高的二进制量化计算出一个近似距离与误差上界，在倒排桶内直接裁掉不可能成为近邻的向量。需要回到堆表进行全精度计算的候选数量骤降，从而规避了关系型数据库最担心的随机回表I/O开销。
跑分话术下的实际口径
宣传数据往往经过精心挑选。官方强调的只需四分之一内存，并非指数据库进程运行时的物理峰值内存（RSS），而是两套评测选用的云服务器硬件配置。
在AWS的r8i.4xlarge规格（128 GiB内存）上，PRISM耗时1小时40分钟完成构建，且p50延迟维持在6毫秒；但同一个机器规格下，pgvector的HNSW直接报错无法完成构建，必须换到512 GiB内存规格才能跑通。这个四倍差距，本质上是能否把图索引全部装入内存的实例门槛，并非绝对计算效率的线性等比。
同时，对照组里的HNSW使用的是16位halfvec类型，本就是牺牲精度换取容量的折中方案。更深层的理论局限在于，RaBitQ的误差界限只作用于被路由命中的分区内部。如果第一阶段的层级质心路由树在搜索时漏掉了真实近邻所在的分区，后续的剪枝和全精度重排再精准，也无济于事。
Alpha阶段的生产陷阱
性能跑分只是实验室里的成绩，工程落地看的是异常边界。翻看项目的开源代码库，目前的pg_vectorsearch带有严重的早期缺陷。
最为棘手的是Issue #188所披露的问题。在带有SQL谓词过滤的查询场景中，PRISM的执行器端过滤在耗尽粗排候选池后，不会自适应向后步进，而是直接返回少于LIMIT甚至0条结果。这在重视元数据混合过滤的企业级RAG业务中属于阻断性故障。此外，Issue #187还指出了全表统计场景下的静默截断异常。
在数据库运维层面，PRISM写入数据后倒排表不会动态分裂，PostgreSQL自带的VACUUM目前仅能标记删除，无法真正回收索引页空间。系统严重依赖管理员手动调用prism_rebalance存储过程进行维护。更关键的是，该扩展强行依赖尚未正式发布的PostgreSQL 18+。
- 结论.PRISM通过数学量化与分层路由，证明了倒排索引在超大规模向量检索中对重型图索引的降维打击能力。
- 风险.当前版本仍处于Alpha极早期阶段，过滤截断Bug与静态维护缺陷意味着它还完全无法承载生产流量。