Pinecone 发布开源 Postgres 搜索扩展 pg_pinecone

Pinecone 于 2026 年 10 月 27 日发布了 pg_pinecone。这是一款采用 Apache 2.0 许可证的开源 Postgres 扩展，可将该公司称其已大规模运行的向量搜索引擎引入应用中现有的 pgvector 列。根据该公司公布的基准测试结果，扩展的原生索引针对 100 万个 768 维向量仅占 136 MB，而 halfvec 上的 HNSW 索引占用 2.0 GB，全尺寸向量上的索引则占用 4.1 GB。

此次发布通过一篇由 Harshita Daddala 和 Anthony Mahanna 撰写的公告文章对外介绍。文章称，在 Postgres 中运行向量搜索的常见方式是使用 HNSW 等图索引。这类索引需要越来越多的内存才能维持性能，构建耗时较长，而且在带筛选条件的搜索中准确度会下降；当查询限定在某位用户或某个租户范围内时，图索引返回的行数可能少于查询中的 LIMIT 值。pg_pinecone 则会在搜索过程中应用筛选条件。Pinecone 表示，这样即使搜索范围较窄，也能返回完整数量的结果；在默认引擎中，数据也始终不会离开 Postgres。

一个索引，三种引擎

pg_pinecone 可与 pgvector 中已有的向量列配合使用。应用仍以相同方式连接 Postgres，并发送相同的 SQL，例如 ORDER BY embedding <=> $1 LIMIT 10；表（包括完整向量）也仍保留在原处，Postgres 继续作为记录系统。

每张表使用三种引擎之一。默认的原生引擎完全在 Postgres 内部构建并搜索索引，无需 Pinecone 账户、API 密钥或网络调用。pgvector 引擎会搜索现有的 pgvector 索引（HNSW 或 IVFFlat）；该项目的 GitHub 代码库称，这种引擎适用于已有 pgvector 索引且不使用筛选条件的表。远程引擎会将搜索请求发送到 Pinecone 托管服务中的无服务器索引，适用于规模已超出单台 Postgres 服务器承载能力的表。切换表所用的引擎只需调用一次 pinecone.set_engine()；查询无需更改，而且每次切换都可以撤销。

原生引擎如何搜索

与 pgvector 的 HNSW 类似，原生引擎使用近似最近邻算法，但它以倒排文件索引取代图结构，将相似向量归入不同簇。每个向量都存储为量化后的 RaBitQ 编码，每个维度约占 1 位，另加少量校正值。公告称，该方法由 Gao 和 Long 在 SIGMOD 2024 上提出。每个簇的编码会集中打包，因此搜索时只需读取少量连续的数据页，无需在图结构中跳转。

搜索分三步进行：先将查询向量与各簇的质心进行比较，探测最近的簇；再根据每行的 RaBitQ 编码计算估算距离，并保留最优候选项；最后从表中读取这些候选项的完整向量并重新排序。

筛选在搜索过程中完成。Pinecone 表示，pgvector 的 HNSW 会在搜索后应用筛选：先查找最近邻，再应用 WHERE 子句。因此，筛选范围较窄时，大多数候选项都会被丢弃，迭代扫描则会补足结果列表，但要付出时间成本；使用 relaxed_order 时，还会影响准确度。原生引擎会将每行的筛选列值与该行的编码一同存储，并在构建时统计每个值对应的行数。对于较窄的筛选范围（默认情况下为 3% 或更少的行），引擎会预先筛选：扫描所有簇中符合条件的每一行，并使用其完整向量计算得分，因此结果是精确的。对于范围较宽的筛选，引擎则采用单阶段筛选：搜索最近簇中最多一半的簇，并在每个簇内先检查筛选条件，再计算得分。

新插入的数据会加入最近的簇，并可立即用于搜索。由于质心的位置在构建索引时便已确定，公告建议在发生大规模变更后运行 REINDEX 或启用自动维护，以便重新平衡各簇；例如，批量加载导致表的大小翻倍时，就应执行这类操作。

Pinecone 公布的基准测试结果

Pinecone 使用 100 万个 768 维 wiki_dpr 向量，将原生引擎与 pgvector 的 HNSW 索引进行比较，测试对象包括全尺寸向量和 halfvec。测试在一台配备 16 个 vCPU 和 128 GB RAM 的 AWS r6id.4xlarge 实例上进行：无筛选条件下的延迟、构建时间和索引大小在 PostgreSQL 17 上通过一次测试测量；带筛选条件的搜索在 PostgreSQL 18 上通过另一次测试测量；内存受限配置则在第三次测试中测量。延迟数据采用单个客户端、k=10 时的中位数 p50。该公司表示，完整的测试设置以及重新运行测试所需的命令，均收录在代码库中的基准测试工具 README 文件里。

针对 100 万个向量，Pinecone 报告称，原生索引占用 136 MB，而 halfvec 上的 HNSW 索引占用 2.0 GB，全尺寸向量上的索引占用 4.1 GB。在无筛选条件的搜索中，该公司报告称，原生引擎在召回率为 0.95 时延迟为 1.3 毫秒；halfvec 上的 HNSW 为 1.7 毫秒，全尺寸向量上则为 2.7 毫秒。召回率为 0.99 时，原生引擎的延迟为 2.3 毫秒，而 HNSW 分别为 4.7 毫秒和 6.7 毫秒。筛选条件匹配 10% 的行时，Pinecone 报告称，原生引擎采用单阶段筛选，在 12.3 毫秒内达到 1.000 的召回率；采用迭代扫描的 HNSW 最多达到 0.920 的召回率，耗时 5.9 毫秒。筛选条件匹配 1% 的行时，该公司报告的召回率为 0.981，耗时 8.3 毫秒。原生引擎的构建时间据报为 45 秒；halfvec 上的 HNSW 为 62 秒，全尺寸向量上则为 79 秒。

可用情况与 Pinecone 可选功能

pg_pinecone 要求使用 PostgreSQL 17 或 18，具备超级用户权限，并在服务器上安装 pgvector。它可以通过 GitHub 上的预编译版本安装，也可以通过 Docker Hub 上的 pineconeteam/pg_pinecone 镜像安装。README 将该镜像描述为在 pgvector/pgvector 镜像中加入了 pg_pinecone，并按 PostgreSQL 主版本分别发布标签，例如 0.11.0-pg17；运行远程引擎还需要通过 shared_preload_libraries 加载扩展。设置过程会创建 vector 和 pg_pinecone 扩展，并通过调用 pinecone.create_index() 建立索引。该项目也可以使用 Rust 工具链和 cargo-pgrx 0.19.2 从源代码构建。

配置可选的 Pinecone API 密钥后，远程引擎会在后台将嵌入向量同步到 Pinecone 索引；在副本完成之前，搜索仍会在 PostgreSQL 中继续运行。文章还介绍了另外三项可选功能：embed() 会调用 Pinecone 的推理服务，从 SQL 中将文本转换为嵌入向量；该功能同时适用于原生引擎和远程引擎，首次构建时可使用 Pinecone 免费套餐；BM25 全文搜索可与向量搜索在同一张表上并行运行，并可通过 SQL 发起 BM25、向量或混合查询；rerank() 则使用 Pinecone 的重排模型重新排列排名靠前的结果。

docs.pinecone.io 上的文档涵盖安装、存储引擎、引擎切换和全文搜索；代码仓库还提供 SQL 参考、运维手册和灾难恢复指南。Pinecone 将此称为该项目的首个版本，并表示由其维护 pg_pinecone、审查每个拉取请求；Pinecone 还表示，将根据通过 GitHub 问题、Discord 社区和每月办公时间收集的反馈，制定公开路线图。