做 RAG 系统的时候，第一个要回答的选型问题就是，向量数据存哪里。这个选择会影响后续的开发成本、运维负担和扩展能力，值得花时间想清楚。
但很多人选型的思路是错的。他们先问「哪个向量库最好」，然后去搜排行榜，选榜单第一的那个。这是技术虚荣，不是工程决策。正确的思路是，先搞清楚自己的规模、团队能力、预算，再看哪个最匹配。这篇把主流的几个选项拆开，讲清楚各自适合什么场景。
pgvector，中小规模的务实首选
pgvector 是 PostgreSQL 的向量扩展。它的最大卖点不是性能，是你已经在用 PG 了，加个扩展就能存向量，不用引入任何新基础设施。
对大多数 RAG 应用来说，数据量在百万级以内，pgvector 完全够用。它支持 HNSW 索引，检索速度和精度都不差。SQL 和向量查询统一在一个库里，可以「先按业务条件过滤，再做向量检索」，这个能力在真实业务里非常常用，比如「在我有权限的文档里检索相关的」。
它的最大价值是零成本。团队已经会 PG，运维已经监控着 PG，备份恢复的流程都现成。加个 pgvector 扩展，向量检索的能力就有了，没有引入新的故障点和学习成本。
代价是规模上限。千万级以上向量，pgvector 的检索性能会下降，HNSW 索引的构建变慢，单机的内存和计算成为瓶颈。到这个量级，就要考虑专门的向量库或者分库分表了。
我的建议是，除非你确定数据量会到千万级以上，否则从 pgvector 开始。别为了「专业」而引入 Milvus 这种重量级组件，pgvector 扛得住就别加复杂度。等真扛不住了再迁移，那时候你对需求的理解也比现在清楚。
Milvus，大规模和高级检索的选择
Milvus 是专门的向量数据库，为海量向量检索设计。它的优势在规模和功能。
规模上，十亿级向量也能撑住，靠的是分布式架构和多种索引类型的支持。功能上，它支持更复杂的检索，比如混合检索、多向量检索、标量过滤，这些在高级 RAG 场景里会用到。
代价是重。Milvus 是个分布式系统，自己部署要管好几个组件（etcd、MinIO、Pulsar 等），运维负担不小。团队的工程能力不到，部署起来容易出各种环境问题。学习曲线也陡，它的概念和 API 比 pgvector 复杂得多。
所以 Milvus 适合两种情况。一是数据量真的很大，pgvector 扛不住。二是团队有能力也有意愿运维一个分布式系统，并且需要它的高级检索功能。两个条件都不满足就别碰，得不偿失。
托管服务，省心但要花钱
Pinecone、Weaviate Cloud、Zilliz Cloud（Milvus 的托管版）这些是托管向量服务。它们把运维全包了，你只管调 API 存取向量。
好处是省心。不用部署、不用运维、不用管扩容，开通就用。对创业团队或者想快速验证想法的场景，托管服务能省下大量工程投入。
代价是成本和锁定。托管服务按用量收费，数据量大、检索频繁的时候，费用会涨得很快，长期算下来比自建贵不少。而且数据锁在别人的服务里，迁移成本不低，接口也是各家不一样，换一家等于重写检索层。
托管服务适合数据量不大但想省运维成本的场景，或者验证阶段的快速起步。等规模上来、成本敏感了，再考虑迁回自建。
图：pgvector / Milvus / 托管服务三方案在规模、运维、成本三个维度上的对比。
选型的真实决策框架
抛开具体产品，向量库选型该问自己这几个问题。
数据规模多大。百万级以内，pgvector 没压力。千万级，pgvector 勉强或者要分库。亿级以上，专门的向量库。这是第一道筛选。
团队运维能力怎么样。能驾驭分布式系统的，Milvus 可选。只有 DBA 经验的，pgvector 或者托管更稳。别选一个团队驾驭不了的工具，那不是先进是负担。
成本敏感度。预算充足要省事的，托管服务。成本敏感能投入人力的，自建。长期大规模使用，自建通常比托管便宜。
和现有系统的集成。已经重度用 PG 的，pgvector 几乎零成本接入。已经用云厂商一整套服务的，那个云的托管向量服务集成最顺。选型和已有基础设施匹配，能省很多集成成本。
图：向量库选型决策流程——以数据规模为第一道筛选，再依次校验运维能力与成本敏感度。
一个真实的选型案例
我自己落地的 RAG 系统选了 pgvector。原因是，数据量在百万级，团队已经用 PG，服务器资源紧张（3.8G 内存），不想再引入一个分布式组件。pgvector 加 HNSW 索引，配合 RRF 融合检索，效果完全够用。
重排用 BGE-Reranker，资源紧张时降级跳过。这个降级设计很重要，保证核心检索功能在资源不够时也能跑，不因为一个可选组件挂了就整个不可用。
向量维度锁死 768，因为 Embedding 模型输出 768 维，这个决策一旦定下就不能轻易改，改了等于全库重算。选型时就把维度和模型一起定死，避免后期的维度漂移问题。
大多数技术选型是可逆的，pgvector 扛不住了可以迁到 Milvus，虽然麻烦但能做到。但有一个决策几乎不可逆，就是 Embedding 模型和向量维度。一旦存量向量按某个维度生成了，换模型换维度等于全库重新 embedding，数据量大的时候这是个重活。所以选型时，先把 Embedding 模型和维度这个最不可逆的决策想清楚，其他都可以边走边调。
图：作者真实落地的 RAG 架构——pgvector + HNSW 承载百万级 768 维向量，RRF 融合检索，BGE 重排可降级跳过，维度锁死避免全库重算。
别被「先进」绑架
最后说一个心态层面的点。
技术圈有种风气，觉得用专门向量库、用分布式、用云原生才显得专业。这种心态会让人选一个超出自己需求的工具，徒增复杂度。
工程选型的唯一标准是，匹配当前和可预见未来的需求，用最低的总成本（开发加运维加金钱）解决它。pgvector 能解决的就用 pgvector，别为了显得专业而过度设计。工具是手段不是目的，选型的功夫到家了，系统会简单、稳定、好维护，这才叫专业。
