pg_vectorsearch实战：亿级向量6ms查询，过滤查询却可能返回不足

Postgres 生态的向量搜索正在经历一轮新的竞争。Tiger Data（TimescaleDB 背后的公司）发布了一个名为 pg_vectorsearch 的开源扩展，用一套全新的索引 PRISM 向 pgvector 的 HNSW 发起挑战。官方 benchmark 显示，在 1 亿向量规模下，PRISM 的中位延迟仅为 6 毫秒，而 pgvector 的 HNSW 在同一台机器上甚至没跑完构建。

这个数字足够吸引眼球，但真正决定它是否适合你的，是两个容易被忽略的前提：benchmark 由厂商自己提供，以及 alpha 版本在 WHERE 子句上存在明显缺口——而这恰恰是大多数 RAG 查询的核心形态。

pg_vectorsearch 到底交付了什么

PRISM 全称 Partitioned Routing Index for Similarity Matching，是一个原生 Postgres 索引访问方法，不需要额外部署独立服务。和 HNSW 的图结构不同，它把向量按 k-means 聚成簇，每个向量以约每维一 bit 的 RaBitQ 编码存储。查询时先走质心树找到最近的簇，扫描其 posting list，用 RaBitQ 误差边界筛掉候选，再用表中的全精度向量重排序。README 把它描述为概念上接近 pgvector 的 IVFFlat。

几个实用细节值得先记住：需要 PostgreSQL 18 或更高版本；自带 vec32 和 vec16 类型，与 pgvector 的 vector、halfvec 二进制兼容；可以直接为已有的 pgvector 列建索引而不必重写表；采用 PostgreSQL License。官方的定位只有一句话——让你留在 PostgreSQL 里。

RaBitQ 编码是一种面向高维向量的量化压缩方法。它的核心思路是先将向量做随机旋转或正交变换，使其分布更均匀，再用每维约一 bit 的低精度表示来近似原始向量，同时保留一个可计算的误差上界。查询时，系统先用这个上界快速剔除明显不可能进入 top-k 的候选，只对剩下的少量向量做全精度重排序。相比传统的标量量化或乘积量化，RaBitQ 在极低位宽下仍能提供较紧的误差边界，因此在“先粗筛、再精排”的两阶段检索中特别有价值。pg_vectorsearch 正是利用这一点，把每个向量的存储开销压到极低，从而支撑起十亿级乃至更大规模的内存驻留索引。

benchmark 数字背后的条件

所有结果都来自 Tiger Data 自己的公开测试工具 rekall，recall 是相对于精确暴力搜索的 recall@10，HNSW 全部使用 halfvec。在 100 万向量规模下，PRISM 在 2GB 的 c8g.medium 上做到 99% recall、15 毫秒中位延迟，而 HNSW 在 4GB 的 c8g.large 上是 392 毫秒，构建还花了约 21.7 小时并出现内存抖动。

到 1 亿向量规模，差距更明显。官方给出的对比是：在 r8i.4xlarge（128GB）上，PRISM 构建耗时 1 小时 40 分钟、索引 25GB、95% recall 下 p50 为 6 毫秒、99% recall 下 21 毫秒；同一台机器上的 HNSW 直接没构建完成。换到 r8i.16xlarge（512GB），PRISM 构建 49 分钟、95% recall 下 4 毫秒；HNSW 构建耗时 42 小时、体积 180GB、8 毫秒，且未能达到 99% recall。

需要注意的是，官方公告没有给出两个数据集的维度、吞吐量（QPS），也没有直接的 IVFFlat 对比。多客户端吞吐测试被列为待完成项。在 Hacker News 的讨论中，有评论者明确要求补充"qps 和 precision/recall"。这些数字可以当作厂商声明来看，rekall 的存在也意味着你可以用自己的数据验证。

recall@10 是向量检索评估中的常用指标。它的含义是：对每个查询，取系统返回的前 10 个结果，再与精确暴力搜索得到的前 10 个真实最近邻相比，计算交集占 10 的比例，最后对所有查询取平均。例如 recall@10 为 95%，意味着平均每个查询返回的 10 条结果里有 9.5 条确实属于真实 top 10。这个指标只衡量“找得全不全”，不衡量“排得准不准”，也不反映延迟和吞吐。因此单独看 recall 数字容易产生误导，必须结合 QPS、p50/p99 延迟以及数据集维度一起判断。官方对比中 HNSW 未能达到 99% recall，说明在高召回区间 PRISM 的候选筛选策略可能更具优势。

alpha 版本目前做不了什么

Tiger Data 对此相当坦诚。公告称这是 pg_vectorsearch 的第一个公开版本，定级为 alpha；0.1.0-rc1 的 release notes 更直接——alpha 质量，仅供测试，不适合生产。已知问题里有几条会影响你的架构决策：

过滤查询可能返回少于 LIMIT 的行数。 如果通过 WHERE 的行不在扫描排序后的候选集里，它不会继续查找（issue #188）。一个多租户查询如 WHERE tenant_id = 7 ... LIMIT 10，可能只返回不到 10 行。

大规模有序扫描可能静默返回部分结果。 当没有 LIMIT，或 LIMIT 超出 work_mem 能承载的范围时，你只会拿到预算覆盖的那部分。调高 work_mem 可以缓解预算问题。

此外，维度上限为 1968 维，不支持 unlogged 表和表达式索引；预发布版本之间的升级可能不兼容，需要删除并重建扩展和索引。没有自动 rebalance，在高频变更下 recall 会漂移，需要手动跑 prism_rebalance 或 REINDEX；删除行占用的空间也要到 REINDEX 才会回收；复制和备份恢复测试仍在进行中。

维度上限尤其要优先核对。OpenAI 的 text-embedding-3-large 默认返回 3072 维，而 pgvector 的 HNSW 最高可索引 4000 维的 halfvec。如果你用的是这套组合，就需要先截短向量——用 OpenAI 的 dimensions 参数重新嵌入，或截断已有向量并重新归一化。

work_mem 是 PostgreSQL 中控制单个查询操作（如排序、哈希连接、索引扫描）可使用内存上限的参数。当操作所需内存超过 work_mem 时，PostgreSQL 会转向磁盘临时文件，导致性能下降；在某些索引访问方法中，超出预算的候选集可能被截断，而不是回退到磁盘继续扫描。这正是 pg_vectorsearch 在大规模无 LIMIT 有序扫描时可能静默返回部分结果的原因。调高 work_mem 可以缓解这一问题，但会按并发查询数放大整体内存占用，需要结合实例规格权衡。对于向量检索这类候选集较大的场景，适当提高 work_mem 往往比默认值更合理。

pgvectorscale 进入维护模式

如果你之前采用了 Tiger Data 更早的 pgvectorscale，这条消息对你更重要。公告称它依然稳定、可跑生产负载，但将进入维护模式，且其受 DiskANN 启发的图索引在低维数据集上可能损失 recall。一位 pgvectorscale 作者在 HN 讨论中确认了同样的说法。

问题在于，公告没有说明 pgvectorscale 用户接下来该怎么办。pgvectorscale 的 README 当时并未添加维护通知，Tiger Cloud 的扩展列表也仍包含它。公告同样没有提到 Tiger Cloud 对 pg_vectorsearch 的支持，HN 上有评论者指出它尚未出现在托管商的扩展列表中。

怎么在副本上试一把

因为需要 Postgres 18，先在表的 staging 副本上做，不要动生产库。README 展示了直接为已有 pgvector 列建索引的方式，按列类型和距离选择 operator class：vector 用 vec32_*，halfvec 用 vec16_*，后缀为 _l2_ops、_ip_ops 或 _cosine_ops。

CREATE EXTENSION pg_vectorsearch;

CREATE INDEX documents_embedding_prism
  ON documents
  USING prism (embedding vec32_cosine_ops);

SET prism.nprobe = 40; -- 0 = 自动（约 0.95 recall），调高提 recall，调低提速度

建好之后删掉 HNSW 索引，确保 planner 只能选 PRISM，再用 EXPLAIN 确认。要评估 recall，可以在同一个查询上关掉索引扫描拿到精确 top 10，对比两个 ID 列表：

BEGIN;
SET LOCAL enable_indexscan = off;
SET LOCAL enable_indexonlyscan = off;
SELECT id FROM documents
ORDER BY embedding <=> (SELECT embedding FROM documents WHERE id = 1)
LIMIT 10;
ROLLBACK;

建议用几百条真实查询做这个对比，务必包含你实际使用的过滤查询。过滤查询返回行数偏少是 issue #188 的已知行为，不是你的配置出了问题。

到底要不要换

判断标准其实很清晰。如果你的向量能装进内存，HNSW 也够快，这个 alpha 目前没有足够理由让你迁移。反过来，如果 HNSW 构建要花一整天，或者索引已经装不进内存，那就值得花一个周末在副本上试试。至于带选择性 WHERE 过滤的场景，比如按租户隔离的查询，正是 alpha 版本暴露短板的地方，也是 GA 发布时需要重点观察的查询类型。

真正的迁移阻力往往不在索引本身，而在三个外部条件：升级到 Postgres 18 的成本、过滤查询的缺口，以及你的托管商是否把新扩展列进支持列表。

PostgreSQL 扩展的托管支持是实际迁移中经常被低估的约束。pg_vectorsearch 要求 PostgreSQL 18，而主流托管商（如 Amazon RDS、Google Cloud SQL、Azure Database for PostgreSQL）通常只跟进到较旧的稳定大版本，且对第三方扩展有白名单机制。即使版本满足，扩展也需要被托管商明确列入支持列表，用户才能通过 CREATE EXTENSION 启用。Tiger Cloud 当时也未将 pg_vectorsearch 加入扩展列表。因此，在自建实例上验证成功后，仍需确认目标托管环境是否允许安装，否则可能面临无法上线的尴尬。对于依赖托管服务的团队，这一外部条件往往比索引本身的性能差异更具决定性。