标题五大向量数据库横评Milvus vs Qdrant vs Chroma vs ES vs Faiss到底怎么选第一部分先泼一盆冷水——性能排名是最没用的选型依据很多横评文章上来就放一张 QPS 排名表Qdrant 第一、Milvus 第二、Chroma 垫底然后得出结论“Qdrant 最好”。这种结论在真实工程里几乎没有参考价值。原因很简单向量数据库的性能表现高度依赖于数据规模、过滤条件的选择性、索引参数ef/M/nprobe、并发模型甚至客户端语言。同一个数据库在不同 benchmark 里排名可以相差好几名。比如在 AIMultiple 的单线程测试中Milvus 排第三但在另一个 100M 规模的测试中Milvus 的 QPS 又高于部分竞品。所以这篇文章不按“谁快谁慢”来组织而是按“你的架构约束和业务场景最适合哪种设计哲学”来拆解。第二部分五款产品的本质差异不在性能在架构Chroma嵌入式原型工具不是数据库Chroma 的定位非常清晰让 Python 开发者在 5 分钟内跑起来。pip install chromadb几行代码就能完成向量存储和查询默认 HNSW 索引与 LangChain/LlamaIndex 深度集成。但它的“上限”和“下限”一样明确。Chroma 底层基于 DuckDB SQLite单节点性能在 10 万条以内非常流畅几十万条开始明显变慢没有横向扩展路径。一旦数据规模超过约 100 万条迁移是必选项。判断标准如果你在写 POC、做本地 RAG demo、或者数据量确定不会超过 10 万条Chroma 是最省时间的选择。除此之外它不该出现在生产架构的讨论里。有个真实案例一个电商推荐系统第一版用了 Chroma数据涨到 5000 万条后查询延迟从 20ms 涨到 800ms紧急迁移到 Milvus 多花了 8 个人周。Milvus为“超大规模”牺牲了运维简洁性Milvus 的架构选择是存算分离 微服务化Proxy、QueryCoord、DataCoord、QueryNode、DataNode 各司其职底层索引文件落在对象存储MinIO/S3上。这种设计带来的能力是真实的十亿级向量、K8s 弹性扩缩容、GPU 加速、多种索引类型HNSW、IVF_FLAT、DiskANN 等。代价同样真实运维复杂度是五款里最高的。你需要理解各个组件的角色、协调对象存储、管理索引构建的调度。Milvus 也有 Standalone 模式用于小规模但这时候它的架构优势发挥不出来运维成本却依然高于 Qdrant 单机。判断标准数据量在亿级以上或者明确需要多业务线共用一个向量集群、且团队有 K8s 运维能力Milvus 是经过验证的选择。如果数据量在千万级以下Milvus 的分布式架构是过度设计。Qdrant用 Rust 重写了“过滤”这件事Qdrant 的核心差异化不在“快”而在过滤检索的执行方式。传统向量数据库的做法是“先做 ANN 检索再对结果做元数据过滤”post-filtering或者“先按条件过滤再在小候选集上做 ANN”pre-filtering。前者在过滤条件严格时会丢失结果后者在候选集过小时精度下降。Qdrant 的做法是把过滤嵌入 HNSW 图遍历过程本身遍历时只走满足 payload 条件的节点而不是事后裁剪结果。这个设计的实际收益在过滤条件高选择性的场景下最明显当过滤后的候选集只占总量的 5% 时Qdrant 的延迟仍能保持基线水平而“先检索后过滤”方案的延迟会因为候选集不足而恶化。加上 Rust 实现带来的低延迟和 Binary Quantization 的 32 倍内存压缩Qdrant 在单机性能和过滤体验的平衡上是目前最成熟的。判断标准如果你的 RAG 场景需要频繁按租户 ID、时间范围、类别标签等条件过滤且数据量在千万到亿级之间Qdrant 是首选。它的单机起步成本极低一个二进制文件集群模式比 Milvus 轻得多。Elasticsearch赢在“你已经有了 ES”ES 做向量检索的技术路线是在已有的倒排索引和全文检索体系上叠加 kNN。它支持近似 kNNHNSW和精确 kNN暴力扫描混合搜索BM25 向量是它的天然强项。但 ES 的向量能力始终是“扩展功能”而非核心设计目标。资源消耗高JVM 堆内存 向量索引额外占用在纯向量检索场景下性能不如专用向量库P99 延迟和吞吐量在百万级以上规模时劣势明显。判断标准“已经有 ES 集群”是选 ES 做向量检索的最强理由。如果你的应用本来就在用 ES 做全文搜索、日志分析叠加向量检索可以避免引入新组件运维团队也不需要学习新系统。但如果是从零开始、以向量检索为核心需求ES 不是最优解。Faiss不是数据库是索引库Faiss 经常出现在“向量数据库”横评里但它本质上是一个C 相似度搜索库提供 Flat、IVF、HNSW、PQ 等多种索引实现GPU 加速能力突出十亿级数据下延迟可以做到极低。问题在于Faiss没有持久化、没有 API 服务、没有元数据过滤、没有分布式协调。你需要自己封装服务层、自己实现数据写入和索引重建、自己处理高可用。它更适合作为嵌入层加速引擎被其他系统调用——事实上 Milvus 的底层索引就构建在 Faiss/HNSWlib 之上。判断标准追求极致性能的离线实验、需要 GPU 加速的嵌入计算密集型场景或者作为已有系统的底层检索组件。把它当“数据库”来用等于自己造一个 Milvus。第三部分一张表看清五款产品的硬约束ChromaMilvusQdrantElasticsearchFaiss本质嵌入式向量库分布式向量数据库独立向量数据库搜索与分析引擎向量索引库架构单进程DuckDBSQLite存算分离微服务Rust 单体/轻集群分布式搜索集群本地库数据上限~10万-100万十亿级十亿级百万-千万级向量场景十亿级单机/GPU过滤检索基础元数据过滤标量过滤过滤内嵌 HNSW最强强倒排向量需自行实现混合搜索✗✓✓✓BM25向量✗分布式✗✓✓Raft轻量✓✗运维复杂度极低高中低中高极高需自建服务核心代价规模天花板运维负担超大规模集群经验少于 Milvus向量为扩展功能资源效率低一切都要自己做数据来源综合了多份横评与基准测试。第四部分选型决策树直接抄作业不要记性能数字记判断顺序第一问你在做 POC 还是上生产POC/本地 demo →Chroma。5 分钟能跑通的事不值得花 5 小时部署 Milvus。上生产 → 进入第二问。第二问你的数据量级和过滤需求是什么千万级以下 过滤条件简单 →Qdrant 单机。一个二进制文件起步性能好运维几乎为零。千万到亿级 过滤条件频繁且选择性高多租户、时间范围、标签 →Qdrant。过滤内嵌 HNSW 的设计在这个区间优势最大。亿级以上 多业务线共用 团队有 K8s 能力 →Milvus。存算分离和弹性扩缩容是为此设计的。第三问你已经有 ES 集群吗是且向量检索不是核心瓶颈 →ES。不引入新组件的工程价值往往大于性能表上几毫秒的差距。否 → 回到第二问。第四问特殊情况你是否需要把检索嵌入到自己的 C 服务里或者需要 GPU 加速的极致性能是 →Faiss但请清醒地认识到你是在“用一个库造一个数据库”服务层、持久化、过滤、高可用都需要自己写。第五部分比选型更重要的事——检索质量不取决于数据库有一个事实经常被横评文章忽略RAG 系统的最终效果向量数据库只贡献了其中一环。分块策略chunk_size 过大切断语义、过小丢失上下文、是否引入 Rerank、是否做混合检索、Embedding 模型是否匹配业务语言这些因素对召回质量的影响远大于“选 Milvus 还是 Qdrant”。一个用 Qdrant 精心设计的 Rerank 流水线的系统完全可以击败一个用 Milvus 但粗暴分块、不做重排的系统。选型的意义是避免在规模和运维上踩坑而不是“选对数据库就等于RAG做得好”。第六部分一句话结论Chroma原型阶段的默认选项生产阶段的债务。Milvus超大规模的正确工具前提是你养得起它的运维复杂度。Qdrant单机到中等集群区间里过滤检索和运维成本的平衡点做得最好的一款。Elasticsearch已有 ES 生态时的“顺便选项”从零开始则以向量为核心需求时不选它。Faiss嵌入系统的加速引擎不是数据库。你目前在用哪款向量数据库数据量到了什么量级有没有遇到过滤后召回“缩水”的问题评论区聊聊我会挑典型场景单独写优化方案。