向量数据库选型踩坑，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也不迟。