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

巧了，我们团队年初也在这俩里选过，最后用的Qdrant。你那几百万条768维的体量，Qdrant默认配置就能跑得挺稳，HNSW参数基本不用动，真要调也就m和ef_construction两个值。Milvus那套etcd加MinIO确实折腾，我们当时光搭环境就花了一周，后期还得专人看着。不过多租户这块Qdrant得自己用payload或者建多个collection来隔离，没有Milvus那种原生项目级别权限方便。你并发查询大概什么量级？我们压测时Qdrant在32核机器上扛到2000 QPS没问题。

另外提醒一句，RAG场景里除了检索延迟，过滤条件那块也要留意，Qdrant的filter在非索引字段上会慢不少。你现在pgvector崩是崩在延迟上还是内存？如果只是并发问题，先试试加连接池和只读副本，有时候不一定要换库。

我们组之前从pgvector迁到Qdrant，部署确实省心，单机Docker跑起来就稳了，几百万向量加过滤没啥压力。Milvus那套组件太多了，小团队真没精力伺候。索引参数建议花点时间调下HNSW的M和efConstruction，默认值对高召回场景不太够，但别过度优化，先跑通再慢慢调。

多租户的话Qdrant的payload过滤挺直观，Milvus的partition逻辑反而绕。社区这块，Qdrant的issue响应还算快，官方文档例子也够用，没感觉生态是短板。

你最好拿自己数据跑个benchmark，特别是并发查询和延迟分布，别光看官网数字。选型卡两周正常，我们当时也纠结，最后直接压测说话。

说实话你这个量级和场景，pgvector崩是意料之中，768维几百万条根本不适合在关系型数据库里硬扛。Milvus那套etcd加MinIO的架构，我团队之前搭过，光是调优就得专门配个运维，日常监控和故障排查确实折磨人，尤其你们如果就两三个人维护，后期会非常痛苦。Qdrant我这边倒是用了大半年，Rust写的确实省心，单机部署就能扛住千万级向量，而且它内置的过滤机制比Milvus那种要分开配索引的方式直观得多，多租户用payload字段做隔离也很顺手。

不过你担心社区生态，这点我倒觉得不用太焦虑，Qdrant现在文档和示例都挺全，遇到问题GitHub上响应也快，比某些大项目提个issue等一周强。索引参数这事，说实话默认配置在大多数场景够用，但如果你查询模式是那种高并发且带复杂过滤的，建议还是手动调下HNSW的M值和efConstruction，不然召回率会忽高忽低。我们之前就是偷懒用默认，结果线上延迟一波动才发现是索引参数没跟上数据分布。另外提醒一句，多租户如果数据隔离要求严格，Milvus的partition其实比Qdrant的payload过滤更硬核，Qdrant做软隔离没问题，但硬隔离还是得靠多个collection。总之，如果团队没有专职运维，我投Qdrant一票，省下的时间够你多优化几轮RAG链路了。

几百万条768维这个量级，其实两边都能扛住，关键差别在你们的运维人力和并发预期。我们线上用Milvus跑了快一年，数据量比你们大一些，etcd加MinIO这套确实一开始配起来烦，但跑顺之后基本不用怎么管，集群扩容也还算丝滑。Qdrant我也在测试环境玩过，单机性能和内存占用确实讨喜，Rust那套过滤表达式写起来挺舒服，如果你们只要相似度检索加简单过滤，它其实够用。多租户这块得提前想清楚，Milvus有database和partition概念可以隔离，Qdrant靠payload过滤加collection分片，玩法不太一样，最好先按你们的租户规模做个压测。索引参数别偷懒用默认，HNSW的M和efConstruction对召回和内存影响很大，尤其是过滤比例高的时候，默认配置经常不是最优。我的建议是先用Qdrant单机把业务跑通，量再涨或者多租户压力大了再考虑Milvus集群，别一上来就上重装备。

几百万条768维其实不算大，Qdrant单机扛这个量级挺轻松的，多租户用payload过滤或者collection隔离都行。Milvus分布式那套确实重，但你们如果没到上亿规模、没强实时写入需求，没必要硬上。索引参数我建议别全默认，HNSW的m和ef_construct调一下召回差别挺明显，但也不用调太细。真要省心可以先Qdrant跑起来，扛不住再换Milvus也不迟。

几百万条768维其实不算大，但pgvector并发一上来确实容易跪，换专门库是对的。我们生产用Milvus快两年了，稳定性没得说，但你说的etcd加MinIO那套运维确实烦，小团队没专人盯着容易出幺蛾子。Qdrant我测试过，单机性能很猛，过滤也灵活，多租户用payload隔离挺方便的，就是生态文档比Milvus薄一些。索引参数别全默认，HNSW的m和efConstruction调一调召回和延迟差别挺大，建议先压测再定。

几百万条768维这个量级，说实话两个都能扛住，关键还是看你团队愿不愿意背运维包袱。Milvus那套依赖确实重，etcd加MinIO加Pulsar，出问题排查起来链路长，小团队没专职运维会挺痛苦。Qdrant单二进制部署是真的省心，Rust写的性能也稳，我们线上跑了快一年，多租户用payload过滤加collection隔离基本够用。索引参数这块别偷懒，HNSW的m和ef_construct对召回和延迟影响很大，默认配置只能算能用，最好拿自己数据压一遍。pgvector崩大概率是没建对索引或者并发下内存扛不住，换之前也可以先看看是不是配置问题。多租户如果租户数量多，Qdrant的collection开销要留意，Milvus在这方面分区设计更成熟一些。

几百万条768维这个量级，Qdrant单机基本能扛住，过滤和多租户用payload做隔离也够顺手，运维比Milvus那套etcd加MinIO省心不少。Milvus强在分布式和功能全，但你要没专门的运维人力，光调索引和扩缩容就够喝一壶的。索引参数别指望默认配置打天下，HNSW的m和ef_construct还是得按召回率压测着调。建议先拿Qdrant搭个单机集群跑真实并发，扛不住再考虑Milvus分布式，别一上来就上重装备。

我之前也遇到过类似问题，后来换了方案。

写得挺好，建议补充一些性能数据。

Qdrant实际跑过，几百万级别默认参数基本够用，别急着调索引。多租户建议提前试下payload过滤性能，别等上线才发现坑。