向量数据库选Milvus还是Qdrant？各自有什么坑？

我们团队是从Milvus迁到Qdrant的，主要受不了Milvus那套依赖组件，etcd、MinIO、Pulsar全给你安排上，小团队运维直接劝退。Qdrant单机部署太香了，不过你如果数据量到千万级，它的内存占用会有点吓人，得提前规划好集群。另外Milvus的索引构建在动态数据下经常卡住，Qdrant的过滤+向量混合查询倒是快很多，但它的嵌套过滤条件写起来挺绕的，官方文档也不够细，得自己试半天。你们现在主要卡在哪个环节？

我之前也是在这俩之间纠结了好久，最后选了Qdrant。主要感觉Milvus的部署和运维确实有点重，特别是小规模场景下，光调那堆组件就够喝一壶的。不过Milvus的生态和周边工具是真的全，如果团队以后数据量上来，还是值得投入的。

另外想问问你，有没有试过Qdrant那个基于Rust的过滤性能？我这边在搞一些复杂的metadata过滤，感觉它这块比Milvus顺畅不少。但如果你的场景偏全文检索混合那种，可能还是Milvus更合适。

Milvus部署重一些但生态全，Qdrant轻量上手快，小团队无脑选后者，大厂才折腾前者。

说实话这俩我都深度用过，Milvus功能全但部署和运维是真重，小团队光调参数就够喝一壶的，尤其索引构建那会儿内存直接爆表。Qdrant上手快很多，Rust写的性能也稳，但分布式场景下扩展性感觉没Milvus成熟，我们后来数据量上来后不得不加机器扛着。另外提醒一句，别光看benchmark，真实业务里过滤条件多的话，Milvus的标量+向量混合查询优势才体现得出来，Qdrant的payload过滤在超大数据集上会明显变慢。你现在数据量大概什么级别？如果千万级以内我反而推荐先试试Qdrant，省心。

我自己是Milvus重度用户，但说实话一开始真被它的部署复杂度劝退过。如果你只是想做原型验证，Milvus那个分布式架构配置起来挺折腾的，etcd、minio、pulsar一堆组件，本地跑个单机版倒是简单，但一上生产就全是细节。Qdrant我最近在另一个项目里试了，Rust写的确实轻量，docker一拉就能跑，API设计也直观，但社区生态和周边工具明显没Milvus成熟，特别是跟LangChain、LlamaIndex这些框架集成的时候，Milvus的官方文档和示例代码还是更全。

坑的话，Milvus最烦的是索引参数调优，HNSW的M和efConstruction选不好，召回率和延迟能差好几倍，而且数据量大了以后compaction和segment管理经常要手动干预。Qdrant那边我遇到的是过滤条件+向量检索混合查询时，性能衰减比预期快，尤其是带payload过滤的复杂查询，有时候得靠多建几个索引来绕。

我现在的做法是小项目直接Qdrant省心，数据量上了千万级或者需要复杂聚合分析，还是老老实实回Milvus。不过两家迭代都很快，上个月刚看到Milvus在ARM上优化了不少，Qdrant也在加分布式支持，感觉这问题一年后答案可能又不一样了。你们有没有试过用pgvector做平替的？我感觉对于千万级以下的数据量，它反而最省事。

两个都用过，Qdrant上手确实快，但数据量上来之后内存占用有点吓人，我们之前压测到千万级向量直接OOM了几次。Milvus这边集群部署折腾人，不过胜在能扛，而且自带的索引类型多，调优空间大。倒是想问问你们有没有遇到Milvus的compaction导致查询延迟抖动的问题？我们这边隔三差五就抽风一下，官方文档也没说清楚。

我之前也是在这俩之间纠结了好久，最后选了Qdrant。主要原因是Milvus的部署和运维太重了，小团队真的扛不住，光K8s那套就够折腾的。Qdrant用Rust写的，单机性能很能打，而且筛选过滤这块做得比Milvus顺手很多。不过Milvus在超大规模数据集和复杂索引类型上确实更成熟，如果数据量过亿而且有分布式刚需，还是得捏着鼻子用Milvus。