Pg_vectorsearch：比pgvector的IVFFlat和HNSW更快的索引

pgvector的性能瓶颈与新的替代方案

在PostgreSQL生态中，pgvector已经成为向量检索的事实标准。它提供了IVFFlat和HNSW两种索引类型，分别面向不同的召回率与速度权衡场景。但随着向量数据规模从百万级迈向亿级，不少团队开始遇到查询延迟陡增、索引构建时间过长的问题。

近期在Hacker News上引发讨论的 Pg_vectorsearch 项目，正是针对这一痛点提出的新索引实现。根据项目作者的描述，其核心目标是在保持可接受召回率的前提下，将查询速度提升到明显优于pgvector现有索引的水平。

Pg_vectorsearch项目在Hacker News上的讨论

为什么pgvector的索引会成为瓶颈

IVFFlat的局限性

IVFFlat通过聚类将向量划分到多个桶中，查询时只扫描距离查询向量最近的若干个桶。这种做法在数据分布均匀时表现尚可，但一旦数据分布倾斜，或者聚类数量设置不当，就会出现"扫描桶数不够导致召回率崩塌、扫描桶数太多导致速度退化"的两难。

IVFFlat 中的关键参数：使用 IVFFlat 时需要设置 lists（聚类桶数量）和查询时的 probes（实际扫描桶数）两个参数。经验法则上 lists 常取 rows / 1000（行数不超过百万时）或 sqrt(rows)，probes 则需在召回率与延迟之间权衡，通常从 sqrt(lists) 起步调优。召回率对 probes 极为敏感，因为当查询向量落在某个聚类的边缘时，真正最近的邻居可能分布在相邻的桶中——这正是原文所说"扫描桶数不够导致召回率崩塌"的根源。

HNSW 的关键参数：m 控制每个节点在图中保留的邻居数（默认 16），ef_construction 决定构建时的候选队列大小（默认 64），查询时的 ef_search 则控制搜索广度。增大 m 和 ef_construction 能提升召回率，但会显著增加构建时间和内存占用，因为图结构需要在内存中存储所有节点及其邻接表。

HNSW的代价

HNSW采用多层图结构，查询时从稀疏的上层图逐步下降到稠密的下层图，通常能提供最佳的召回率-延迟曲线。代价在于内存占用高、构建时间长，并且在频繁更新的工作负载下维护成本显著。对于写入密集型的应用，HNSW往往不是理想选择。

Pg_vectorsearch试图在这两者之间找到一个新的平衡点。

Pg_vectorsearch的核心思路

从公开信息来看，Pg_vectorsearch并没有沿用IVF或HNSW的经典路线，而是设计了一种新的索引结构，重点优化了以下几个维度：

查询延迟：在相同召回率水平下，减少每次查询需要访问的向量数量
索引构建速度：降低构建阶段的计算开销，使大规模数据集能够更快完成索引
内存效率：在保证性能的同时控制常驻内存占用

这些目标如果能够同时达成，对于那些既要低延迟查询、又需要频繁重建索引的场景（比如推荐系统的实时特征更新），会带来实际价值。

与pgvector索引的对比

根据项目方给出的基准测试数据，Pg_vectorsearch在查询吞吐上超越了pgvector的IVFFlat和HNSW。需要注意的是，这类基准测试的结果高度依赖于数据集特征、向量维度、召回率目标和硬件配置。

在实际选型时，建议关注以下几点：

召回率-延迟曲线：不只看单一延迟数字，要看在目标召回率下的延迟表现
构建时间与资源消耗：对于需要频繁重建索引的场景，构建成本可能比查询成本更关键
更新友好性：插入、删除、更新操作对索引性能的影响
生态兼容性：是否兼容现有的pgvector SQL接口，迁移成本有多高

评估向量索引的核心指标：

召回率（Recall@k）：查询返回的 k 个结果中，与暴力搜索（ground truth）结果重合的比例。它衡量的是"漏掉了多少真正的近邻"。
P99 延迟：99% 的查询能在该延迟内完成，比平均延迟更能反映用户实际感受到的"慢查询"，尤其在推荐、搜索等对长尾延迟敏感的场景。
QPS（吞吐）：每秒查询数，用于评估单位硬件资源下的服务能力。
索引构建时间与内存：决定了索引能否在夜间窗口内重建，以及单机能承载多大的数据集。

基准测试的公平性还取决于是否固定召回率目标（如都在 Recall@10=0.95 下对比延迟），否则单纯比较 QPS 数字容易产生误导。

对向量数据库格局的影响

向量检索领域目前呈现出明显的分化：专用向量数据库（如Milvus、Qdrant、Weaviate）在极致性能上发力，而PostgreSQL+pgvector则凭借"在一个数据库里搞定关系数据和向量数据"的便利性占据大量中小规模场景。

Pg_vectorsearch这类项目的出现，说明PostgreSQL生态内部的竞争也在加剧。如果新索引能够兑现性能承诺，同时保持与pgvector的接口兼容，那么对于已经在用PostgreSQL的团队来说，升级路径会非常平滑——不需要迁移数据，不需要重写查询，只需要换一个索引类型。

当然，新项目在成熟度、社区支持、边界情况处理上通常需要时间验证。是否采用，取决于团队对稳定性和性能的权衡。

专用向量数据库与 pgvector 的差异定位：Milvus、Qdrant、Weaviate 等专用系统通常针对分布式扩展、异构索引类型（如 DiskANN、ScaNN）和 GPU 加速做了深度优化，适合十亿级以上、独立部署的检索服务。pgvector 的优势在于"关系数据 + 向量数据"同库事务一致性——不需要在业务库和向量库之间做数据同步，简化了架构与运维。Pg_vectorsearch 这类插件级方案的价值就在于：它把性能优化留在了 Postgres 内部，而不是要求用户为了性能把向量搬出去。这种"Postgres 内部的索引竞争"实际上在缩小专用数据库与通用数据库之间的性能差距。

实践建议

如果你正在使用pgvector并遇到性能瓶颈，可以按以下步骤评估Pg_vectorsearch：

在自己的数据集上复现基准测试，而不是直接采信项目方的数字
对比在目标召回率（如95%）下的P99延迟，而非平均延迟
测试索引构建时间和所需内存
评估在真实写入负载下的表现

对于向量规模在千万级以下、且对延迟不敏感的应用，pgvector现有的索引可能已经足够，没有必要引入新的依赖。但对于规模更大、延迟要求更苛刻的场景，Pg_vectorsearch值得关注。