向量数据库到底怎么选？Milvus和Qdrant把我整不会了

几百万条Qdrant完全够用，生产也没问题。HNSW先默认参数跑，m=16、efConstruction=200基本不踩坑。

几百万条其实不算大，Qdrant单机扛生产完全没问题，我们线上跑了一年多挺稳的。Milvus那套etcd+minio+pulsar的架构，小团队维护起来真挺劝退的，除非你们有专门的运维。HNSW调参别太纠结，m从16起步，efConstruction给100到200，先跑通再微调，别一上来就抠参数把自己绕进去。真赶时间的话，Qdrant几行代码就能起服务，先上线再慢慢优化，比纠结选哪个强。

几百万条这个量级，Qdrant单机其实完全扛得住，我去年一个项目400多万条跑生产环境没啥问题，内存给够就行。Milvus确实重，etcd加MinIO那套部署下来运维成本不低，除非你数据量再涨一个数量级或者要分布式。HNSW的M从16起步，efConstruction给到100到200一般够用，主要还得拿自己数据测召回率，别照搬文章里的参数。急着上线的话建议先用Qdrant把链路跑通，后面真扛不住再换也不迟。

几百万条embedding其实还没到必须上分布式向量库的体量，faiss慢多半是你在全量暴力检索，先用IVF或者HNSW索引包一层，性能就能回来一大截。Milvus确实重，etcd、minio、pulsar那一套在单机场景下纯属负担，但它的分布式架构和索引类型丰富度是真优势，数据上千万以后横向扩展省心。Qdrant我拿它跑过千万级，单机docker起一个，内存给够，HNSW查询延迟稳定在十几毫秒，生产用一年多没出过幺蛾子，轻量不代表不能打。选型别光看性能benchmark，先问自己团队有没有运维能力扛Milvus那套依赖，没有的话Qdrant或者干脆pgvector都更务实。HNSW调参别迷信文章，m一般16到32够用，efConstruction设200左右，真正影响召回和延迟的是查询时的ef，这个得拿你自己的数据压测着调。急着上线就用Qdrant，Python客户端友好，跑不动了再迁也不难，向量库迁移成本比你想的低。

几百万条其实不算大，Qdrant单机扛生产完全没问题，我们线上跑了一年多挺稳的。Milvus那套etcd+minio确实重，除非你要上亿级别或者团队已经有k8s运维能力，不然纯属给自己找麻烦。HNSW调参别太纠结，m先从16起步，efConstruction给到100到200，然后拿真实query测recall和延迟，比看文章瞎猜靠谱多了。急着上线就选能最快跑通压测的那个，后面真扛不住再换也不迟，RAG这块迁移成本没你想的那么高。