每次有人问我"做 RAG 到底用哪个向量库"，我都想先反问一句：你手上有多少数据，有多少人维护，预算是零还是无穷？这几个问题答完，选型基本就定了。可现实是大多数人直接打开 GitHub，按 star 数从上往下抄，结果上了线才发现踩了一脚泥。这篇文章不灌鸡汤，直接把 Milvus、Qdrant、Weaviate、Chroma、pgvector 五个常被点到名字的家伙摆在一张桌上，用真实数据横评，再按场景给结论。
先说清楚两个前提：第一，star 数截至 2026-07-29，实时变动，别当圣经；第二，下面涉及性能的对比是代表性对比，非亲自压测，我引用的是各项目官方描述和社区共识，不是我在同一台机器上跑出来的压测数字。你要做选型决策，拿这个当起点，别当终点。
一、为什么向量数据库突然成了"刚需"
这事得从 RAG 说起。大模型记不住你的私有文档，也不会实时联网，唯一靠谱的办法是把文档切块、转成向量、塞进一个能做相似度检索的库里，检索出来拼进 prompt 再喂给模型。这个库就是向量数据库。
但你很快会发现，传统的 ES 或者 Postgres 全文检索干不了这活——它们不擅长在高维空间里做近似最近邻（ANN）搜索。于是专门为向量检索设计的数据库冒出来了，Milvus、Qdrant、Weaviate、Chroma 都是这条路。pgvector 则走了另一条：不另起炉灶，给 Postgres 加个扩展，让它也能干向量检索的活。
选型的核心矛盾，其实不是"哪个最强"，而是"你要不要为向量检索单独养一个服务"。这一刀切下去，五个选项自然分成了两派。
二、五款横评：数据说话
先把硬数据摆出来。star 数截至 2026-07-29，实时变动；活跃度以近期 push 情况判断，五个项目目前都在活跃维护。
| 项目 | Star | 语言 | 许可证 | 部署形态 | 规模定位 | 官方特色描述 |
|---|---|---|---|---|---|---|
| Milvus | 45,408 | Go | Apache-2.0 | 独立服务（云原生） | 超大规模生产 | 高性能云原生向量库，面向可扩展向量 ANN 检索 |
| Qdrant | 33,640 | Rust | Apache-2.0 | 独立服务 | 中大规模 | 高性能大规模向量库与向量搜索引擎 |
| Weaviate | 16,656 | Go | BSD-3-Clause | 独立服务 | 中规模 | 同时存对象与向量，向量检索 + 结构化过滤 |
| Chroma | 28,900 | Rust | Apache-2.0 | 嵌入式 / 独立 | 轻量起步 | AI 搜索基础设施，轻量易上手 |
| pgvector | 22,385 | C | NOASSERTION | Postgres 扩展 | 中小规模 | Postgres 的开源向量相似度搜索扩展 |
这张表里有几个点值得多看一眼。
star 排序不等于能力排序。Milvus 4.5 万星遥遥领先，但它的定位本来就是冲着超大规模去的，star 多有一部分是先发优势加中文社区基本盘。Chroma 2.8 万星压过 Weaviate，很大程度上是因为它吃到了 AI 应用爆发第一波的红利——开发者刚开始折腾 LangChain 的时候，Chroma 是默认教程里的那个库，门槛低到 pip install 就能跑。
语言上，Qdrant 和 Chroma 都选了 Rust，这不是巧合。向量检索是计算密集型的活，Rust 在零成本抽象和内存安全上的优势，在这种场景下能直接转化为吞吐和延迟的收益。Milvus 和 Weaviate 选了 Go，更偏工程化和云原生生态。pgvector 用 C 写，因为它要作为扩展跑在 Postgres 进程里，必须贴近内核。
许可证那一栏，四个都是 Apache-2.0 或 BSD-3-Clause，这类是商业友好的宽松许可。但 pgvector 标的是 NOASSERTION——GitHub 没能自动识别出一个明确的开源许可证。我查了项目仓库根目录的 LICENSE 文件，实际上它用的是 PostgreSQL License（类似 BSD），但 GitHub 没标成标准 SPDX。这里要划重点：如果你公司法务卡得严，NOASSERTION 这个标签就够你走一轮合规流程。别等到上线前才被发现。
三、逐个拆解：谁适合什么活儿
数据是骨架，场景才是血肉。下面按"你是谁、你要干嘛"来对号入座，这是我在做选型时真正会问的问题。
超大规模生产选 Milvus
Milvus 的官方定位是"高性能云原生向量库，面向可扩展向量 ANN 检索"。翻译成人话：它是为亿级以上向量、需要水平扩展、要跑在生产环境里的场景设计的。它支持多种索引类型，有存算分离架构，能挂 S3 当存储后端。
代价是什么？运维成本。Milvus 不是 pip install 就能跑的东西，它的完整部署涉及 etcd、MinIO、Pulsar 等一堆依赖组件，即便用 Docker Compose 也是十几个容器起步。小团队上 Milvus，运维开销可能比业务开发还重。所以选它之前先问自己：你的向量量级真到千万、亿级别了吗？没到，就是杀鸡用牛刀。
Rust 性能选 Qdrant
Qdrant 官方描述是"高性能大规模向量库与向量搜索引擎"。它用 Rust 写，单机吞吐和内存占用表现好，API 设计干净，还自带一个很好用的过滤功能。3.3 万星、活跃维护，是目前独立向量服务里 Milvus 之外最常被提到的替代。
Qdrant 的甜区是中大规模、追求单机性能、不想被 Milvus 的组件 zoo 拖垮的团队。部署一个二进制就能跑，比 Milvus 轻得多；但因为没有 pgvector 那种寄生在现有 Postgres 上的便利，它依然是一个需要单独运维的服务。如果你的运维人力只够养一个数据库，Qdrant 是独立向量库里性价比比较高的那个。
混合检索选 Weaviate
Weaviate 的官方特色是"同时存对象与向量，向量检索 + 结构化过滤"。这一句就把它的差异点说清楚了：它不只是存向量，还存对象本身，这意味着你可以在做向量相似度搜索的同时，叠加结构化过滤——比如"找和这段话最相似的文档，但只要 2025 年之后发布的、标签是技术的"。
这种混合检索在 RAG 场景里非常实用，因为纯向量检索经常召回一堆语义相近但完全跑题的结果，加一层元数据过滤能大幅提升召回质量。Weaviate 1.6 万星，比前两位低，但它的定位本来就是功能全、一体化，不是拼极致规模。如果你的 RAG 管线对召回质量敏感、又不想自己在应用层拼一套过滤逻辑，Weaviate 值得优先看。
轻量起步选 Chroma
Chroma 的官方描述精髓就四个字：轻量易上手。它定位是 AI 搜索基础设施，但真正的杀手锏是开发体验——pip install chromadb，几行代码就能在本地跑起来，不需要起服务、不需要配依赖。2.8 万星里有相当一部分是被 LangChain 教程安利进来的开发者。
Chroma 适合什么阶段？原型验证、demo、个人项目、刚起步的 RAG 实验。它的嵌入式模式可以和数据放在同一个进程里，连服务都不用起。但它的生产成熟度和大规模能力，和 Milvus、Qdrant 不是一个量级。我的建议是：用 Chroma 把想法跑通，一旦进入要上生产、数据量上百万的阶段，认真考虑迁移。
已在用 Postgres 选 pgvector
pgvector 是唯一一个寄生型选手——它不是独立数据库，是 Postgres 的一个扩展。官方描述：Postgres 的开源向量相似度搜索扩展。你不用引入新组件、不用养新服务，CREATE EXTENSION vector 就能让你的 Postgres 干向量检索的活。
这个路线的诱惑力显而易见：如果你已经在用 Postgres 存业务数据，加一个扩展就能让同一套库同时干关系型查询和向量检索，运维成本几乎为零。2.2 万星说明这个思路戳中了很多团队。但 pgvector 也有明显的天花板——它的 ANN 索引在千万级以上向量时，吞吐和召回速度会明显落后于专门的向量库。所以 pgvector 的甜区是中小规模、已重度依赖 Postgres、不想引入新基础设施。规模一旦上去，它就不是最优解了。
四、选型决策树：三分钟定下来
讲了这么多，给你一个能照着走的决策树。按顺序问自己：
- 你已经在用 Postgres 吗？ 是，优先 pgvector，向量量级在百万以内基本够用。否，进入下一问。
- 你的向量量级在千万、亿级别吗？ 是，Milvus，这是它的主场。否，下一问。
- 你重视单机性能和 Rust 技术栈吗？ 是，Qdrant。否，下一问。
- 你需要向量加结构化数据的混合检索，且想一体化存储？ 是，Weaviate。否，下一问。
- 你是在做原型验证、个人项目、或者刚起步？ 是，Chroma，先把流程跑通。
这不是一套能覆盖所有边缘情况的完美决策树，但它能帮你排除掉 80% 的错误选项。剩下 20% 的纠结，通常是因为需求本身没想清楚——比如既想轻量又想扛亿级，这种既要又要的，最后往往什么都做不好。
五、避坑指南：运维、许可证、托管
横评做完，三个坑必须单独拎出来说，都是上线前最容易翻车的地方。
第一，运维成本。 这五个里，Milvus 的运维最重，完整部署要 etcd 加 MinIO 加 Pulsar 一整套，建议直接上官方托管 ZillizCloud 或者 K8s operator，别手动维护。Qdrant 和 Weaviate 居中，单二进制或单容器能跑，但生产环境还是要配监控和备份。Chroma 最轻，嵌入式模式零运维，但生产部署要切 client-server 模式。pgvector 的运维成本就是你 Postgres 的运维成本——已经在养的那个库，加个扩展几乎不增加负担。
第二，许可证的 NOASSERTION。 前面提过，pgvector 在 GitHub 上的许可证标签是 NOASSERTION，虽然实际仓库里用的是 PostgreSQL License。如果你公司有严格的合规流程，这个标签会被法务系统标记。四个 Apache 和 BSD 项目的许可证都是商业友好的，可以放心用在商业产品里。pgvector 不是不能用，是要多走一步确认。
第三，托管 vs 自托管。 这是比选哪个更上游的决策。如果你的核心业务不是搞数据库，托管能省下的运维人力远超那点订阅费。Milvus 有 ZillizCloud，Qdrant 有 Qdrant Cloud，Weaviate 有 Weaviate Cloud，pgvector 在几乎所有托管 Postgres（Supabase、Neon、RDS）上都预装好了。Chroma 的托管选项相对少，这也是它更适合早期阶段的原因之一。一个简单的判断标准：如果你的向量库挂了会导致业务中断，而你又没有专职 DBA，托管是更稳的选择。
六、我的建议
最后给你一句大实话：这五个里没有最好，只有最合适。Milvus 不是因为有 4.5 万星就适合你，pgvector 也不会因为 star 少就低人一等。选型的关键，永远是先把自己的规模、运维能力、技术栈、预算这四件事想清楚，再回来对号入座。
如果你问我一个最稳的起手式：先用 Chroma 把 RAG 管线跑通，验证业务逻辑；数据量起来后，如果已经在用 Postgres，迁 pgvector；如果要独立服务，选 Qdrant；如果真冲着亿级去了，再上 Milvus。这条路径不是最快的，但它能让你在每个阶段都不为基础设施分心，把精力留在真正产生差异的业务逻辑上。向量库是 RAG 的地基，但地基再好，上面盖的是个茅草棚还是摩天大楼，取决于你用它做什么，而不是它本身有多强。
参考来源