向量数据库选型求助，Milvus和Qdrant到底怎么选？

几十万条Qdrant单机完全够用，千万级再考虑分布式，Milvus那套依赖确实劝退小团队。

几十万文档Qdrant单机够用了，千万级再考虑集群吧，Milvus那套依赖确实劝退不少人。

几十万文档Qdrant单机完全够用，千万级再考虑集群吧，Milvus那套依赖确实劝退小团队。

几十万文档这个量级其实两家都绰绰有余，Milvus那套etcd加MinIO的依赖确实劝退不少人，单机测试阶段Qdrant的体验好太多了，一个二进制文件跑起来就能用。不过选型得看你们团队运维能力，如果本来就是k8s体系，Milvus的分布式架构后面扩展会省心些。千万级数据Qdrant单机不是扛不住，主要看内存，HNSW索引全放内存的话得算算你的向量维度和量化策略，bge-m3是1024维，一千万条原始向量光存储就40G左右，加上索引开销内存压力不小。我自己的经验是Qdrant配好标量量化或者二值量化能大幅降内存，但召回率会掉一些，得测。Milvus在千万级以上确实更成熟，分片和水平扩展是原生设计，代价就是组件多、调优复杂。其实可以先用Qdrant快速验证业务，真到瓶颈再迁，它俩的API抽象层做得都还行，迁移成本没想象中高。

几十万文档这个量级其实两边都能轻松拿下，真正要纠结的是你团队愿不愿意维护那套分布式组件。我去年有个项目跟你的情况差不多，一开始图省事上了Qdrant单机，跑得确实舒服，docker一个容器就起来了，备份也直接快照文件拷走就行。但后来数据涨到七八百万向量、并发查询一多，单机内存就开始吃紧，HNSW索引全塞内存里，扩容只能垂直加配置，成本曲线挺陡的。Milvus这边虽然etcd加MinIO加一堆组件看着吓人，但它是存算分离的，querynode和indexnode能各自扩，千万级往上走基本是它的舒适区，代价就是运维复杂度实打实摆在那。所以我一般建议是：如果团队没有专职运维、数据量短期看不到千万，Qdrant省心；要是预期一年内就破千万还要求高可用，早点上Milvus别折腾迁移。另外你top-k才10-20，其实可以关注下两边过滤和混合检索的性能差异，bge-m3配标量过滤的场景Qdrant的payload索引做得挺顺手。