最近RAG圈子里，向量数据库选型这个话题密集升温。7月29日，有博主发文复盘：自己起的Qdrant容器跑了快一个月，CPU占用稳如老狗，但一次查询都没往它那边发，最后直接把它停了。知乎7月30日，《向量数据库，ChromaDB和Qdrant到底怎么选？》发布。知乎8月13日，《向量数据库怎么选：Milvus / pgvector / Qdrant横评》出炉，作者直接晒出了自己的生产翻车经历。知乎
半个月内，两派观点摆开了阵势：一派认为数据涨了就该早换、换大的；另一派认为多数人想多了，不换才是常态。两边都有实测数据，都不是纸上谈兵。我们把这些案例对照着看一遍，试图讲清楚一个问题：Qdrant什么时候值得换，什么时候千万别换。
先对齐定位：Qdrant站在哪个位置
社区对Qdrant的定位判断相当一致：它是Rust写的，这两年涨得猛，算是pgvector和Milvus的中间地带——不像Milvus那么重，也不像pgvector那样被PostgreSQL绑死。知乎它的形态是独立服务：容器拉起来之后，6333端口是REST API，6334端口是gRPC，Web Dashboard、访问控制、快照备份这些Chroma没有的东西，Qdrant都有。知乎
与之对照，Chroma是嵌入式优先的设计，核心API少而精，一共五个，适合不太想折腾向量数据库的人，感觉类似sqlite，pip装完就能跟着Python代码跑。知乎
《ChromaDB和Qdrant到底怎么选》的作者用自己的经历提了个醒：他刚玩RAG时跟风直接上了Qdrant，折腾部署、调参数花了整整两天，本地测试几万条文档根本感受不到生产级优势，换成Chroma后直接省下大量时间聚焦业务。知乎这个案例的意义不在于贬低Qdrant，而是说明：工具的生产级优势，要在匹配的规模上才兑现。
数据量门槛：翻车案例都发生在量级切换时
先看"该换"一派的论据。最有说服力的是一个pgvector翻车案例：横评作者给一家小公司做RAG系统，因为对方用的是PostgreSQL，直接装插件上了pgvector，跑通demo不到一小时；没想到两个月后表内数据涨到2000万，向量检索延迟从最初的30-40ms飙到2s+，最后靠知识库分表才解决。知乎
而他朋友的公司换用Qdrant的理由非常朴素：不想养着一个月薪3万的Milvus运维了。目前表中5000万向量，一次检索只消耗几十到上百毫秒。知乎
B站《RAG向量数据库怎么选》给出的量级划分与这些案例基本吻合：Chroma/PgVector对应小规模、原型、已有PostgreSQL；Qdrant/FAISS对应百万到千万级、性能敏感或自建服务层；Milvus对应上亿数据、高QPS、分布式和多租户。哔哩哔哩
但要提醒一句：选型不能只看"有多少条向量"。同一位横评作者强调，还要看向量维度、topK大小、过滤条件复杂度、召回率要求、并发量、数据更新频率——500万条768维向量和500万条3072维向量，完全不是一个压力级别。知乎
换不换的判据：看信号，别只看数字
这一轮讨论里最值钱的内容，是一个判断口诀：迁移的信号是体验变差，不是数字变大。知乎码哥字节给出的三信号口诀是：触发两个就考虑迁移，只触发一个先优化配置（调HNSW参数、换SSD、加内存）。第一个信号是P99延迟：他用Chroma跑5877个chunks时P99是0.8秒，按其性能曲线推算，5万chunks以内大约1秒出头，10万chunks时开始逼近2秒。注意测的是P99而不是平均值，偶发一次网络抖动不算数。
第二个信号是内存压力。Chroma的HNSW索引全量驻留内存，按384维float32计算，超过50万个chunks时索引就要占约800MB，加上原始数据很容易突破2GB；而Qdrant的量化压缩可以把索引内存压到100MB以内，官方口径最多能省97%的内存。知乎
第三个信号最容易被忽略：多人写入冲突。Chroma默认后端的写入是文件级锁，5个人以上同时用一个库，几乎一定会撞；而且Chroma是嵌入式架构，每个进程跑自己的实例，多人要查同一份数据，天然就得换独立服务。知乎反过来说，只触发一个信号时不必急着迁移——向量检索以随机读为主，把数据挪到SSD上，往往比任何参数调优都立竿见影。
换Qdrant，你得到什么、付出什么
得到的第一样是多租户过滤的顺手程度。企业RAG经常要"在某个租户、某个部门、某类文档里搜"，Qdrant的point + vector + payload模型对这种查询很直观；索引层面，Filterable HNSW、ACORN、查询规划这些机制让过滤和向量检索在图遍历阶段就结合在一起，而不是搜完再过滤。知乎知乎
第二样是轻量。本地部署场景里，有人用n8n + Qdrant + Ollama搭个人知识库，Qdrant只需要200MB内存就能流畅运行，对个人电脑和内网私有化部署都很友好。哔哩哔哩第三样是混合检索能力：借助稀疏向量和服务端原生IDF计算，关键词全文检索和向量语义检索可以在一个库里完成，不用再搭一套全文搜索引擎。知乎
付出的成本也要说清。其一，生态还年轻、中文资料少，横评作者的原话是：连通过大模型查出来的资料都不多，遇到问题能抄的作业有限。知乎其二，Qdrant不内置embedding：Chroma可以直接传文本由它向量化，Qdrant只负责存储和检索向量，向量化链路要自己搭，对新手是多一层认知负担。知乎其三，独立服务意味着健康检查、日志轮转、备份策略、版本升级这些运维细节，从此都是你的活。
一个需要留意的反方声音
还有一则值得记录的对线：7月，Elastic发布基准测试，称DiskBBQ在网络附加存储（NAS）环境下，以相当的召回率实现了最高达Qdrant 7倍的向量搜索吞吐量。知乎注意，这是Elastic自己跑的测试，场景限定在NAS这类存储上，Qdrant方面尚未回应。如果你的检索服务恰好跑在低成本存储上，这个方向值得自己复测一轮，但先别把7倍当结论。
另一边，Chroma也没闲着：1.5版本新增了Rust客户端支持，性能敏感又不想迁库的，这是现成框架内的优化路径。知乎
最后，压成一张行动清单
10万向量以内、单人使用：别换。把精力花在分块策略和检索prompt上，它们才是决定知识库质量的变量。
百万到千万级，或多人使用、多租户过滤：Qdrant是这一档省心的选项，一个容器起服务，维护成本远低于Milvus Cluster。
上亿量级：先问有没有专职运维。没有的话，先把Qdrant的量化压缩和磁盘存储压到极限再决定。
动手切换前，先测三个数：P99延迟、内存占用、写入冲突。触发两个再动，一个先优化。
记住一句话：向量数据库的性能瓶颈跟你存了多少文档没关系，跟你有多少个chunk、每个chunk多少维有关。知乎
你的知识库现在跑在什么方案上，踩过哪些坑？欢迎在评论区对一下账。
