向量数据库选型：Chroma、Qdrant、Milvus 的分工

向量数据库这两年跟着 RAG 一起火起来，选型也就成了新团队的必修课。但很多选型文章的问题在于给了一堆 benchmark 数字，却没回答最核心的问题：你现在的项目在哪个阶段。选型不是选「最快的」，是选「和你当前规模、人手、预算匹配的」。这篇把几个主流选项的分工讲清楚。

选型看阶段

向量数据库选型的第一原则是看阶段，不是看性能排行。Demo 阶段要的是最快出结果，产品化阶段要的是性能和部署的平衡，企业生产阶段要的是分布式、SLA 和数据管理。这三个阶段对应完全不同的选项，错配的代价在早期看不出来，等数据量涨上来才暴露，而那时的迁移成本不低。如果一开始就预期要上规模，务实的做法是直接跳过最轻的选项、从中档起步，省掉后面数据迁移的痛。

几个主流选项

Chroma 是嵌入式、零配置的选项，pip 装完就能用，本地跑，最适合原型验证和个人项目，但单机、功能有限，撑不住高并发。Qdrant 是 Rust 写的开源向量库，单机性能强、过滤能力强，有免费额度，适合自托管的 MVP 到中型生产。Milvus 面向超大规模分布式场景，支持亿级向量、冷热分层，但运维复杂、上手门槛高。Weaviate 走的是混合搜索路线——向量搜索加 BM25 关键词搜索，再配 GraphQL API，内置多模态向量化，适合语义加关键词要结合的场景。还有 pgvector：如果你的应用已经在用 PostgreSQL，加个扩展就能上向量，免去引入新组件。以及全托管的 Pinecone：零运维、按量计费、有多区域 SLA，适合没有运维团队、要快速上线生产的小团队，代价是厂商锁定和用量上去之后的成本。

一张对比表

这五个不是「谁更好」的关系，而是「谁适合你现在」的关系。多数项目用 Chroma 或 Qdrant 起步就够了，不必一上来就上最重的。

最小可用起步

选 Qdrant 自托管起步，Docker 一行起服务：

docker run -d --name qdrant -p 6333:6333 qdrant/qdrant

再建一个 collection 就能用：

from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams

client = QdrantClient(host="localhost", port=6333)
client.create_collection(
    collection_name="docs",
    vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
)

注意 VectorParams 里的 size 要和你用的 embedding 模型维度一致，1536 是常见的一档，换模型要跟着改，否则写入会报维度不符。

常见的坑

第一个坑是拿 benchmark 当唯一依据——向量库的价格和版本一季度一变，引用数字前先复核，别把某次排名当永久结论。第二个坑是以为「开源就是免费」——自托管 Qdrant、Milvus 仍然要算算力、运维和 on-call 成本，许可证不消灭总拥有成本。第三个坑是选了 Chroma 就一路用到客户生产环境，第一波真实负载到来时撞上并发写入和持久化的上限。第四个坑是把选型当一次性决策——正确做法是从最小可行开始、按阶段迁移，而不是一开始就上最重的 Milvus。另一个容易被忽略的点：迁移成本藏在数据里，从 Chroma 迁到 Qdrant 要把向量和元数据重新导一遍，所以阶段没到就别急着把家底押在某个库上。

结论

一句话收尾：Demo 用 Chroma，MVP 用 Qdrant，企业生产用 Milvus，从一开始就明确要混合搜索就用 Weaviate，已经在 PostgreSQL 上就用 pgvector。先想清楚自己在哪个阶段，再决定上哪个，比追着「最快」跑要省心得多。真正贵的从来不是选错库，而是到了要迁移的时候才发现当初选得太轻、或者太重——所以按阶段选，本身就是成本控制。