Chroma 替代方案对比：Qdrant/Milvus/pgvector怎么选

🇺🇸
Read in English: Chroma Vector Database Alternatives: When to Switch, When Not To

一位朋友曾经跟我说过他第一次搭 RAG 应用时的经历。他用 Chroma 把文档切片嵌入向量，本地跑起来丝滑得不行，demo 给老板看的时候完全没问题。然后上线，三周后数据量涨到几十万条，查询开始变慢，某天 pod 重启，向量索引不见了。他花了一个周末才搞清楚：Chroma 默认是把数据存在内存里的，持久化要自己配，而且他配的方式不对。

这不是 Chroma 的问题，准确说是他用错了场景。Chroma 本来就是给”快速验证想法”设计的工具，文档里也没藏着这件事。但当项目从 demo 走向实际运行，这种用法上的错位就开始引发麻烦。

向量数据库这个赛道在过去两年里突然热闹起来，直接原因是大语言模型的普及。几乎每个做 AI 应用的团队都要解决同一个问题：怎么给模型提供外部知识？答案通常是 RAG，而 RAG 的关键基础设施就是能存储和检索向量嵌入的数据库。问题在于，选哪个？

这篇文章想帮你想清楚这件事。

自托管开源这条路

如果你有足够的工程能力和基础设施资源，自托管开源方案能给你最大的控制权和最低的长期成本。这个阵营里，Qdrant 和 Milvus 是最值得看的两个。

Qdrant 的故事

Qdrant 是用 Rust 写的，这件事本身就说明了它的设计取向：性能优先，资源占用低。它提供了相当完善的过滤查询能力，可以在向量相似度搜索的同时附加结构化条件，比如”只在这个用户的文档里搜””只找过去 30 天上传的文件”。这类需求在真实应用里很常见，但 Chroma 处理起来并不顺畅。

Qdrant 支持多种向量索引算法，可以根据数据集大小和查询延迟要求进行调整。它有自己的云服务，也可以完全自托管，Docker 部署文档写得很清楚。对于数据量在百万条以上、需要稳定生产运行的场景，Qdrant 是一个成熟可靠的选择。

它的上手成本比 Chroma 高一些，API 设计更像传统数据库，需要先理解 collection、payload、point 这些概念。但这个成本是值得付的，因为你在换取的是更稳定的生产行为和更强的查询能力。

Milvus 的体量感

如果 Qdrant 的定位是”生产级别的向量数据库”，Milvus 的定位更接近”面向企业的向量数据库基础设施”。它是 LF AI & Data Foundation 的项目，由 Zilliz 主导开发，设计目标是处理十亿级向量规模的场景。

Milvus 的架构是分布式的，计算和存储分离，可以独立扩展。它支持的向量索引类型非常多，IVF、HNSW、DiskANN 等算法都有，可以根据数据规模和内存限制灵活选择。

但这些能力是有代价的。Milvus 的部署比较重，生产部署依赖 etcd、MinIO、Pulsar 等一系列组件，光是把这些东西跑起来就需要一定的运维投入。如果你的团队没有相应的基础设施经验，维护成本会比较高。

Milvus 还有一个叫 Milvus Lite 的轻量版本，适合本地开发和小规模部署，算是弥补了部署复杂度高这个问题。如果你预期数据量在千万到亿级，或者是个需要严肃对待数据库运维的组织，Milvus 值得认真评估。

Weaviate：语义搜索的另一个视角

Weaviate 在这个领域走的是稍微不同的路。它把自己定位为”向量搜索引擎”，除了标准的向量相似度查询，还内置了混合搜索能力，可以把向量搜索和关键词搜索结合起来。它还有一个特别的模块系统，可以直接在数据库里运行嵌入模型，不用在外部生成向量再写入。

对于需要语义搜索加全文搜索混合的场景，比如电商的商品搜索、知识库的问答系统，Weaviate 的这个设计很有吸引力。你不需要在外部维护两套索引再手动合并结果。

Weaviate 有云服务，也可以自托管，社区活跃，文档质量不错。但它的 API 设计比较独特，学习曲线相对陡峭，从其他系统迁移过来需要适应一段时间。

—

pgvector：已经有 Postgres 了？

有一类场景经常被忽视：你的应用本来就在用 PostgreSQL，然后需要加向量搜索能力。这时候很多人的反应是”那我是不是得再加一个向量数据库”，但其实 pgvector 这个扩展插件值得先看一眼。

pgvector 让 PostgreSQL 能直接存储向量，支持余弦相似度、欧式距离等常见距离函数，可以建索引加速查询。最重要的是，它完全在 PostgreSQL 里运行，意味着你可以在同一个查询里把向量相似度搜索和现有的关系型数据结合起来，事务、权限、备份全部复用现有的 PostgreSQL 基础设施。

如果你的数据量在几百万条以内，不需要极端的查询延迟，已经有 PostgreSQL 运维经验，pgvector 可能是阻力最小的选择。你不需要学习新的数据库，不需要增加新的运维负担，也不需要处理两套数据的同步问题。

pgvector 的局限是在超大规模场景下性能比专用向量数据库差，过滤复杂查询时的优化空间也没有专用系统丰富。但对于大多数中小规模的 AI 应用，这些不是问题。

值得一提的是，Supabase 把 pgvector 作为默认支持的功能，如果你在用 Supabase，向量搜索基本上是开箱即用的。

—

Pinecone：把运维外包出去

自托管意味着你要自己管理数据库的部署、扩容、备份、监控。对于很多团队来说，这不是他们想做的事。Pinecone 的定位就是把这些全部帮你搞定。

Pinecone 是完全托管的向量数据库云服务，不需要自己管理任何基础设施。它的查询延迟控制得很好，在高并发场景下的稳定性是经过大量实际应用验证的。对于快速迭代、不想花时间在基础设施上的团队，它能节省相当多的工程时间。

但 Pinecone 有几个需要想清楚的地方。首先是成本，托管服务按查询量和存储量计费，在数据量大、查询频繁的场景下账单会很可观。其次是数据主权，数据存在第三方服务上，对于有合规要求的业务来说可能是个问题。第三是供应商绑定，切换出去的迁移成本不低。

如果你的 AI 应用处于快速增长期，工程团队的主要精力需要放在产品功能上而不是数据库运维上，Pinecone 是一个合理的选择。把基础设施的复杂度变成一个月付的账单，这个交换对某些团队来说是划算的。

—

选哪个？一张表帮你定位

在看完这些方案之后，一个自然的问题是：我的场景到底适合哪个？

下面这张表梳理了几个可以直接核查的维度：

工具	部署方式	开源协议	大概定价模式	最适合的场景
Chroma	本地/自托管	Apache 2.0	免费（开源）；云版测试阶段	本地原型、快速验证、小数据量
Qdrant	自托管/托管云	Apache 2.0	开源免费；云按用量计费	生产级应用、需要复杂过滤
Milvus	自托管/Zilliz 云	Apache 2.0	开源免费；云按用量计费	超大规模、企业级基础设施
Weaviate	自托管/托管云	BSD-3	开源免费；云按节点计费	混合搜索（向量+关键词）场景
pgvector	PostgreSQL 插件	PostgreSQL 协议	免费（随 PG）	已有 Postgres、中等规模、要简单
Pinecone	完全托管云	商业闭源	免费额度+按量付费	不想自管基础设施、需要快速上线