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

pgvector真香，少维护一套系统，几百万量级完全扛得住，先上线再说。

pgvector别犹豫，几百万量级够用，少维护一套系统省太多心，HNSW先抄官方参数再调。

几百万条这个量级其实pgvector完全够用，尤其是你们本来就有PostgreSQL，少维护一个组件对生产环境省心太多了。我去年做过类似项目，用的pgvector加HNSW，实时写入和过滤查询都没问题，就是注意索引构建的时候内存要留够，不然rebuild会卡死。Milvus我也试过，功能确实全，但光那套依赖（etcd、MinIO、pulsar）就够运维喝一壶的，小团队真不建议碰。Qdrant我朋友在用，说Rust写的性能确实好，但生态确实浅，遇到问题连个参考都难找，你们如果团队没人熟悉Rust栈，踩坑成本会很高。HNSW参数别太纠结，我一般先按M=16、efConstruction=200跑，然后拿真实query调efSearch，效果基本就出来了，别一开始就追求完美，先让系统跑起来再慢慢优化。另外提醒一句，如果未来数据量会涨到几千万，pgvector可能就要分片了，到时候再迁移成本也不小，所以你们得预估一下半年后的增长曲线再拍板。

pgvector真不是省事选项，几百万量级加实时写入，postgres的vacuum和wal迟早让你头疼。我们当时就是从pgvector迁到qdrant的，部署轻确实是优势，但过滤查询一复杂，性能跟milvus差距就出来了。你如果团队有运维能力，milvus的分布式和索引管理后期省心太多。HNSW参数别纠结，先固定M=16，efConstruction调200，线上efSearch再根据延迟慢慢试，比看教程管用。

说实话你这量级pgvector真够了，我们之前从FAISS迁到pgvector就加了个索引的事，几百万向量加个HNSW也就几十G内存，省掉一套运维成本太香了。Milvus除非你要上亿或者要复杂的标量过滤+向量混合查询，不然真没必要上那套K8s全家桶。Qdrant单机版确实轻，但生产环境要分布式还得自己折腾，团队没专人维护的话后期挺痛苦的。HNSW参数别迷信啥最优配置，先按默认跑通，然后重点调efConstruction和M，其他参数影响真没你想的大。

说实话你这量级pgvector真够了，别被Milvus的分布式吓到，我们上线前也纠结半天，最后发现单机pgvector配个SSD扛几百万向量完全没问题，还省了运维成本。HNSW参数别迷信网上那些默认值，efConstruction调到200左右，M设16，然后拿你真实数据跑几轮召回率测试比啥都强。Qdrant我也试过，轻量是真轻量，但文档和社区反馈确实比Milvus薄一些，生产环境出问题时候挺挠头。要是你们团队本来就熟PG，直接上pgvector最快落地，以后真到千万级再考虑迁移也不迟。

我们团队最后选了pgvector，几百万条数据完全够用，少维护一套系统省心多了，HNSW参数先抄官方默认再调。

pgvector配PostgreSQL的过滤查询太香了，但实时写入多了记得开HNSW的ef_search调优，不然召回率会掉。

pgvector够用就别折腾，几百万量级它真不虚，先上线再说。

我们之前就是被Milvus运维坑惨了，换回pgvector香得很。

几百万量级真别折腾pgvector，性能差距明显，直接上Qdrant吧，部署轻量够用了。

pgvector真没那么不堪，你们本来就用PG的话直接上最省事，几百万条数据加个HNSW索引完全扛得住，实时写入也不用额外维护一套集群。Milvus和Qdrant我都试过，前者光K8s那套部署就够折腾两周，后者文档和周边工具确实还差点意思。过滤查询的话pgvector可以用GIN索引配合，性能不比专用库差多少，关键是不用改架构。HNSW参数别迷信什么最优组合，先efConstruction=200，M=16跑起来，然后根据召回率调efSearch就行，别一开始就纠结完美参数。

我们之前也卡在这三个选项里，最后选了pgvector。如果你PostgreSQL用得熟，真别小看它，几百万量级加HNSW完全扛得住，还能直接用SQL做过滤，省掉一套运维。Milvus确实重，光那堆组件就够喝一壶的，小团队慎入。Qdrant轻是轻，但文档和社区问答深度还是差点意思，遇到怪问题容易卡住。HNSW参数别死磕，先按官方默认跑，等数据量上来再调M和ef_construction，多数场景根本不用动。

pgvector先顶着，几百万量级够用，等真扛不住了再换Milvus也不迟，别一上来就上重器。

我们之前也是你这纠结，最后用Qdrant跑的，部署省心，过滤查询也够使，生态没那么差。

pgvector省心多了，几百万条真不用折腾，HNSW参数先抄官方默认再调。

我们团队去年从FAISS迁到Qdrant，几百万向量这个量级完全够用，部署和运维省心太多，过滤查询性能也稳。Milvus功能强但光搭集群就劝退，小团队真没必要。pgvector我们试过，写入一上来锁问题就明显了，当主库用迟早拖垮业务。HNSW参数别死磕，先efConstruction=200，efSearch=64跑通再调，你那数据量m=16就够了，更多是看召回率能不能接受。

pgvector真没那么神，几百万条加过滤查询性能会明显下滑，尤其并发一上来就吃力。我们之前就是从pgvector迁到Qdrant的，部署轻量这点在迭代期太香了，HNSW参数用默认值再调ef构建和search就够用。Milvus我同事踩过坑，etcd那些组件运维确实烦，除非你们有专门infra团队，不然别轻易碰。你既然已经用FAISS，上手Qdrant的API几乎是平迁，先跑通再考虑扩展性吧。

pgvector真没那么玄乎，你们既然已经在用PostgreSQL，直接上pgvector是最省落地成本的，几百万条数据配合HNSW索引完全扛得住，实时写入也没啥压力，就是过滤查询得注意联合索引的写法，不然容易走错执行计划。Milvus那套分布式部署确实重，如果团队没有专门的infra运维，光调K8s和对象存储就够喝一壶的，但它的标量过滤和动态schema确实比pgvector灵活，尤其你们后续要做复杂条件组合查询的话。Qdrant轻量是真轻量，Rust写的性能也猛，不过生态确实薄，遇到问题能搜到的案例少，而且它的过滤机制和Milvus一样依赖payload索引，写不好照样慢。我个人建议先拿pgvector跑通业务闭环，等真遇到性能瓶颈或者查询模式变复杂再迁移到专用向量库，反正数据导出也不难。HNSW参数别看教程瞎调，M设16够用，efConstruction按数据量平方根试，efSearch线上用动态调，多跑几轮召回率对比再定。另外提醒一句，几百万条如果只是短文本embedding，pgvector用halfvec类型能省一半内存，这招很多人不知道。

pgvector够用就别折腾，几百万量级上生产完全扛得住，省下的运维时间够你调半年HNSW了。