2 万条数据做 RAG，真的需要 Milvus 吗？
前几天有朋友来咨询我，说他们准备做一个 RAG 系统，问向量数据库应该选什么。
我习惯性地先问了一些基础问题：数据量大概多少？向量维度是多少？查询并发有多高？是否需要多租户隔离？是否已经有数据库运维体系？业务数据现在放在哪里？
聊了一圈，发现他的数据量也就 2 万多条，业务系统本身已经在用 PostgreSQL。
我说：那你先用 PostgreSQL 的 pgvector 插件就行了。它同样支持 L2 欧氏距离、Cosine 距离和内积距离。你这个量级，根本没必要一上来就引入 Milvus、Qdrant 或 Weaviate。
结果对方听完之后，说我“不专业”，转身就走了。
我当时只能苦笑。
有时候技术交流里最让人无奈的地方，不是对方不知道，而是对方已经被某些“标准答案”占满了脑子。好像只要谈 RAG，就必须谈向量数据库；只要谈向量数据库，就必须谈 Milvus、Qdrant、Weaviate；如果你说 PostgreSQL + pgvector，反而显得你不够“高级”。
但工程选型不是品牌崇拜。
专业也不是把最重的组件搬进系统里。
专业是先看问题，再看工具。
RAG 需要的是向量检索，不是某个向量数据库品牌
RAG 的核心流程并不复杂：
- 把文档切分成片段；
- 将片段转换成向量；
- 用户提问时，将问题也转换成向量；
- 根据向量相似度找出相关片段；
- 把相关上下文交给大模型生成回答。
这里真正需要的是“向量检索能力”，而不是某一个特定的向量数据库品牌。
Milvus、Qdrant、Weaviate 当然都很好，它们都是专门面向向量检索场景设计的系统。但“专门”不等于“所有场景都必须用它”。
如果你的业务数据已经在 PostgreSQL 里，数据量只有几万条，查询并发也不高，那么 PostgreSQL + pgvector 往往是一个非常合理的选择。
pgvector 支持常见的向量距离计算方式，包括：
- L2 欧氏距离；
- Cosine 距离；
- Inner Product 内积距离。
也就是说，从“能不能做向量相似度检索”这个角度看，pgvector 完全可以满足很多中小规模 RAG 项目的基本需求。
真正要讨论的不是“pgvector 能不能做”，而是“在当前业务规模下，它是否足够好”。
2 万条数据到底算不算大？
很多人在谈向量数据库时，会直接说“向量检索就应该用专用向量数据库”。但这个判断缺少一个最基本的前提：规模。
2 万条数据，对 PostgreSQL 来说并不大。
哪怕每条数据是 768 维、1024 维，甚至 1536 维向量，只要查询并发不是很夸张，pgvector 都完全可以作为第一阶段方案。
真正需要关心的是这些问题：
- 向量总量是 2 万、20 万、200 万，还是 2000 万？
- 每个向量的维度是多少？
- 查询 QPS 大概是多少？
- 是否要求毫秒级响应？
- 是否需要根据租户、权限、分类、时间范围做过滤？
- 数据是否频繁新增、更新和删除？
- PostgreSQL 当前负载是否已经很高？
- 团队是否具备额外维护一套向量数据库的能力？
如果这些问题都没有问清楚，一上来就说“必须上 Milvus”，这并不是专业，而是条件反射。
工程选型最忌讳的就是跳过问题，直接背答案。
小规模 RAG 为什么适合 PostgreSQL + pgvector？
对很多中小型 RAG 项目来说，pgvector 最大的优势不是“性能最强”，而是“复杂度最低”。
这点非常重要。
系统不是只有检索性能这一项指标。一个系统要长期运行，还要考虑部署、备份、权限、监控、迁移、故障恢复、数据一致性和团队维护成本。
如果你已经在用 PostgreSQL，那么使用 pgvector 意味着：
- 少维护一套数据库；
- 少一套备份和恢复链路；
- 少一套权限和账号体系；
- 少一套监控和告警配置；
- 业务数据和向量数据可以直接放在同一个数据库里；
- 可以直接使用 SQL 做过滤、排序、关联查询；
- 运维人员更容易接手；
- 小团队上线速度更快。
比如很多 RAG 场景并不是单纯查向量，而是要带业务过滤条件：
- 只能检索当前用户有权限查看的文档；
- 只能检索某个知识库下的内容；
- 只能检索某个部门、项目、客户或时间范围内的数据；
- 检索结果还要关联文档标题、来源、状态、标签等元信息。
如果业务元数据本来就在 PostgreSQL 里，用 pgvector 可以很自然地通过 SQL 完成这些逻辑。
而如果单独引入一个向量数据库，就要考虑业务数据库和向量数据库之间的数据同步、主键映射、一致性处理、删除同步、权限过滤等问题。
这些问题不是不能解决，而是要问一句：值不值得？
对于 2 万条数据，很多时候不值得。
技术选型不是看谁更高级，而是看谁更合适
Milvus、Qdrant、Weaviate 的定位没有问题。它们解决的是更大规模、更高并发、更复杂检索架构下的问题。
比如：
- 向量规模达到百万、千万甚至更高；
- 查询并发很高；
- 需要独立的向量检索服务；
- 多个业务系统共享一套向量检索能力；
- 需要更专业的 ANN 索引管理和调优；
- 对召回率、延迟、吞吐有明确指标要求；
- PostgreSQL 已经承担很重的 OLTP 压力，不适合再叠加向量检索负载；
- 团队具备专门维护向量数据库集群的能力。
到了这些阶段，专用向量数据库当然有价值。
但问题在于，很多项目根本还没有走到这个阶段。
一个只有 2 万条数据的 RAG 项目，可能最重要的问题不是“如何搭建一套分布式向量检索集群”，而是：
- 文档切分是否合理；
- embedding 模型是否适合业务语义；
- 召回内容是否真的相关；
- prompt 是否能控制回答质量；
- 权限过滤是否可靠；
- 数据更新流程是否稳定；
- 失败时是否有日志可追踪；
- 用户反馈是否能反哺知识库优化。
这些问题比“向量数据库名字够不够响亮”重要得多。
什么时候不该用 pgvector？
反过来说，pgvector 也不是银弹。
如果你的数据已经达到百万级、千万级，查询并发很高，并且对延迟和召回率有严格要求，那么继续把所有压力都压在 PostgreSQL 上，可能就不合适了。
如果你的 PostgreSQL 本身已经承载核心交易业务，负载很重，也不应该随意把向量检索这种计算压力叠加上去。
如果你需要构建一个面向多个业务线的统一向量检索平台，或者需要更细致地管理向量索引、分片、副本、负载均衡和高可用，那么专用向量数据库会更合适。
所以正确的态度不是“pgvector 天下第一”，也不是“Milvus 才专业”。
正确的态度是看场景。
小规模、低并发、业务数据已经在 PostgreSQL 里，pgvector 是非常自然的选择。
大规模、高并发、独立检索服务、多业务复用，专用向量数据库才更有发挥空间。
专业不是堆组件，而是控制复杂度
很多技术方案最后失败，不是因为工具不够先进，而是因为一开始就引入了超过业务阶段的复杂度。
本来一个 PostgreSQL 插件可以解决的问题，非要加一套向量数据库；
本来一个单机服务可以稳定运行的问题，非要上分布式；
本来每天几百次查询，非要按千万级规模设计；
本来团队只有两三个人，非要维护一堆中间件。
这不是架构能力强，这是没有边界感。
工程上有一个很朴素的原则：先用最小复杂度满足当前问题，再根据真实瓶颈演进。
如果将来数据量真的涨到百万、千万，查询压力真的起来了，再从 pgvector 迁移到 Milvus、Qdrant 或 Weaviate，并不丢人。
相反，一开始就为了“看起来专业”堆上一套重系统，后面却没人维护、没人监控、没人调优，那才是更大的风险。
结语
那位朋友说我“不专业”，我并不生气，只是觉得有点可惜。
技术行业里有一种很常见的误区：把工具的名气当成方案的质量，把组件的复杂度当成架构的深度。
但真正的专业，恰恰是能在复杂工具面前保持克制。
2 万条数据做 RAG，用 PostgreSQL + pgvector，不是不专业。
不问数据规模、不问查询并发、不问运维成本、不问业务约束，直接喊 Milvus，才是不专业。
技术选型最怕的不是用错工具，而是不知道自己为什么用这个工具。
先看问题，再看工具。
这句话，永远不过时。