pg_vectorsearch 发布，PostgreSQL 向量索引迎来新选手

**Timescale 近日公开了 pg_vectorsearch，一个面向 PostgreSQL 的新向量搜索索引项目，并直接把比较对象锁定为 pgvector 的 IVFFlat 与 HNSW。**项目给出的核心主张很明确：在 PostgreSQL 内完成近似最近邻搜索时，pg_vectorsearch 可以取得比 pgvector 两种主流索引更好的性能。

截至 2026 年 10 月 14 日，pg_vectorsearch 已通过 Timescale 的 GitHub 仓库公开。它的出现并不意味着 pgvector 已经过时，而是说明 PostgreSQL 内部的向量检索竞争，正在从“有没有索引”进入“同等召回率下谁更快、谁更省资源、谁更容易运维”的阶段。

pg_vectorsearch 是什么

**pg_vectorsearch 是一个为 PostgreSQL 提供近似最近邻检索能力的向量索引项目。**近似最近邻搜索，也就是 ANN，是通过牺牲极少量结果精度，避免逐行计算全部向量距离，从而把百万乃至更大规模数据集的查询延迟压缩到在线应用可以接受的范围。

**pgvector 是当前 PostgreSQL 生态中事实上的主流向量扩展。**它不仅提供 vector、halfvec 和 sparsevec 等数据类型，也提供精确搜索、IVFFlat 与 HNSW 索引，因此大量 RAG、语义搜索、推荐系统和图像检索项目已经围绕它建立了数据模型与查询逻辑。

**pg_vectorsearch 的价值不在于再次证明 PostgreSQL 可以存向量，而在于尝试替换最昂贵的索引执行环节。**对开发者来说，真正关键的问题不是扩展名称，而是它能否继续保留 PostgreSQL 的事务、SQL、JSONB、权限和备份体系，同时让向量查询获得更高吞吐量。

这也是 pg_vectorsearch 最值得注意的地方：它没有另起一套独立向量数据库，而是继续押注 PostgreSQL 作为统一数据底座。应用可以把文档正文、租户编号、更新时间、权限标签和 embedding 放在同一数据库内，再组合关系过滤与向量排序，减少跨系统同步带来的延迟和一致性问题。

它挑战的是两条成熟路线

**IVFFlat 是一种先对向量空间进行聚类、查询时只扫描部分聚类分区的 ANN 索引。**它的优势是结构相对简单、构建速度快、空间成本可控；弱点是结果质量高度依赖训练数据、lists 数量与查询时的 probes 参数，数据分布发生变化后也可能需要重新评估索引。

**HNSW 是一种用多层近邻图缩小搜索范围的 ANN 索引。**它通常能在高召回率下提供较低延迟，不要求像 IVFFlat 那样预先完成聚类训练，但代价是构建更慢、索引更大、内存需求更高，持续写入时也需要承担图结构维护成本。

**召回率是 ANN 索引返回的真实近邻结果占精确搜索结果的比例。**例如，精确搜索得到的前 10 个结果中，ANN 找回了 9 个，那么 Recall@10 就是 90%。任何只谈 QPS、不谈 Recall@10 或 Recall@100 的“更快”，都缺少可比性。

三种方案的定位可以先概括如下：

| 对比项 | pg_vectorsearch | pgvector IVFFlat | pgvector HNSW | |---|---|---|---| | 产品定位 | 新的 PostgreSQL ANN 索引 | 聚类加倒排分区索引 | 多层近邻图索引 | | 主要目标 | 在相近召回率下进一步降低延迟、提高吞吐 | 快速构建、控制索引体积 | 追求高召回率和低查询延迟 | | 构建特征 | 需按项目版本与基准测试验证 | 通常构建较快，需要已有数据完成聚类 | 通常构建较慢，参数越激进成本越高 | | 查询调优 | 以项目公开参数和版本为准 | 主要调节 lists、ivfflat.probes | 主要调节 m、ef_construction、hnsw.ef_search | | 数据更新 | 需要重点验证写入放大和索引维护成本 | 增量成本相对容易控制，但数据漂移会影响聚类质量 | 支持增量插入，但图维护和内存开销更高 | | 过滤查询 | 需要在真实 SQL 条件下验证 | 可能因先检索后过滤而返回不足 | 可借助迭代扫描缓解过度过滤 | | 成熟度 | 新项目，生产案例仍需积累 | 成熟、部署广泛 | 成熟、部署广泛 | | 软件与部署成本 | 仓库公开，实际成本取决于许可证、硬件和运维 | 扩展本身开源，基础设施成本自担 | 扩展本身开源，通常需要更多内存 |

“更快”必须放进同一条召回率曲线里看

**pg_vectorsearch 的性能主张不能只用一个最快延迟数字来判断。**向量索引的标准比较方式，是在相同数据集、相同距离函数、相同 Top-K 和相同召回率下，观察 P50、P95、P99 延迟以及每秒查询数，而不是拿低召回配置去对比高召回配置。

一个索引可以通过少扫描数据获得极低延迟，但如果 Recall@10 从 95% 降到 70%，它对严肃的 RAG 系统未必更有用。检索阶段漏掉关键文档后，再强的语言模型也无法从不存在于上下文中的资料生成可靠答案。

**基准测试是否把索引完整放入内存，会直接改变性能结论。**当索引和向量数据都位于操作系统页缓存中时，CPU 距离计算、图遍历和内存访问局部性更重要；当数据规模超过内存后，随机磁盘读取次数、页面布局和预取策略才会成为主要瓶颈。

AWS 此前在 Aurora PostgreSQL 与 pgvector 上的测试已经说明环境差异有多大：在特定 BIGANN-1B 工作负载中，使用优化型读取的 HNSW 相比 IVFFlat，每秒查询数最高可提高 20 倍；与未使用优化型读取的同类实例相比，吞吐量最高提高 9 倍，每次查询成本下降 75% 至 80%。这些数字不能直接用于证明 pg_vectorsearch 的优势，却说明存储路径和缓存条件足以重写排名。

**本文不会把仓库中的“faster”扩写成一个脱离上下文的固定倍数。**pg_vectorsearch 的具体性能数字应以对应 commit 的 benchmark 脚本、硬件配置、数据集、向量维度和召回率曲线为准，因为项目迭代、编译选项与 PostgreSQL 配置都会影响结果。

开发者复测时至少要固定以下条件：

• 数据集规模、向量维度与向量分布必须相同；
• 距离度量必须一致，例如余弦距离、L2 距离或内积不能混用；
• Top-K、并发数、预热方式和缓存状态必须一致；
• 必须同时公布 Recall@10 或 Recall@100，而不是只公布平均延迟；
• 必须观察 P95、P99，而不是只看容易被少量快请求美化的 P50；
• 必须记录索引构建时间、索引体积、峰值内存和 WAL 生成量；
• 必须加入租户、时间、权限等过滤条件，而不是只跑无过滤的纯向量查询；
• 必须测试插入、删除和更新后的性能，而不是只测试一次性导入的静态数据。

真正难点是 PostgreSQL 的混合查询

**向量数据库进入生产后，过滤能力往往比裸 ANN 跑分更重要。**现实中的查询通常不是“从全部数据里找最相似的 10 条”，而是“从某个租户、某段时间、用户有权限查看且语言为中文的数据里找最相似的 10 条”。

这种查询会同时涉及 B-tree、JSONB、时间范围、行级安全策略和 ANN 索引。假设向量索引先找到 100 条候选记录，但其中 95 条因租户或权限条件被排除，最终就可能只返回 5 条，而不是应用要求的 10 条。

**过度过滤是 PostgreSQL 向量检索中最容易被实验室跑分忽略的问题。**pgvector 0.8.0 已经为 HNSW 和 IVFFlat 加入迭代索引扫描，可以通过 hnsw.iterative_scan 与 ivfflat.iterative_scan 在首轮候选不足时继续搜索，并分别使用 hnsw.max_scan_tuples 和 ivfflat.max_probes 控制额外工作量。

这意味着 pg_vectorsearch 不只要证明自身的裸查询速度，还要回答三个更实际的问题：过滤后是否能稳定返回足够的 Top-K 结果，PostgreSQL 查询规划器是否能正确估算成本，以及继续扩大搜索范围时延迟是否平滑增长。

**查询规划器兼容性会决定一个索引在复杂 SQL 中是否真的被使用。**即使索引本身很快，只要成本估算不准确，PostgreSQL 仍可能选择顺序扫描、B-tree 过滤后排序，或者采用开发者意料之外的执行计划。新索引因此需要的不只是算法，还包括选择率估算、并行执行、统计信息和 EXPLAIN 可观测性。

对 RAG 应用意味着什么

**RAG 是先从外部知识库检索相关内容，再把结果交给生成模型回答问题的应用架构。**在这条链路中，向量检索通常只是端到端延迟的一部分，但它决定了系统能否在扩大知识库后继续保持稳定响应。

对一个在线 RAG 服务来说，如果数据库检索从 40 毫秒降到 10 毫秒，单次请求只节省了 30 毫秒，看起来不如模型推理优化醒目；但在高并发环境下，更短的数据库占用时间意味着连接可以更快释放，同一实例能够支撑更多请求，尾延迟也更容易控制。

**索引内存占用也可能比单次延迟更影响总体成本。**HNSW 依靠图结构换取检索速度，当数据达到数千万条并使用 768、1024 或 1536 维 embedding 时，原始向量、图边、PostgreSQL 页面和缓存会共同消耗大量内存。一个稍慢但能减少随机访问、降低索引体积的方案，实际部署成本可能反而更低。

pg_vectorsearch 如果能在相同 Recall@10 下同时减少 CPU 周期、缓存失效和索引体积，它对 PostgreSQL 用户就不只是一个跑分更高的选项，而可能改变实例规格选择。反过来，如果优势只出现在数据完全驻留内存、无过滤、只读且单并发的条件下，它更适合作为技术预览，而不是立即替换生产索引。

pgvector 不会因此被轻易取代

**pgvector 的最大护城河是成熟生态，而不是某一次基准测试中的最快数字。**它已经被多家云数据库集成，拥有稳定的数据类型、操作符、索引方法和迁移经验，开发者也更容易找到参数调优、故障排查与容量规划资料。

pgvector 的 IVFFlat 与 HNSW 还覆盖了两种差异明显的需求。IVFFlat 适合重视构建速度、索引空间和批量更新的场景；HNSW 适合对召回率与在线查询延迟要求更高、并且愿意投入更多内存的场景。新索引必须在这两者之外提供足够明确的收益，才能说服团队承担迁移和运维成本。

**索引替换也不是执行一次建索引语句那么简单。**生产团队还需要验证逻辑备份与物理备份、流复制、崩溃恢复、主从切换、版本升级、扩展升级、批量删除、VACUUM、WAL 体积和只读副本查询等行为。

对于写入频繁的系统，还要观察索引在持续更新数周后的状态。部分 ANN 结构在静态数据集上表现很好，但删除产生的空洞、数据分布漂移和反复更新可能逐渐降低搜索质量，最终需要重建索引，而重建时间本身就是生产成本。

现在是否值得使用

**pg_vectorsearch 已经值得做独立压测，但还不适合仅凭项目标题直接替换现有生产索引。**最稳妥的方式，是从真实业务数据中抽取一份脱敏副本，把 pg_vectorsearch、IVFFlat、HNSW 和精确搜索放在相同 PostgreSQL 版本与硬件上比较。

可以按以下场景做选择：

1. **已有 pgvector 且性能满足要求：**没有必要为了追逐跑分立即迁移，先关注 pg_vectorsearch 的版本稳定性和兼容性。
2. **HNSW 内存压力明显：**重点测试 pg_vectorsearch 的索引体积、缓存命中率与超内存数据集表现。
3. **IVFFlat 召回率不稳定：**应在相同 Recall@10 下比较延迟，而不是沿用默认 probes 参数。
4. **多租户和权限过滤较重：**必须加入真实过滤条件，并检查返回条数、执行计划和 P99 延迟。
5. **数据更新频繁：**需要同时压测写入吞吐、索引维护成本、WAL 和更新后的召回率。
6. **面向核心生产业务：**应等待更充分的版本、恢复、复制和升级验证，同时保留回退到 pgvector 的路径。

判断：有竞争力，但胜负不只在 ANN 算法

**pg_vectorsearch 最重要的意义，是把 PostgreSQL 向量索引的评价标准继续向前推进。**过去开发者讨论的是 PostgreSQL 能不能做向量搜索，现在讨论的已经是相同召回率下的 P99 延迟、索引体积、过滤效果、写入成本和磁盘工作集。

Timescale 选择直接挑战 pgvector 的 IVFFlat 与 HNSW，说明 PostgreSQL 原生生态仍然有相当大的优化空间。对不愿维护独立向量数据库的团队来说，这类项目越多，统一保存业务数据与 embedding 的路线就越有吸引力。

**现阶段更合理的结论是：pg_vectorsearch 是一个值得进入技术选型清单的新索引，而不是已经无条件胜出的 pgvector 替代品。**它能否成为新的默认选择，要看公开基准能否被独立复现，更要看它在过滤、并发写入、数据超过内存以及 PostgreSQL 高可用环境中的长期表现。

参考来源

• Timescale / pg_vectorsearch：项目官方仓库，包含源码、安装说明、基准测试与后续版本更新。
• pgvector / pgvector：pgvector 官方仓库，可查阅 IVFFlat、HNSW、距离操作符和迭代扫描参数。