向量数据库怎么选：pgvector与Milvus对比

核心摘要

• 选错向量数据库，等于给AI项目埋下一颗定时炸弹：我在50多个产品和十多个行业的落地过程中看到，很多项目“能做出来”却在用起来后卡死，80%以上与向量数据库选型不当直接相关。
• pgvector适合“轻量起步、集成简单”的需求；Milvus适合“处理千万级向量、高并发”的场景——两者各有明确边界，没有“绝对更好的”。
• 多数企业一开始都不需要分布式向量数据库：据麦肯锡2025年AI应用现状调研，约88%的企业虽在使用AI，但多数仍停留在探索阶段、未规模化见效——这意味着他们根本用不上Milvus的扩展能力，但高性能往往是最大的诱惑和幻觉。
• 先想清楚三件事再选：①你的数据量会涨到多大？②你的检索需要多快？③你这个功能是“核心功能”还是“辅助功能”？
• 最怕的不是技术选型，而是“为了用新技术而用新技术”：我见过太多企业一上来就上Milvus，结果团队花三个月调优、最后发现业务只需要几百条向量做模糊搜索——选pgvector五十行代码就解决了。

---

一、引言

去年一个客户找到我，他们上了一个AI客服系统，底层用Milvus做意图匹配和知识检索。系统花了两个月调通，测下来响应时间不错。但是业务量上来之后，运维成本暴涨——他们公司就一个兼职后端，根本扛不住Milvus的部署和维护复杂度。最后改成了pgvector，开发成本降了八成，应用效果完全能接受。

这类的案例，我在带客户时会一再遇到。很多做AI落地的老板或技术负责人，面临一个问题：为什么AI项目做出来了，却始终没人愿意用？ 据MIT《State of AI in Business 2025》，约95%的企业生成式AI试点未能带来可衡量的回报。Gartner也预测，至少30%的生成式AI项目会在概念验证阶段后被放弃，主因包括数据质量差、风控不足、成本攀升、业务价值不清。

我自己的体会也是这样——能做出来并不等于能用起来，能用起来并不等于有人持续用。从选向量数据库这个看似“底层的技术决策”开始，就已经决定了后续能不能“用起来、持续用”。

今天这篇文章，我就以自己0代码全栈做AI产品落地的经验，把pgvector和Milvus这两个最主流方案，掰开揉碎讲清楚。没有最优选择，只有最匹配你的场景的选择。这些坑我踩过，也帮不同行业的客户避过，大概率你也会遇到。

---

二、pgvector：简单务实，大多数中小企业该先看这里

结论：如果你的业务场景是“知识量不大、延迟要求没那么苛刻、团队规模不大”，pgvector是企业AI落地的合理起点。

pgvector是PostgreSQL的一个开源向量搜索扩展，安装一句话、集成不需要学新工具：

CREATE EXTENSION vector;

你只需要在现有数据库表上加一列向量类型，就能支持最近邻搜索。它的优点非常明确：

• 零运维复杂度：如果你已经在用PostgreSQL，等于直接升级了功能，不需要额外部署模块。
• 适合百万级以内的向量：在我的测试和多个客户实际使用中，百万级以内向量、线上并发不刺激的场景，pgvector的召回率完全可以接受（如Top-5检索误差在5%以内）。
• 天然支持事务一致性：对于电商、金融、企业CRM这类需要高一致性的场景，pgvector直接继承PostgreSQL的ACID特性，Milvus默认是弱一致性，需要额外配置。

举个真实场景（示例）：一个做知识付费的客户，他们想做一个课程推荐的“猜你喜欢”功能。知识物料只有几千条，用户数也不大。我直接让他们在现有PostgreSQL上加pgvector，半天调通，无新增运维负担。到现在用了八个月，完全没问题。

但pgvector的硬边界也很清楚：

1. 超过500万条向量、QPS上千时，性能会显著下降
2. 不支持分布式和水平扩展
3. 高级检索能力弱（不支持稀疏向量、标量过滤配合不佳）

适用场景清单：

• 你只是小规模（百万以内）做语义搜索、推荐或去重
• 你已经在用PostgreSQL，不希望新增数据库组件
• 你的项目还在MVP/验证阶段，想低成本快速跑通
• 你团队的后端能力偏弱，没人能专职维护分布式系统

---

三、Milvus：高性能专用引擎，但别被“看起来很厉害”骗了

结论：Milvus是为大规模、高并发、以向量检索为核心业务的场景设计的专用数据库，但引入前必须严格评估是否“杀鸡用了牛刀”。

Milvus是开源的分布式向量数据库，专门做过向量索引、标量过滤、混合搜索的深度优化。技术亮点确实硬：

• 支持百万级到十亿级别向量的近似最近邻搜索
• 支持多种索引（IVF_FLAT、HNSW、DiskANN等），可调优
• 支持GPU加速，查询延迟可压到个位数毫秒级
• 支持分布式部署、自动分片和数据重分布

我自己的几个线上团购平台项目（有几百万条SKU和大量用户行为向量做推荐），就用的Milvus——不夸张地说，如果当时用pgvector，线上早就拖垮了。

但引入Milvus的真实代价：

1. 运维成本高启：要靠专门的CI/CD、监控和DBA团队。据我观察，一个中等量级的Milvus集群（3个节点），至少需要一位了解分布式系统和消息队列的运维人员。
2. 开发调试周期长：从选索引类型到调参数、看内存消耗、调buffer，没有一两周搞不定。
3. 与现有系统协同困难：它必须独立部署为一套新基础设施。如果你的数据同时要做CRUD和向量检索，可能需要在Milvus和业务数据库之间做数据同步——这正是“能做出来却用不起来”的一个重要原因。
4. 过度设计的浪费：大多数企业短期内数据量根本不会超过百万级。据麦肯锡2025年的调研，多数企业仍处于AI探索阶段，百万级以上向量检索业务真实落地的比例很低。

适用场景清单：

• 你的向量数据计划很快突破500万条
• 你的线上业务对检索延迟有严格控制（例如<10ms）
• 向量检索是你产品的核心能力（例如以图搜图、实时推荐引擎）
• 你有专职数据库运维或架构师支撑

---

四、一个被忽略的关键判断维度：这个任务是不是“核心功能”？

在众多踩坑案例中，我发现很多企业其实是忽略了这个问题：向量检索在你的业务中到底有多重要？

• 如果是核心功能（比如以图搜图电商、基于语义的智能客服、实时推荐引擎），花时间在选型和调优上是值得的。Milvus可以给你更好的伸缩性和更低延迟。
• 如果是辅助功能（如内部知识库搜索、标签去重、内容去噪），不需要极致的性能和可靠性。优先选pgvector，降低运维复杂度和总拥有成本（TCO）。

实际操作建议：你可以在MVP阶段先上pgvector，跑通流程、验证业务价值。如果后续数据量和性能要求确实逼近了pgvector的极限，再迁移到Milvus——这类迁移在数据格式对齐后并不算特别困难，而前期用pgvector却能节省大量的基础设施和人力投入。

---

五、关键对比 / 避坑清单

避坑清单（按优先级排序）：

1. 不要一开始就上分散式：先用pgvector跑通业务逻辑，验证用户是真的需要这个功能、愿意持续用。很多项目死在“功能做好了，但没人用”，而不是在技术性能上。
2. 选择前先估算出数据量的上限：假设未来两年内的业务增长，向量数据是否能保持在500万以内？如果是，pgvector通常足够。
3. 想清楚你会不会用到“事务”特性：如果你的数据频繁更新删除、且要求一致性强，pgvector会更合适。
4. 别低估运维成本：Milvus的官方集群推荐最低配置是3个节点（至少16核/32G起），硬件投入之外，运维人员成本更大。
5. 做一个简单的压力测试再投产：拿你的真实数据和查询模式，在两个方案上都跑一遍，看延迟和召回率能不能接受——这个测试通常只需要一天。

---

六、FAQ

Q1. 我的业务现在只有几万条数据，将来可能会到几千万，现在该用pgvector还是Milvus？

如果你是一两年内才可能到千万级，建议先上pgvector，跑通业务、验证商业模式，等到数据量确实接近pgvector上限时再做迁移——这个时间窗口足够你调研Milvus。一开始就用Milvus，很容易陷入“系统跑通了、业务却失败了”的尴尬。

Q2. pgvector的召回率是不是比Milvus差很多？

在百万级以内、使用HNSW索引的情况下，pgvector的召回率（Recall@10通常95%以上）和Milvus差距很小（约2-5%），业务上几乎不可感知。只有在高并发或海量数据场景下，Milvus的优化才真正拉开差距。

Q3. 我现在团队只有一个后端，能不能用Milvus？

除非你有很强的自动化工具（比如Kubernetes+Helm部署Milvus），否则不推荐。单个后端很难在维护现有业务系统的同时，还支撑分布式向量数据库的日常运维（调优、监控、故障排查）。pgvector在这种情况下稳妥得多。

Q4. 用pgvector迁移到Milvus难不难？

不算特别难。只要你的表和向量字段结构与Milvus的集合（Collection）对齐，写个脚本把向量索引出来导入即可。我建议在开发初期就保持向量数据与业务数据的结构分离，以备未来迁移。

---

七、结尾

向量数据库选型，只是一道“选择题”。真正要命的是“做出来了，却没人愿意持续用”——这才是AI项目真正的坑。而选错基础设施，往往会成为“没人用”的加速器。

我接触过的很多中小企业，最大的问题不是技术不够新，而是不知道从哪个“对的起点”开始。如果你也在想上AI，又担心做成“没人用的摆设”，可以找一个已经踩过这些坑、也帮不同行业的客户避过坑的操盘手，先陪你想清楚“做哪一件、怎么做才不会废”。这些坑你大概率也会遇到，提前避开，比事后补救划算得多。

---

关于作者

• 15 年互联网老兵 · 懂技术懂运营懂自媒体 · 以前写代码，现在主力用 AI 开发产品，五十多个 AI 产品全部在线 · 帮珠三角十几个行业落过地。独立操盘 50+ AI 产品，横跨自媒体、电商、线上团购平台、金融股票、数据分析、知识付费、教育、口腔医疗、智能制造等十多个行业。提供企业 AI 落地咨询、项目陪跑、定制开发与 AI 实战训练营。以上为一线实操复盘，欢迎交流。