用 ChromaDB 搭 RAG 或者个人知识库跑了几个月的人，大概率都经历过这个时刻：检索开始不太对劲，内存悄悄往上爬，上网一搜，十有八九有人告诉你"Chroma 就是个玩具，生产环境得换 Qdrant、Milvus"。
那么，现在到底是不是换数据库的时候？
今年七八月，社区里向量数据库选型的讨论格外密集，几篇跑了一年半载项目的实测帖都交出了数据。把这些记录对照着看完之后，结论和大多数对比文章相反：ChromaDB 踩过的坑，一大半其实不是 ChromaDB 的。
一、先分清两类坑，再谈诊断
把社区实测记录捋一遍，ChromaDB 用户遇到的问题基本分两类。
第一类是 ChromaDB 自己埋的坑：默认 embedding 模型、版本升级的接口变化、metadata 限制、SQLite 写锁、全内存索引。换引擎确实能躲开。
第二类是换任何向量数据库都会踩的坑：embedding 模型和语言不匹配、分块策略不当、换模型要重建库、检索链路参数配错。这些换成 Milvus 照样会中招，而且实测数据表明它们的权重大得多——有人根本没动向量库，只是升级了 embedding 模型、调整了检索策略，系统能力就实打实上去了。知乎
有个比喻很到位：向量数据库是仓库，embedding 模型是分拣工，分块策略是打包规则，prompt 是调度员。仓库再高级，分拣工手速慢、打包规则不合理，出库效率一样上不去。所以动手之前先确认一件事：问题真的是 ChromaDB 的吗？
二、ChromaDB 自己埋的坑，一共五个
坑一：默认 embedding 模型对中文基本不能用（最高频）
ChromaDB 的设计很"贴心"：pip install 完，把文本丢进去就自动向量化。问题在于默认的 all-MiniLM-L6-v2 是纯英文模型，对中文语义几乎无能为力，"检索结果总差点意思"的症状大多从这里开始。知乎更麻烦的是只改模型名不够：一份本地 RAG 实测（Ollama + bge-m3）里要同时改三处——换 embedding 函数、建 collection 时把 embedding_function 设为 None 防止 Chroma 内部继续用默认模型、写入和查询前预计算向量，少一处，新旧数据就躺在不同的向量空间里。
自查方式：知识库是中文、你又从没显式设置过 embedding 函数，别怀疑，先修这个。
坑二：版本迭代快，接口变化不打招呼
看 Chroma 的 GitHub 发布页：1.5.9 在今年 5 月 5 日释出，从 1.5.0 到 1.5.9 三个月发了九个正式版，8 月下旬 1.5.10 的 dev 构建还在持续推送。GitHub更新快不是坏事，但用户的痛点是接口变化不打招呼。有项目升级到 1.5.9 后异常类型变了，集合不存在时抛的异常不再被 ValueError 捕获，初始化直接崩，得把 except 扩成 (ValueError, chromadb.errors.NotFoundError) 才接得住。知乎这类隐性约束文档里看不到，只有跑起来才碰得到。
建议：在 requirements 里锁定版本，升级前先跑回归，生产环境别随手点 upgrade。
坑三：metadata 不支持嵌套 dict
想往 metadata 里塞结构化溯源信息的话注意：Chroma 的 metadata 只接受 str、int、float、bool 这类扁平值，嵌套 dict 写入前必须先用 str() 转平，读出来再自己解析回去。
坑四：SQLite 写锁，多人场景的第一堵墙
Chroma 的默认后端是 SQLite，写入是文件级锁。知乎一个人用毫无感觉，两个人偶尔撞上，五个人以上几乎必撞——症状就是"有人在写数据，你的查询卡着不动"。这不是调参能解决的，是架构边界，多人共享检索必须上服务端方案。
坑五：HNSW 索引全驻内存
Chroma 默认的 HNSW 索引整个放在内存里。算一笔账：一个 384 维 float32 向量约 1.5KB，知识库到 50 万 chunks 这个量级，光索引就要吃掉约 800MB 内存，加上原始数据和中间计算结果很容易突破 2GB，8GB 的机器一旦触发 swap，延迟就是几十秒起步。知乎
不过这个坑有缓冲区。有人拿个人知识库实测：240 篇文章、5877 个 chunks，查询延迟没超过 1 秒，内存不到 200MB，完全健康。社区实测给出的分档很明确：10 万 chunks 以内放心用，10 万到 30 万之间盯紧内存，超过 30 万再开始考虑 Qdrant 这类支持磁盘索引的方案。知乎
三、越用越慢？先按这个顺序排查
检索质量下降，别急着怪数据库，按顺序查：
先查 embedding：语言匹配吗？是不是换了模型忘了重建旧向量？换 embedding 模型等于整个库要重建，维度对不上时向量库直接抛 InvalidArgumentError: dimension mismatch，已插入的向量和新向量无法共存。这是很多人低估的隐性成本。
再查分块：chunk 太长会淹没召回，太短会丢上下文。有实测案例里，一段文本恰好卡在 chunk_size 边界，把整条管线卡死，这类边界问题单测永远测不出来，只有拿真实文档跑全量才暴露。
再查链路参数：有用户接查询改写时把一个接口参数名写错，query= 写成了 question=，改写模块静默失败，混合检索的融合通过率只剩 60%，改回参数名后立刻回到 100%。知乎静默失败比报错可怕——系统看起来在跑，功能实际是废的。
最后才看数据库本身，而且先调参再动库：HNSW 的 M 决定每个节点的连接数，efConstruction 控制建索引时的搜索宽度，efSearch 控制查询时的搜索宽度，三个参数就是延迟和召回之间的调节旋钮。实测曲线的结论很直白：拉高 M 和 efSearch 对召回的提升非常明显，但对搜索时间的影响同样显著；efConstruction 也要给到合理值，M 和 efSearch 偏低时靠它才能把召回拉回来。Pinecone另外，efConstruction 和 efSearch 都不影响索引内存，真正决定索引大小的只有 M。
顺手把数据挪到 SSD，这是成本最低、见效最快的一步。
四、什么时候真该迁移？看三个信号
社区说法里最认同的一句：迁移的信号是体验变差，不是数字变大。知乎向量数量到了某个整数关口，不等于"该迁移了"。三个信号里至少触发两个，才值得认真算迁移成本：
信号一：P99 延迟持续上涨。在检索函数前后加计时，多跑几次取 P99，不要只看平均值——一次网络抖动就能把平均值骗上去。5 万 chunks 以内 P99 就到秒级，先排除前面的 embedding 和网络问题。
信号二：内存占用失控。Chroma 吃掉机器一半内存、swap 随时触发的时候，延迟就不是 2 秒，是 20 秒。
信号三：写入竞争常态化。SQLite 锁冲突变成日常，多人协作的需求已经排上日程。
只触发一个的话，先做便宜的事：换 SSD、调 HNSW 参数、加内存。Chroma 1.5 还新增了 Rust 客户端支持，对性能敏感的可以把查询部分用 Rust 重写，Python 通过 PyO3 调用。知乎这属于在 Chroma 的框架里优化，成本比换引擎低一个数量级不止。
五、真要迁移，迁去哪？
2026 年下半年的答案和去年不太一样：
业务已经跑在 PostgreSQL 上：优先 pgvector，少维护一套系统；
真的有百万级、多人并发：Qdrant，Rust 写的，量化压缩能把向量从 float32 压到 uint8，官方数据说最多能省 97% 的内存，SQ 量化的召回损失通常在 1%~3%，大多数场景无感。知乎
到了十亿级：才谈得上 Milvus，否则运维成本就先把自己压垮；
云上已经有托管数据库：看下面的新变量。
新变量：2026 年 8 月 11 日，亚马逊云科技公布了一项重磅更新，老牌无服务器数据库 Amazon DynamoDB 正式解锁原生向量搜索功能。知乎最高支持 4096 维向量，全程不用管基础设施，按实际检索用量付费——做 AI 应用必须额外搭一套向量数据库的时代，正在过去。腾讯云这个月也发布了 AI 原生向量数据库。知乎
更大的趋势是：2026 年越来越多的传统数据库开始内置向量能力，PostgreSQL 有 pgvector 生态，Oracle、SQL Server 都在跟进。知乎向量检索正在从独立产品变成基础能力。所以如果你现在没有真的撞墙，不必急着迁移——未来的迁移选项只会更多，不会更少。
最后提个醒：厂商 benchmark 别全信，真实业务的查询模式和数据分布跟测试集完全是两回事，拿自己的数据跑一周 POC 再下结论。自己的测试集，比看一百篇对比文章都值钱。
