pgvector、Pinecone 与 Weaviate: 2026 年应该如何选?
一名 AI 架构师视角的 2026 年向量数据库选型指南: 先用 pgvector, 必要时再迁移。每种方案分别在什么情况下占优, 以及性能数字真正告诉你的是什么。
第 01 节 · 决策概览
为什么向量数据库选型对 RAG 很重要
向量数据库是你 RAG 流水线的检索层。它的性能、运维模型和规模化下的成本, 决定了你的 RAG 系统是否可靠、可维护、经济上可持续。
快速回答
简短答案: 如果你跑 Postgres, 就从 pgvector 开始 — 在大约 1,000 万向量以内是生产级的, 加进来几乎不用钱。规模超过它能托住的范围时用 Pinecone。需要原生混合检索或大规模自托管控制时用 Weaviate。
大多数工程师选向量数据库的方式, 是读那种把所有方案在所有维度上同时排序的对比文章。更有用的视角是迁移路径: 你应该从哪个起步, 什么信号触发迁移?
答案几乎总是先用 pgvector。它是 Postgres 扩展, 直接跑在你已有的数据库里。没有新基础设施、没有新运维负担、没有额外费用。你已有的备份、监控、访问控制都覆盖它。在 1,000 万向量以下 — 这覆盖了绝大多数种子轮到 A 轮场景 — 它的性能与专用向量库相比也具有竞争力。
第 02 节 · 方案一
pgvector: 没特别理由就从这里开始
pgvector 给 PostgreSQL 加上向量存储与 HNSW 索引支持。你把向量存在与现有数据并列的列里, 用 SQL 加上向量距离运算符做查询。整套栈 — 向量、元数据、关系数据 — 都在一个数据库里, 一个连接、一份备份、一套监控。
什么时候用 pgvector
你已经在跑 Postgres。数据集在 1,000 万向量以下。你想把基础设施复杂度压到最低。Supabase、Neon 和 RDS 原生支持 pgvector。包括 Instacart 在内的公司已在生产中以可观规模运行 pgvector。
什么时候迁出 pgvector
数据集超过 1,000 万到 5,000 万向量, 单节点 Postgres 已经出现明显延迟劣化。你需要原生混合检索而不希望手动用 BM25 索引拼装。或者你需要在大规模下做多租户向量隔离。
100 万向量规模下的性能: pgvector 配 HNSW 在 95% 召回率下大约 640 QPS。专用向量库在同等召回率下能跑到 1,600 QPS 以上。在 100 万向量这个量级, 这个差距很少决定成败 — 查询延迟很低, 吞吐通常也不是瓶颈。但到 5,000 万向量时, 差距就变得明显。
第 03 节 · 方案二
Pinecone: 通往 1 亿以上向量的托管路径
Pinecone 是一个全托管、无服务器的向量数据库。你创建索引、写入向量、查询 — 不需要配置或维护任何基础设施。它能透明扩展到数亿向量, 不需要做运维改造。SLA 与支持是三者中最强的。
什么时候用 Pinecone
你需要超出 pgvector 的实际上限, 同时希望以最快速度上生产, 而不想在基础设施运维上投入。从 pgvector 迁到 Pinecone 的团队反馈, 切换通常以小时为单位, 不是天 — API 表面足够直接。
什么时候考虑替代
成本是首要约束。Pinecone 无服务器价格在中等规模下具有竞争力, 但在大规模下会高于自托管方案。如果你能稳定运维基础设施, Qdrant 或 Weaviate 自托管在超大流量下每次查询的成本更低。
第 04 节 · 方案三
Weaviate: 原生混合检索与自托管控制
Weaviate 原生支持混合检索 — BM25 加向量相似度, 用 Reciprocal Rank Fusion 融合。你不需要在向量索引旁边再单独搭一个 BM25 索引。对需要混合检索的生产 RAG 系统而言 (绝大多数都需要), 这是显著的运维优势。
什么时候用 Weaviate
你需要原生混合检索, 不想自己拼装。出于数据主权、合规或成本考虑, 你想要自托管选项。你在构建多租户 RAG 系统, 向量空间需要按租户隔离。
什么时候考虑替代
你想要尽可能简单的托管服务, 而且不需要自托管。Weaviate 的托管云不错, 但 Pinecone 的 API 更简洁、SLA 也更强, 适合希望完全托管、不掺和运维的团队。
第 05 节 · 直接对比
生产中真正重要的数字
| 维度 | pgvector | Pinecone | Weaviate |
|---|---|---|---|
| 部署模型 | 自托管 (Postgres 扩展) | 全托管, 无服务器 | 自托管或托管云 |
| 混合检索 | 需手动 (与 BM25 索引拼装) | 支持 (2025 年加入) | 原生 — 开箱即用 |
| 100 万向量性能 | ~640 QPS, 95% 召回率 | ~1,600+ QPS, 95% 召回率 | ~1,600+ QPS, 95% 召回率 |
| 实际规模上限 | ~1,000 万到 5,000 万向量 (单节点) | 数亿 | 自托管: 取决于节点; 托管: 高 |
| 成本模型 | 免费 (Postgres 成本) | 按用量 (起步约 70 美元/月) | 自托管免费; 托管按定价 |
| 多租户支持 | schema 级隔离 | namespace 级 | class 级隔离 — 强 |
| 从 Postgres 迁移 | 已经在那里 | 几小时 | 几天 |
在 100 万向量规模下, 三者的质量差距很小 — 默认设置都能达到 95% 召回率。基于运维模型偏好和混合检索需求来选即可。到了 5,000 万向量, pgvector 需要细致调优, 可能也需要迁移; Pinecone 和 Weaviate 则不需要改动就能扛住。
第 06 节 · 常见问题
常见问题
新做一个 RAG 应用, 我应该选 pgvector 还是 Pinecone?
如果已经在跑 Postgres, 优先用 pgvector。在 1,000 万向量以下, 它已经是生产级别, 不需要额外费用, 数据可以集中管理。当突破 pgvector 上限时再迁移到 Pinecone, 迁移过程并不复杂, 而 Pinecone 的托管服务在大规模下能显著降低运维成本。
在 100 万向量规模下, pgvector 与 Pinecone 性能差多少?
在 100 万向量、95% 召回率下, pgvector 的 QPS 大约是 640, 像 Pinecone、Weaviate 这类专用向量库可以达到 1,600 QPS 以上。但对绝大多数生产 RAG 系统而言, 这一差距并不致命 — 两者的查询延迟都在可接受范围之内。
pgvector 支持混合检索吗?
原生不支持。pgvector 只负责向量相似度检索。要补关键字检索, 需要在 Postgres 中单独构建 BM25 或全文索引, 再手动合并结果。Weaviate 默认就提供混合检索, Pinecone 在 2025 年加入了该能力。
什么时候应该从 pgvector 迁移到 Pinecone 或 Weaviate?
数据集突破 1,000 万到 5,000 万向量、pgvector 出现明显延迟劣化时迁移; 需要原生混合检索而不希望自己拼装时迁移; 或者需要在大规模下做多租户向量隔离时迁移。还没遇到的规模, 不必提前迁移。
常见问题
- 新做一个 RAG 应用, 我应该选 pgvector 还是 Pinecone?
- 如果已经在跑 Postgres, 优先用 pgvector。在 1,000 万向量以下, 它已经是生产级别, 不需要额外费用, 数据可以集中管理。当突破 pgvector 上限时再迁移到 Pinecone, 迁移过程并不复杂, 而 Pinecone 的托管服务在大规模下能显著降低运维成本。
- 在 100 万向量规模下, pgvector 与 Pinecone 性能差多少?
- 在 100 万向量、95% 召回率下, pgvector 的 QPS 大约是 640, 像 Pinecone、Weaviate 这类专用向量库可以达到 1,600 QPS 以上。但对绝大多数生产 RAG 系统而言, 这一差距并不致命 — 两者的查询延迟都在可接受范围之内。
- pgvector 支持混合检索吗?
- 原生不支持。pgvector 只负责向量相似度检索。要补关键字检索, 需要在 Postgres 中单独构建 BM25 或全文索引, 再手动合并结果。Weaviate 默认就提供混合检索, Pinecone 在 2025 年加入了该能力。
- 什么时候应该从 pgvector 迁移到 Pinecone 或 Weaviate?
- 数据集突破 1,000 万到 5,000 万向量、pgvector 出现明显延迟劣化时迁移; 需要原生混合检索而不希望自己拼装时迁移; 或者需要在大规模下做多租户向量隔离时迁移。还没遇到的规模, 不必提前迁移。