技术拆解 025｜pg_vectorsearch：Timescale 官方向量检索新索引，1 亿向量 6 毫秒

10 月 13 日，Timescale（现已更名 Tiger Data）在 GitHub 开源了新仓库 pg_vectorsearch，一个 PostgreSQL 的近似最近邻检索扩展，核心是自研的 PRISM 索引。第二天它就登上 Hacker News 引发讨论，约 200 个赞、50 条评论。热度来自三点：出品方是做 TimescaleDB 的老牌 PostgreSQL 团队，官方博客给出的数字相当激进（1 亿向量、95% recall、P50 延迟 6 毫秒，而对比的 HNSW 在同规格机器上连索引都建不起来），以及它选择了一条与 pgvector 主流方案不同的技术路线：不做图索引，做分区索引。但先把最要紧的一句话放在最前面：README 状态栏原话是「Meant for testing, not production」，仅供测试，勿用于生产。本文按老规矩拆六段。

一、它是什么

pg_vectorsearch 是 PostgreSQL 的高性能 ANN（近似最近邻）检索扩展，提供名为 PRISM 的索引访问方法，全称 Partitioned Routing Index for Similarity Matching。它是 IVF 式索引：把向量空间按质心切成一个个簇，查询时只扫最可能命中的少数簇，属于「分区扫描」流派，而不是 pgvector 的 HNSW 那种「图上行走」流派。设计渊源写在仓库的 AGENTS.md 里：受 Google 的 ScaNN for AlloyDB 与 Microsoft 的 SPANN 启发，向量格式沿用 pgvector 的规范。

它的身份有三层值得说清。第一，这是 Timescale 官方出品，同一团队 2024 年开源过 pgvectorscale（DiskANN 图索引，HN 上一位评论者自述是作者之一），这次是他们在 PostgreSQL 向量检索上的第二次出手，而且发布博客明确宣布 pgvectorscale 转入维护模式，资源向新索引倾斜。第二，它兼容 pgvector 而非替代：已有的 vector/halfvec 列不用重写、不用复制，直接在上面建 PRISM 索引就行，用 pgvector 操作符写的查询照常工作；它也自带 vec32/vec16 两种类型，可以不装 pgvector 独立运行。第三，它是 alpha：预发布版本之间可能没有升级路径，官方建议做好 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 的三个变体（lloyd、elkan、hamerly）加 hkmeans 层次聚类，聚类是建索引的核心步骤，三种算法各适合不同数据规模。quant 里是 rabitq 和 fastscan 两组实现，各自带 avx2、avx512、neon 三个 SIMD 版本。index 里的 centroid_build、centroid_search、posting_build、posting_scan、posting_split 等文件，把「质心树」和「倒排表」两个数据结构的读写路径分得很干净。

另一个值得注意的结构特征是仓库自带的 AI 辅助开发配置：.claude/skills 下有 build-feature、create-pr、git-workflow、profiling、release、review、security-review、testing 八个技能文件，外加 AGENTS.md 和 CLAUDE.md，写明这个项目按 Claude Code 的工作流开发。代码是否由 AI 生成，作者没有明说，这里只陈述仓库自带这套配置的事实。一个官方 C 扩展把 agent 工作流配置直接放进仓库，这个工程实践本身比代码量更有观察价值。

三、机制拆解

PRISM 的查询路径是五步：先走层次质心树找到最近的若干簇（树常驻 buffer cache），再扫这些簇的 posting list 拿候选（异步 I/O），然后用 RaBitQ 做两阶段过滤，最后对幸存者用堆表里的全精度向量重排，返回 k 个最近邻。

三个技术支柱逐个拆。第一是分区路由：向量空间被 kmeans 聚成簇，簇再组织成一棵浅层的质心树，查询时自上而下路由，只碰一小部分分区。这与 IVFFlat 概念同源，区别在于树状路由让「扫哪些簇」这件事本身也变快了。博客还提到 PRISM 实现了类似 ScaNN 的 SOAR 溢出技术：边界向量同时存进相邻的第二个簇，用一点存储换 recall。

第二是 RaBitQ 量化，出自 SIGMOD 2024 的论文，卖点是带理论误差界的二值量化。每个量化向量自带一个误差范围，搜索时先算估计距离，再用误差界直接排除「不可能进前 k」的向量，剩下的少数候选才需要回表做全精度重排。误差界是数学保证而不是经验阈值，这是它和一般二值量化方案的关键区别。posting list 的页布局也为 SIMD 距离计算专门设计过。

第三是 SIMD 与工程集成：距离计算内核按 AVX2、AVX512、NEON 三套指令集分别实现，同一份核心代码既编进 PostgreSQL 扩展也编进 standalone 引擎，方便隔离数据库瓶颈单独测算法。质心树依赖 PostgreSQL 的共享 buffer cache 保温，向量数据走磁盘页系统，MVCC 和流复制都在设计目标里。

调参被刻意压到极简：查询侧只有一个 prism.nprobe（扫描的簇数），默认 0 表示自动选值，瞄准约 95% recall，调大换 recall、调小换速度。更新方面，插入把向量追加到路由命中的 posting list，list 只增不自动分裂，官方提供 prism_rebalance 存储过程手动分裂过大的分区，或者直接 REINDEX 重建。

四、数字与验证

以下 benchmark 数字全部来自 Tiger Data 官方博客（2026-10-13），是官方口径，尚无第三方独立复测，采信时请带这个折扣。

大场景：1 亿条 Cohere 向量，两台 AWS 实例对比，r8i.4xlarge（16 vCPU/128 GiB 内存）和 r8i.16xlarge（64 vCPU/512 GiB，时价贵 4 倍）。PRISM 在小机器上建索引 1 小时 40 分，95% recall@10 的 P50 延迟 6 毫秒，99% recall 21 毫秒；HNSW 在这台机器上根本建不起来，换到大机器（512 GiB）建了 42 小时，95% recall 8 毫秒，但 99% recall 达不到可用延迟。同一台大机器上 PRISM 建索引 49 分钟，P50 4 毫秒（95%）/19 毫秒（99%）。官方还试过把大机器上建好的 HNSW 索引搬到小机器查询，95% recall 时单次查询超过 1 秒，结论是 HNSW 在这个规模上查询也离不开大内存。

小场景：100 万向量，PRISM 在 2 GiB 内存的 c8g.medium 上做到 99% recall、15 毫秒延迟；HNSW 需要两倍内存的机器，延迟 392 毫秒，官方口径慢 23 倍以上。建索引 4 GiB 机器上 PRISM 约 3 分钟，HNSW 约 21.7 小时（图在构建期放不进内存导致颠簸）。基线口径也交代一句：HNSW 用的是 pgvector 的 16-bit halfvec，官方称这是他们测试中 HNSW 的最佳权衡。

短板官方自己写在 CHANGELOG 的 Known issues 里：高频写入会导致 recall 漂移，分区不会自动重分裂，需要手动 prism_rebalance 或 REINDEX，官方计划未来自动化；索引维度上限 1968；删除只打墓碑不回收索引页空间；带 WHERE 过滤的查询可能返回少于 LIMIT 的行，扫描不会回头补候选（即只有后过滤）；LIMIT 超过 work_mem 允许的排序预算时会被静默截断。HN 评论区也对后过滤提出了质疑，有评论者问多租户、权限隔离场景该怎么用这类索引，官方未正面回应；一位评论者的初步实测同样注意到了维度上限。

五、判断

三处值得盯。

第一，路线选择比数字更重要。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 工作流配置（八个技能文件加 AGENTS.md），说明 AI 辅助开发已经进入数据库内核这类传统上最保守的工程领域。代码质量最终以测试结果说话，但配置进仓库这个动作本身，值得每个做基础设施的团队看一眼。

六、谁能用怎么用

适合测试的画像：向量规模在千万到亿级、被 HNSW 的内存账单压得难受、想留在 PostgreSQL 里（要 join 业务数据、要单事务更新）、且能接受 alpha 风险的团队。已经用 pgvector 的场景最省事：CREATE EXTENSION pg_vectorsearch 之后，在现有 vector 列上直接 CREATE INDEX … USING prism，跑 EXPLAIN 确认查询计划走了新索引，两个索引并存对比一段时间，满意了再 drop 掉 HNSW。操作符类的对应关系是 vector_l2_ops 换 vec32_l2_ops，halfvec 换 vec16，L2、内积、余弦三种距离都支持。

调优就一个旋钮：prism.nprobe 默认自动瞄准约 95% recall，要更高 recall 就调大，要更低延迟就调小。写入频繁的库要把 prism_rebalance 排进运维计划，或者定期 REINDEX；官方明确不建议在空表上建索引再灌数据。删除多的场景注意索引空间不会自动回收。

生产环境的建议只有一句：等它出 beta。官方路线图上有自动 rebalance、流式过滤搜索（WHERE 与 ORDER BY 配合持续产出候选）、物理复制与备份恢复的加固测试，这些恰好对着当前最痛的几个短板。现在最合理的姿势是拿真实数据在测试环境跑起来，把结果反馈到 GitHub，官方博客原话是「如果你的结果和我们的不一致，开 issue，我们来查」。

至于不打算用它的开发者，这个仓库也值得一读：src/algo 下三种 kmeans 变体的工程实现、quant 下带 SIMD 三套内核的 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 story 与评论池，2026-10-14 上榜，评论按转述处理
• 「受 ScaNN/SPANN 启发」「pgvectorscale 前作与维护模式」：AGENTS.md 自述与官方博客
• 星数未取精确值，正文按「官方新发布/发布数日」口径处理