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

说实话你这个量级我建议先别纠结Milvus还是Qdrant，几百万条用pgvector加上正确的索引（比如HNSW）完全能扛，我们团队之前从numpy切到pgvector只花了半天，召回率几乎没损失，运维成本几乎为零。真要上专门的向量库，Qdrant单机部署确实舒服，内存控制比Milvus好太多，但你要考虑未来上K8s的话，Milvus的官方Operator其实更成熟，Qdrant的集群模式相对年轻，踩坑概率高一些。至于准确率，纯embedding检索场景下两者差距可以忽略，真正的差异在过滤条件和向量+标量混合查询时，Milvus的标量索引和过滤性能明显更强，但如果你只是简单topk检索，Qdrant的响应速度和资源占用会更香。另外提醒一句，别忽略索引参数调优，同样的HNSW配置下，efConstruction和M值对内存的影响可能比换数据库还大。我现在的建议是，如果团队没人专职运维，先pgvector跑通业务，等QPS真上来了或者需要复杂过滤了，再评估迁到Qdrant单机，最后才考虑Milvus集群，这样每一步都有明确理由而不是拍脑袋。

说实话你这数据量上pgvector真够呛，几百万条加OpenAI embedding，索引构建和查询延迟会很难看。Milvus部署重是重，但K8s迁移和扩缩容反而更省心，Qdrant单机玩得爽，上集群后配置和调优得自己踩不少坑。召回准确率俩其实差不多，主要看你的检索策略和embedding质量，内存占用Qdrant更友好，Milvus默认配置比较吃资源。建议直接上Qdrant起步，等真遇到瓶颈再迁Milvus也不迟，反正都是标准接口。

你这量级pgvector真够了，别折腾，等真到千万级再换不迟。

几百万条pgvector真能凑合，但别等索引膨胀了再哭，Milvus部署虽然重，K8s迁移反而省心。

几百万条pgvector还真能打，先上这个省心，等真扛不住再迁Qdrant也不迟，K8s上它比Milvus轻太多了。

说实话这个量级pgvector真够用了，我们之前也是几百万条embedding，pgvector加个HNSW索引查起来毫秒级，省掉一套基础设施的运维成本。Milvus和Qdrant我都试过，召回率这种纯向量检索场景下差别真不大，关键看你要不要标量过滤和复杂索引，Milvus那套分布式组件在单机上纯属浪费资源。如果你铁了心要上专业向量库，Qdrant的K8s迁移反而更省心，文档和API设计都简洁，Milvus迁移过去得调一堆配置。内存这块Qdrant默认走mmap，同样的数据量比Milvus省不少，但你要做好将来分片时的数据重平衡，那才是真麻烦。

说实话你这量级上pgvector+pgvector的ivfflat索引大概率能扛，真没必要一上来就上重武器。我之前在类似规模的项目里先用pgvector跑通业务，后面压力大了再迁到qdrant，迁移成本没想象中高。milvus部署确实重，单机玩起来etcd、minio那一套就够折腾，但如果你确定要上k8s且团队有运维精力，它的分片和索引管理确实更省心。qdrant单机性能很能打，内存占用比milvus小不少，召回率这东西其实两者差不太多，主要看你embedding模型和检索策略。我自己的经验是，先拿qdrant快速上线，真到了千万级再考虑milvus也不迟。

几百万条这个量级，pgvector 真不一定扛得住，尤其你还要考虑后面上 K8s。我自己用 Qdrant 跑过千万级，内存控制比想象中好，单机起个 docker 就能跑，迁移到 K8s 也有官方 helm chart，挺顺的。Milvus 功能确实全，但那个部署复杂度对小团队来说有点劝退，除非你确实需要它的分布式能力。召回率这块两者差距没想象中大，关键还是看你的索引参数怎么调。

几百万条文档这个量级，pgvector其实真不一定扛不住，但得看你的QPS和延迟要求。如果只是离线批量检索或者并发不高，pgvector配HNSW索引完全能打，还省得你维护两套存储。不过一旦你要频繁更新向量、做多路召回或者上过滤条件组合，专用向量库的优势就出来了。Milvus功能确实全，但它的重主要重在一堆依赖组件上，单机跑个standalone其实没那么夸张，只是资源占用比Qdrant高不少。Qdrant我实际用下来内存控制挺舒服的，Rust写的，单机性能也够，上K8s有官方operator，迁移不算麻烦。召回准确率这块两者差距没想象中大，更多取决于你的索引参数调优和embedding质量，别指望换个库就能质变。真要纠结的话，建议先用Qdrant跑起来，它API清爽、本地docker一条命令的事，等真遇到瓶颈再考虑Milvus也不迟。

几百万条用pgvector其实也扛得住，但得看你的QPS和延迟要求，单机pgvector跑个几十万到百万级没啥问题，再往上就有点吃力了。Milvus确实重，但你要是计划上K8s，它的operator生态反而更成熟，Qdrant的k8s部署也不算麻烦，只是分片和扩缩容策略得自己多操心。召回率这俩差别不大，主要还是看索引参数调优，内存占用Qdrant明显更省，尤其开了量化之后。如果团队运维人手有限、又不想被分布式组件绑死，我倾向Qdrant起步，真到瓶颈再换也不算太痛。

几百万条用pgvector其实挺吃力的，尤其你还要上K8s，单机postgres扩展性会先卡住。我这边Qdrant跑过千万级，内存控制比Milvus舒服不少，rust写的确实省资源，但分布式那块确实没Milvus成熟。Milvus要是单机standalone还行，集群模式那套etcd+pulsar+kafka的依赖真够喝一壶。你这规模我建议Qdrant先顶着，真到亿级再考虑迁移，它K8s operator也够用了。

几百万条文档用pgvector其实也能扛，但得看你的QPS和延迟要求，单机pgvector跑几百万向量检索大概几十到几百毫秒，如果并发不高完全够用。Milvus和Qdrant召回率这块不用太纠结，都是HNSW系，调好参数差距不大，主要差在运维和生态。Qdrant单机确实省心，上K8s也有官方helm chart，Milvus那套etcd+minio+pulsar的组合小团队运维起来是真的累。如果现在单机、未来才上K8s，Qdrant迁移会更平滑，Milvus的分布式架构你得从一开始就按集群思路规划。

几百万条单机pgvector就够跑，真要上K8s再换Milvus也不迟，Qdrant扩展性其实没你想的那么弱。