向量数据库选型：pgvector、Qdrant、Pinecone 怎么选

向量数据库选型的核心不是性能最好，而是总拥有成本最低。100 万向量以下 pgvector 是默认选择，其价值在于和业务数据的事务一致性。

先说一个反直觉的结论

很多人在做 RAG 或语义搜索时，第一反应是「我需要一个向量数据库」。但在动手之前，请先看这个数字：

绝大多数应用，在向量数量少于 100 万条时，用 Postgres 加一个 pgvector 扩展就够了。

这句话的含义是：你可能根本不需要引入一个独立的向量数据库。而引入它的代价是——多一套需要运维、备份、监控、调优的系统，以及多一个可能出故障的环节。

所以这篇文章的顺序是：先讲怎么判断你到底需不需要，再讲如果真的需要，怎么选。

第一步：先算清楚你的规模

决策的核心变量只有一个：向量数量和查询并发。

规模	建议方案
< 10 万条	pgvector 或内存索引，完全够用
10 万 – 100 万条	pgvector（配合合适的索引），多数场景可撑住
100 万 – 1000 万条	开始考虑专用向量数据库
> 1000 万条	需要专用方案，且要认真做容量规划

怎么估算向量数量？公式很简单：

向量数 = 文档数 × 平均每文档分块数

举个例子。假设你有 5000 份文档，每份文档切成 30 个块，那就是 15 万个向量——这仍然在 pgvector 的舒适区。

但如果你的场景是「用户上传的每一张图片都要做向量检索」，且日活用户上万，那规模可能迅速突破千万。

先算这个数，再谈选型。 跳过这一步直接对比产品特性，是最常见的浪费。

第二步：理解真正的性能瓶颈

向量检索的性能，取决于三个因素：

因素一：索引类型

向量检索的精确算法是暴力计算（和每个向量都算一次距离），复杂度是 O(n)。这在百万级就不可接受了。

所以实际用的是近似最近邻（ANN） 算法。主流三类：

HNSW（分层可导航小世界图）：查询最快，召回率高，但内存占用大，构建慢
IVF（倒排文件）：内存友好，构建快，但召回率不如 HNSW
PQ（乘积量化）：压缩率高，能处理超大规模，但精度损失明显

实践中最常用的是 HNSW，因为它查询快、召回好。代价是内存。

因素二：内存

这是最容易被低估的成本。HNSW 索引通常需要把全部向量和索引结构放在内存里。

算一笔账：假设 100 万个向量，维度 1536，用 float32 存储：

1,000,000 × 1536 × 4 bytes ≈ 6.1 GB

这还只是原始向量，HNSW 的图结构还要额外开销。所以 100 万向量的 HNSW 索引，实际内存需求可能在 10 GB 以上。

这是选型时最实际的约束——很多时候不是性能不够，是内存买不起。

因素三：过滤条件

真实查询往往不是「找最相似的 10 个」，而是「在某个分类下找最相似的 10 个」。

这看起来是个小需求，但对性能影响巨大：

先过滤再检索：如果过滤后只剩 100 条，暴力算就够了，不用 ANN
先检索再过滤：如果过滤条件很苛刻，可能召回 100 条结果后发现过滤完只剩 2 条

过滤和检索的顺序，会显著影响结果质量和性能。 这是很多选型对比文章不会提的细节。

三个主流方案的差异

pgvector：被低估的选择

优势：

你的业务数据本来就在 Postgres 里，向量和元数据可以在同一个事务里操作
不需要额外运维一套系统
支持完整的 SQL 能力——JOIN、聚合、复杂过滤
事务保证一致性

劣势：

超大规模（千万级以上）性能下降明显
HNSW 索引构建和调优不如专用数据库成熟
水平扩展困难

关键优势是「事务一致性」。举个例子：如果你用独立的向量数据库，当你删除一份文档时，需要同时删除 Postgres 里的记录和向量库里的向量。这两步如果有一边失败，数据就不一致了。而用 pgvector，这在同一个事务里完成，天然一致。

这个优势在多数业务场景里被严重低估。

Qdrant：工程实现的平衡点

优势：

用 Rust 写的，性能好且资源占用合理
原生支持 payload 过滤，且过滤与检索结合得比较好
部署简单，单二进制或 Docker 即可
支持量化，能显著降低内存占用

劣势：

生态相对较新
复杂数据分析能力不如 SQL

适合：中大规模、需要独立向量服务、又不想引入过重运维负担的场景。可以在这里查看 Qdrant 的详细信息。

Pinecone：全托管的省心方案

优势：

完全托管，无需运维
弹性扩缩容
上手快，适合快速验证

劣势：

成本随规模线性增长，规模大了会很贵
数据在第三方，有合规顾虑
供应商锁定

适合：想快速验证想法、团队没有运维能力、或者数据量小但要求高可用的场景。详见 Pinecone 介绍。

选型决策树

把上面的分析整理成可以直接用的判断路径：

数据量 < 100 万？
├── 是 → 业务数据已在 Postgres？
│         ├── 是 → 用 pgvector（最省事，且天然事务一致）
│         └── 否 → 仍建议 pgvector（引入 Postgres 比引入向量库简单）
└── 否 → 需要独立向量服务
          ├── 团队能接受运维 → Qdrant（性价比高）
          └── 不想运维 → Pinecone（贵但省心）

注意我把 pgvector 放在了「默认选项」的位置。 原因不是它性能最好，而是它的总拥有成本最低——这包括开发成本、运维成本、和出问题时的排查成本。

除了向量数据库，还有一个选项

如果你的场景是「小规模 + 只读 + 可以全量加载」，还有一个被忽略的方案：在应用内存里做向量检索。

用 LlamaIndex 这类框架，它内置了内存向量索引。几万条向量直接放内存，查询是纯内存计算，延迟极低，且零运维。

限制是：

进程重启要重建（除非做持久化）
内存受限于单机
不适合频繁更新

对于原型验证和中小规模的固定知识库，这是最快的方案。

常见误区

误区一：追求极致召回率

很多人执着于把召回率从 92% 优化到 97%，但忽略了——后面还有重排序环节。

实际上，粗召回阶段稍微放宽（比如召回 50 条），再用重排序模型精排，效果往往比死磕召回率更好，而且成本更低。

别在召回率上做过度优化，给重排序留出空间。

误区二：忽略嵌入模型的成本

嵌入模型的选择往往被当成「顺便决定」的事，但实际上：

换嵌入模型 = 全量重建向量，这是不可逆的操作
有些模型按 token 计费，大规模文档的嵌入成本可能很高
不同模型维度不同，直接影响内存和存储

嵌入模型一旦上线，就当成数据库 schema 级别的决策来对待。

误区三：不做数据清理

向量数据库里的「删除」往往不是真删除（为了性能）。长期运行后，你会发现：

明明删了文档，检索还能查到
存储持续增长，但有效数据没增加

要定期做真空/压实操作，或者设计时就把「软删除 + 标记过滤」考虑进去。

误区四：只用向量检索

纯向量检索对精确匹配很弱。比如搜索产品型号「XR-2000」，向量检索可能返回一堆语义相似但型号不对的产品。

混合检索（向量 + 关键词）几乎是标配，除非你的数据完全是自然语言且没有专有名词。

一个务实的落地建议

如果你正要做技术选型，我的建议是这个顺序：

第一步：用 pgvector 起步。 不要纠结。它能撑到百万级，覆盖绝大多数场景。先把业务跑通。

第二步：埋点收集真实数据。 记录查询延迟、召回率、数据增长率、内存占用。这是未来选型的唯一依据。

第三步：等数据说话。 当 pgvector 真的成为瓶颈（而不是你猜它会成为瓶颈）时，再迁移。

迁移的代价是可接受的——向量数据可以重建，而且到那时你已经清楚知道自己的真实需求是什么。

最糟的做法是：一开始就为了「未来的规模」引入复杂的分布式向量数据库，结果运维成本吃掉了大部分开发时间，而业务量根本没到那个规模。

小结

向量数据库选型的核心不是「哪个性能最好」，而是「在你的规模下，总拥有成本最低」。

< 100 万向量：pgvector 是默认选择，它的价值在于和业务数据的事务一致性
中大规模：Qdrant 是工程上的平衡点
不想运维：Pinecone 省心但贵
原型/小规模只读：内存索引最快

最后强调一点：先算清楚你的向量数量。这一个数字，能帮你排除掉 80% 不必要的选型纠结。