2026 年 10 月 27 日，Pinecone 发布开源 PostgreSQL 扩展 pg_pinecone，采用 Apache 2.0 许可证，把其向量检索引擎接入应用已经存放在 pgvector 列中的向量数据，让 PostgreSQL 在不开辟独立向量数据库的情况下支持近似最近邻检索。发布文章由 Harshita Daddala 与 Anthony Mahanna 撰写。本文从后端架构与数据视角解读这次发布。
HNSW 在真实负载下的三个痛点
在 PostgreSQL 里做向量检索，常见做法是建 HNSW 图索引。Pinecone 认为这类索引有三个现实问题：为维持性能需要不断增加内存；构建时间长；在带过滤条件的查询上准确率会下降。更具体地说，当查询被限定到某个用户或某个租户时，图索引可能返回的行数少于查询的 LIMIT，应用不得不做迭代扫描来补足结果，既增加延迟，也可能在放宽顺序时牺牲准确率。对多租户 SaaS 与 RAG 系统，这不是边缘情况，而是常态。
三种引擎，一套 SQL
pg_pinecone 让每张表选择三种引擎之一。默认的原生引擎完全在 PostgreSQL 内构建与检索索引，不需要 Pinecone 账号、API key 或网络调用；pgvector 引擎复用已有的 HNSW 或 IVFFlat 索引，适合已有索引且不做过滤的表；远程引擎把检索发到 Pinecone 的托管无服务器索引，适合已经超出一台 PostgreSQL 服务器承载能力的表。应用连接方式不变，SQL 也不变，例如仍然使用 ORDER BY embedding <=> $1 LIMIT 10；表与完整向量留在原处，PostgreSQL 仍是系统记录源。切换引擎只需调用一次 pinecone.set_engine()，且可以随时切回。
原生引擎如何检索
原生引擎同样使用近似最近邻，但把图结构换成了倒排文件索引：先把相似向量聚成簇，每个向量存成量化的 RaBitQ 码，约每维一比特加上少量修正值，方法来自 Gao 与 Long 的 SIGMOD 2024 论文。同一簇的码被连续打包，检索时读少量连续页，而不是在图上跳转。一次检索分三步：用查询向量与各簇质心比较，探测最近的簇；用每行的 RaBitQ 码估算距离，保留最佳候选；再用表中的完整向量对候选重排。
过滤发生在检索内部。Pinecone 称 pgvector 的 HNSW 采用后过滤：先找最近邻，再应用 WHERE 条件，窄过滤会丢弃大部分候选，迭代扫描补列表既费时又可能降低准确率。原生引擎在构建时为每行存一个过滤列的值，并统计每个值的行数；当过滤条件命中行数不超过默认的 3% 时，它走预过滤，扫描所有匹配行并用完整向量打分，结果精确；过滤范围更宽时走单阶段过滤，最多搜索一半的最近簇，并在簇内先检查过滤条件再打分。新插入的向量加入最近的簇并立即可检索；由于质心不会随插入移动，官方建议在大批量变更后运行 REINDEX 或开启自动维护来重新平衡簇。
官方基准数据
Pinecone 在 100 万条 wiki_dpr 的 768 维向量上对比原生引擎与 pgvector HNSW，测试环境为 AWS r6id.4xlarge（16 vCPU、128GB 内存），无过滤延迟、构建时间与索引体积在 PostgreSQL 17 上测，过滤检索在 PostgreSQL 18 上测。官方报告原生索引 136MB，HNSW 在 halfvec 上为 2.0GB、全精度向量为 4.1GB；无过滤检索在 0.95 召回率下为 1.3ms，HNSW 分别为 1.7ms 与 2.7ms；在 0.99 召回率下为 2.3ms，HNSW 分别为 4.7ms 与 6.7ms。过滤命中 10% 行时，原生引擎以单阶段过滤达到 1.000 召回、12.3ms，HNSW 迭代扫描最好为 0.920 召回、5.9ms；过滤命中 1% 时，原生引擎为 0.981 召回、8.3ms。构建时间官方报告为 45 秒，HNSW 在 halfvec 与全精度下分别为 62 秒与 79 秒。
这些数字来自厂商自测，数据集、硬件与参数固定，不能直接外推到所有负载；但索引体积从 GB 级降到百 MB 级，以及窄过滤下召回率的差异，值得在选型时用自有数据复现。
安装与可选能力
pg_pinecone 要求 PostgreSQL 17 或 18、超级用户权限，并在服务器上安装 pgvector。它可以从 GitHub 的预编译发布安装，或使用 Docker Hub 上的 pineconeteam/pg_pinecone 镜像，该镜像按 PostgreSQL 主版本打标签，例如 0.11.0-pg17；使用远程引擎还需要通过 shared_preload_libraries 加载扩展。初始化会创建 vector 与 pg_pinecone 扩展，并通过 pinecone.create_index() 建索引；从源码构建需要 Rust 工具链与 cargo-pgrx 0.19.2。可选的 Pinecone API key 可启用远程引擎的背景下同步；embed() 可在 SQL 中调用 Pinecone 推理服务把文本转为向量，BM25 全文检索可与向量检索在同一张表上组合成混合查询，rerank() 可调用 Pinecone 的重排模型。
对数据架构的意义
对已经把业务数据放在 PostgreSQL 的团队，pg_pinecone 提供了一条“先留在数据库、再按规模迁移”的路径：小规模用原生引擎，已有 pgvector 索引时复用，超出一台服务器后再切远程引擎，而查询语句不变。这种引擎可切换的设计降低了向量检索的锁定风险，也让混合检索、嵌入生成与重排可以在 SQL 层组合。需要提醒的是，原生引擎目前在 PostgreSQL 17 与 18 上可用，且需要超级用户安装；在生产采用前，应评估扩展升级、备份恢复与高可用方案，而不仅是对比基准延迟。
小结
Pinecone 于 2026 年 10 月 27 日开源 PostgreSQL 扩展 pg_pinecone，以三种可切换引擎、原生索引 136MB、窄过滤下更高召回与 Apache 2.0 许可为看点，是后端架构与数据领域把向量数据库能力下沉到 PostgreSQL 的一次尝试。