从 Chroma 换成 Qdrant，我踩了 100 万向量的坑

文章主旨：

选向量库的核心不是比较功能列表，而是将自身场景参数（数据量、查询复杂度、运维条件）套入决策框架，在嵌入式服务（Chroma）与独立服务（Qdrant）之间做出合理选择。

关键要点：

• Chroma 是嵌入式数据库（类似 SQLite），零运维，适合数据量低于100万向量且过滤简单的场景。
• Qdrant 是独立服务（类似 PostgreSQL），支持Raft共识、水平分片、复杂过滤，适合生产环境、数据量超过100万或复杂过滤需求。
• Chroma 超过100万向量后性能明显退化（延迟不稳定），Qdrant 在5000万向量规模下仍稳定。
• 查询过滤复杂度是关键差异：Qdrant 的 Filterable HNSW 可在图遍历时应用位图掩码，同时完成语义搜索与条件过滤，互不影响。
• 作者建议新项目先用 Chroma 快速验证，待数据量和查询复杂度触及阈值后再迁移到 Qdrant，避免提前优化。

内容结构：

1. 决策框架：选向量库不是比功能，而是匹配场景参数（数据量、查询复杂度、运维条件）。
2. 核心对比结论：
   • Chroma 适用于零运维、100万向量以下
   • Qdrant 适用于复杂过滤、高吞吐、生产环境
   • 预算极紧+数据量大可选 Chroma（S3成本低）
3. 作者亲身经验：早期无脑选 Chroma，数据量达200万时检索延迟从50ms飙升至800ms，切换 Qdrant 后回到40ms以内。
4. 代码示例对比：
   • Chroma：pip install 后直接 import，作为 Python 库运行在进程内（嵌入式）；建集合、添加数据、查询均在同一进程完成。
   • Qdrant：需要先启动独立服务（docker），通过 HTTP/gRPC 交互；建集合时必须声明向量维度和距离算法。
   • 实质区别：Chroma 是“住在你家的帮手”，Qdrant 是“隔壁开了间办公室的团队”。
5. 内部查询机制对比：
   • Chroma（推模式）：将查询计划拆成微小切片并行计算，已索引数据用 HNSW，新数据暴力扫描，合并层返回。优势：刚插入数据即可搜索；劣势：超过100万向量时合并层压力大。
   • Qdrant（分段隔离）：数据拆成多个独立段（Segment），写入先记 WAL，查询与后台合并隔离。优势：高吞吐、不卡查询；劣势：需要前期投入。
   • 作者踩坑案例：Flask 服务中 Chroma 读写在同一条线，高峰期 GIL 导致整条链路等待；拆成 Qdrant 独立服务后解决。
6. 性能退化边界：
   • Chroma 软肋：100万向量附近延迟不稳定（20ms~200ms），原因在于 Python/Rust 跨语言通信瓶颈和 GC 抖动。
   • Qdrant 的“大材小用”：若只有5万向量，优势感受不到，反而增加维护成本。
   • 查询过滤：Chroma 先搜再滤或先滤再搜，复杂条件下性能衰减；Qdrant 的 Filterable HNSW 同时处理语义搜索和过滤，互不干扰。
7. 选型决策指南：四个问题（数据量、查询复杂度、运维条件、预算）代入框架得到具体建议：
   • 数据量<100万且过滤简单 → Chroma
   • 数据量<100万且过滤复杂 → Qdrant
   • 数据量>100万 → Qdrant（几乎必选）
   • 预算极紧+数据量超大 → Chroma（S3）
   • Agent/上下文管理 → Chroma
8. 作者最终建议：新项目一律 Chroma 起步快速验证，数据量和查询复杂度真正摸到阈值时再迁 Qdrant，让数据告诉你该换什么。

文章总结：

这是一篇技术选型实战指南，通过架构对比、性能边界和作者亲身踩坑经验，为不同场景下的向量数据库选择提供了清晰的决策框架，倡导“不提前优化，但知道边界在哪”的务实态度。