向量数据库选型实录：Chroma、Milvus、pgvector到底怎么选

在做RAG知识库问答系统的过程中，我遇到了一个绕不开的选型问题：向量数据存哪？网上推荐一堆——Chroma、Milvus、pgvector、Qdrant、Weaviate——每个都说自己好。为了给项目一个靠谱的结论，我花了一周时间把主流方案都实测了一遍。这篇文章把选型过程和结论整理出来，帮你少走弯路。

一、先明确需求再选型

动手之前，我先列出了自己的真实需求：

• 数据量：知识库文档约10万段，后期可能涨到百万级；
• 查询要求：单次检索延迟<300ms，准确率要可接受；
• 部署环境：公司内网，Docker/K8s均可，数据不能上公有云；
• 团队能力：运维能维护一个中间件，但没有专门的大数据团队；
• 成本：能少一个组件就少一个，能复用现有设施最好。

二、三套方案的实测对比

我重点实测了三个：Chroma（轻量嵌入式）、Milvus（专用向量数据库）、pgvector（PostgreSQL扩展）。

三、实测中的关键发现

1. 小数据量三者差距不大，别过度设计

测到10万向量这个量级，三个方案的检索准确率几乎一样（都用的HNSW索引，结果基本一致），延迟差距也就是几十毫秒的差别。对大多数中小企业场景，数据量根本撑不到需要Milvus的地步——很多团队一上来就上Milvus，结果运维成本全花在了用不到的能力上。

2. 检索效果的关键不在数据库，在Embedding和切分

实测中最意外的发现：换一个更好的Embedding模型，检索准确率的提升远大于换数据库。同样的数据，用bge-m3做向量比用老模型高好几个百分点。还有文档切分策略——切分太粗、太细都会让检索质量明显下降。所以选型时别把宝全押在数据库上，先把"向量怎么来、文档怎么切"这些前置环节做扎实。

3. 混合检索才是"真香"

单纯向量检索在专业术语多、同义词多的场景会丢分。我给pgvector和Milvus都加了BM25全文检索做混合（向量+关键词加权融合），准确率提升明显。如果你的场景术语密集，建议直接选支持混合检索的方案，或者像我们一样向量库+Elasticsearch搭配。

4. 运维成本容易被低估

Milvus在生产环境要部署etcd、MinIO、Proxy、Coordinator等一串组件，排障难度高；pgvector就是一个插件，跟着PostgreSQL的备份、监控、权限体系走，运维负担几乎为零。

四、我的最终选择

最终我们选了 pgvector，理由很实际：

1. 公司已有PostgreSQL集群，复用现有设施，零新增组件；
2. 数据量10万级，pgvector的性能完全够用；
3. 权限、备份、监控全部沿用数据库现有体系，运维成本最低；
4. 用HNSW索引+并行查询，实测检索延迟稳定在100ms以内。

同时我在架构上留了"逃生通道"：向量检索逻辑封装成独立接口，如果未来数据量真的涨到千万级，可以无缝切换到Milvus，业务代码不用改。

五、总结

我的选型心得就三条：

1. 先量化需求再选型：把数据量、延迟、并发、运维能力写下来，对着需求选，别听"最火的就是最好的"；
2. 数据量是分水岭：百万级以下，pgvector或Chroma完全够用；真要千万级、高并发，才轮到Milvus这类专业选手；
3. 别忽视"检索质量"：数据库解决的是"存和查"，检索准不准主要看Embedding和切分——这两样没做好，换什么数据库都白搭。

如果你正在做RAG选型，建议从"已有设施优先、够用就好"的角度出发。很多时候，最朴素的选择就是最好的选择。