第二期：PostgreSQL向量检索深度剖析——从pgvector到VectorChord

当向量检索从“能用”走向“好用”，PG生态如何重塑AI应用的数据底座

在第一期中，我们提到PostgreSQL正在经历一场从关系型数据库到综合性数据平台的深刻转型。而这场转型最核心的驱动力之一，正是向量检索能力的爆发。2026年，PostgreSQL在向量检索赛道上已完成从“追赶到引领”的角色转换。根据DB-Engines 2025年11月的数据，PostgreSQL在向量数据库细分赛道中已直接冲进前三——与专业向量数据库同台竞技。这背后，是PG社区与生态力量合力完成的一场关于效率、成本和架构的全面进化。

一、pgvector：从奠基者到持续进化的“事实标准”

1.1 为何pgvector成为AI工作流的中心？

pgvector之所以能在短短几年内成为AI应用开发的事实标准，核心原因在于它让向量检索与关系型数据库的能力实现了“无缝对接”。开发者可以在一个PostgreSQL实例中同时处理以下需求：

存储文本的embedding向量，并在其上构建相似度搜索；
关联用户ID、商品类别、状态等元数据进行复杂过滤；
利用ACID事务保证数据一致性；
借助Point-in-Time Recovery（PITR，即时间点恢复）、流复制等高可用特性保障生产稳定。

对大多数企业级AI应用而言，这些能力远比纯粹的向量检索性能更重要。

1.2 索引体系：IVFFlat与HNSW的选择之道

pgvector提供两类核心近似最近邻（ANN）索引，分别对应不同的使用场景：

IVFFlat（倒排文件索引）：将向量空间划分为多个聚类（lists）。查询时只搜索与目标向量最近的若干聚类，而非全表扫描。构建速度快，内存占用低，适合数据频繁更新的场景。
HNSW（分层导航小世界）：构建多层图结构，查询时从顶层向下贪婪搜索。检索精度更高，但构建时间显著更长，内存消耗更大。

两者之间不存在“绝对优胜”，真正有意义的权衡在于：你的数据更新频率有多高、可接受的内存预算有多少、以及业务要求的召回率和延迟标准是什么。

1.3 pgvector 0.8.0：从“基础可用”到“生产级可用”

2025年的pgvector 0.8.0版本是一次重要的跨越式升级：

性能飞跃：相较0.7.4版本，特定查询模式的性能提升高达5.7倍，在Amazon Aurora PostgreSQL上甚至实现了9倍查询加速和100倍搜索结果相关性提升；
迭代扫描（iterative_scan）：解决了困扰多时的“过过滤”（overfiltering）问题——即结合向量搜索与SQL过滤时，结果被过度裁剪甚至返回空集的场景；
成本估算优化：优化器能够更智能地选择执行路径，如在复杂过滤场景下优先使用B-tree而非HNSW。

1.4 安全与运维：pgvector 0.8.2的关键补丁

2026年2月，pgvector 0.8.2发布，修复了并行HNSW索引构建中的缓冲区溢出漏洞（CVE-2026-3172），恶意用户可通过该漏洞泄露敏感数据或导致数据库崩溃。这一事件提醒我们，向量检索扩展的成熟度不仅体现在性能上，更体现在安全响应和运维稳健性上。

二、VectorChord：磁盘优先架构如何改变游戏规则

如果说pgvector是向量检索在PG生态中的奠基者，那么VectorChord正在扮演“破局者”的角色。作为pgvecto.rs的继任者，它由同一团队开发，目标只有一个：让PostgreSQL的向量检索真正能上到十亿级规模。

2.1 为什么需要VectorChord？

pgvector的HNSW索引尽管性能出色，但在PostgreSQL的内核架构中面临一个根本性矛盾。HNSW要求索引常驻内存才能保证高性能，而PostgreSQL的表/索引模型、MVCC、VACUUM等机制与HNSW的图结构之间存在天然的不匹配：

插入成本高昂：插入单个向量可能触发多层、多节点的级联调整；
删除处理复杂：删除节点后需重新插入所有邻居以保持图的连通性，维护成本极高。

当数据规模达到千万甚至亿级时，这套架构的运维成本会急剧膨胀。

2.2 技术突破：IVF + RaBitQ组合方案

VectorChord的核心方案是IVF + RaBitQ量化技术：

IVF聚类：向量被路由到粗粒度聚类中，查询时只在相关聚类中搜索；
RaBitQ量化：在每个聚类内存储压缩后的量化码而非原始高维浮点数，查询时主要在压缩码上执行查表和整数运算。

这一设计带来的收益是质变性的——索引主体存储在磁盘而非内存中，使十亿级向量检索成为可能。

2.3 令人瞩目的性能指标

索引构建：在16 vCPU机器上，1亿向量索引构建时间不足20分钟；同等规模下，pgvector HNSW需要超过50小时；
存储成本：每1美元可存储40万向量——相同成本下，存储量是Pinecone优化存储的6倍，是pgvector的26倍；
查询能力：仅需32GB内存即可查询1亿个768维向量，P50延迟低至35ms，top10召回率高达95%；
高维支持：向量维度上限高达60,000，可轻松适配text-embedding-3-large等高维模型。

2.4 与pgvector的生态兼容

值得注意的是，VectorChord并非pgvector的替代品，而是补充者。它完全兼容pgvector的数据类型和语法，开发者可以在不修改应用代码的前提下引入VectorChord索引以获得性能提升。在实际部署中，两者可以并存于同一数据库，由开发者在不同场景中选择最合适的索引策略。

三、生态融合：向量检索与全文搜索的“双向奔赴”

单一模态的检索在真实场景中往往力不从心。2026年，PG生态中最值得关注的趋势之一是向量检索与全文搜索的深度融合。

3.1 ParadeDB：PostgreSQL原生替代Elasticsearch

ParadeDB是一个基于PostgreSQL的现代Elasticsearch替代方案，其口号是“Postgres for Search & Analytics”。它通过pg_search扩展带来了BM25全文搜索、密集与稀疏向量搜索以及分面搜索能力。在ParadeDB的实践中，BM25的词汇精准度与pgvector的语义理解能力形成了完美互补。

3.2 混合搜索（Hybrid Search）策略

混合搜索的核心问题是如何融合两类不同维度的相关性得分。行业公认的最佳实践是RRF（Reciprocal Rank Fusion，倒数排名融合）：综合计算BM25的词汇排名和向量相似度的语义排名，生成融合后的最终结果。VectorChord Suite更进一步，在同一发行版中内置了vchord（IVF+RaBitQ向量索引）、pg_tokenizer（文本分词）和vchord_bm25（BM25检索），提供一体化的混合搜索体验。

3.3 全文搜索的演变：从tsvector到BM25

PostgreSQL原生的全文搜索基于tsvector/tsquery，其排名函数ts_rank仅考虑文档本身的词频，缺乏对全局语料统计的理解——无法区分高频通用词与低频关键字的权重差异。BM25通过词频（TF）、逆文档频率（IDF）和文档长度归一化三者融合解决了这一问题，成为现代搜索引擎的事实标准。pg_search扩展将BM25能力直接带入PostgreSQL内核。