向量数据库选型纠结死了，Milvus和Qdrant到底怎么选？

几百万的量级真没必要一上来就上Milvus，部署运维够你喝一壶的。我们之前也是FAISS起步，后来直接换pgvector了，反正本来就靠PG，少维护一个组件，过滤查询也好写，HNSW参数默认值先跑着，等性能瓶颈了再调不迟。Qdrant我也试过，轻量是真轻量，但你要的实时写入和复杂过滤它其实也能扛，就是社区案例少点，遇到问题得自己翻源码。反正别被“生态成熟度”吓住，你这数据量PG完全hold住，真到了千万级以上再考虑迁移不晚。

几百万量级真的不用纠结，pgvector足够扛住，而且你们本来就用PG，少维护一个组件省太多事了。之前我们也是FAISS起步，后来直接切pgvector，HNSW参数就调m和ef_search，实测召回率差不到1%。Milvus和Qdrant都试过，前者运维成本确实高，后者API挺好但跟PG的JOIN查询联动起来很别扭。实时写入的话注意下PG的vacuum策略，别让死元组拖垮查询就行。

几百万这个量级pgvector其实挺够用的，你们本来就有PG，运维成本最低，省得再搭一套。不过实时写入频繁的话要留意索引重建和vacuum的开销，最好先压测下。Qdrant我也用过，轻是真轻，过滤查询性能不错，生态确实还差点意思。HNSW的m和ef_construction别照搬默认值，拿你们自己的数据跑个小网格搜一下，一般m=16到32、ef_construction=200左右就够，别太迷信调参。

几百万这个量级其实pgvector完全扛得住，HNSW索引加上去查询延迟也很稳，你们已经在用PG的话省了运维一套新组件的成本。Milvus功能确实全但独立部署那套etcd加MinIO加Pulsar的组合，小团队维护起来真挺累的。Qdrant我用过一段时间，单机性能不错过滤也灵活，就是周边工具和文档确实没Milvus那么厚。HNSW的m和ef_construction别太纠结，先把ef_search调大点保召回，再慢慢压延迟就行。

几百万数据pgvector够用了，你们又有PG运维底子，省心。HNSW的m和ef_construction多试几组，别迷信默认值。