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

几百万条用OpenAI embedding的话，其实pgvector+HNSW索引大概率能扛住，前提是你查询并发不高，而且愿意花点时间调索引参数。我之前在类似规模的项目上先上的pgvector，后来发现召回率其实和专门向量库差别不大，瓶颈反而在embedding本身的维度上。Milvus部署确实重，尤其是早期版本，etcd、pulsar那一套光运维就要劝退不少人，但如果你未来铁定上K8s，它的operator和读写分离架构会省心很多。Qdrant单机部署很爽，内存控制也做得好，不过分布式模式下的分片迁移和一致性配置得自己趟坑，文档没Milvus那么细致。我现在的建议是，如果团队没有专门的infra精力，先pgvector跑通业务，等查询延迟或并发真成瓶颈了再迁，迁移时数据导出导入也就半天的事。另外你提到准确率，其实向量库本身不参与这个，影响的是检索策略和距离算法，我测过同样数据在Milvus和Qdrant里用余弦距离，top10结果几乎一致，所以别在这上面纠结。最后提醒下，OpenAI embedding是1536维，内存占用别只看向量数量，算上原始文档和索引开销，单机32G以下还是老实pgvector吧。

几百万条上pgvector真不够看，单机就Qdrant先顶着，后面要K8s再换Milvus也不迟。

说到这个我可太有感触了，去年我们团队也是在这个岔路口纠结了快两周。最后选了Qdrant，主要原因是当时我们数据量也就比你略大一点，单机跑起来内存控制确实比Milvus友好太多，而且Rust写的服务部署起来就是一个二进制文件，配合Docker Compose五分钟就能起一套测试环境。召回准确率这俩其实没本质区别，因为向量索引算法都差不多，关键还是看你embedding模型和距离度量选得对不对，别在数据库层面过度纠结。

不过我得提醒你，Qdrant的分布式方案虽然现在也成熟了，但如果你未来真要上K8s并且数据量会涨到千万级，Milvus的存算分离架构和成熟的监控体系会让你少踩很多坑。我们当时就是贪轻量选了Qdrant，结果半年后数据涨到八百多万条，分片和副本调参全靠自己摸，运维成本反而上去了。另外你提到pgvector，说实话如果你只是做简单RAG而且团队本来就熟Postgres，几百万条数据加个HNSW索引完全能顶住，别被“向量数据库”这个概念忽悠了，很多场景下pgvector的性价比真的很高。

最后想问下你现在的embedding维度是多少？如果超过2000维，Qdrant的内存占用会明显高于Milvus，这点在选型时容易被忽略。还有你们期望的查询延迟是多少，这会影响索引类型的选择，不同索引在召回率和性能上还是有取舍的。

你这数据量其实还没到非上专用向量库不可的地步，pgvector加个HNSW索引扛几百万条没问题，内存占用还比那俩都省。真要选的话，Qdrant单机部署起来确实爽，但K8s迁移时Milvus的operator明显更成熟，我这边生产环境两个都跑过，召回率差距基本可以忽略，主要看你对运维折腾的容忍度。另外提醒一句，OpenAI embedding维度高，Qdrant的过滤性能在小数据集上优势不明显，但到了千万级你会感谢它的二进制量化。

几百万条pgvector真够呛，Milvus部署重但K8s下反而稳，Qdrant单机爽迁移时想哭。

正好我们团队两个都跑过生产，几百万条这量级其实两者召回率没啥肉眼可见差别，关键在资源占用——Milvus那套依赖组件多，单机16G内存跑起来有点紧，Qdrant倒是省心不少。不过你后面要上K8s的话，Milvus的operator反而更成熟，Qdrant得自己折腾点东西。pgvector这种量级也勉强能扛，但查询复杂了延迟会飘，建议还是专门库吧，省得半年后又来一遍迁移。

说实话你这个问题我太有共鸣了，之前做相似项目时也在Milvus和Qdrant之间反复横跳过。如果单看召回准确率，这俩其实没啥本质区别，因为底层都是走向量索引那一套，真正的差异全在工程实现上。Qdrant的Rust写的内存控制确实香，我单机跑过千万级向量，峰值内存比Milvus稳很多，但Milvus胜在生态成熟，尤其你后面要上K8s的话，它的分布式架构和监控组件都是现成的，Qdrant虽然也支持集群但感觉还稚嫩点。我最后选了Milvus，因为运维重归重，但踩坑有文档有社区，Qdrant出问题只能自己啃源码。至于pgvector，我劝你除非数据量真就百万内而且不追求毫秒级，否则别折腾，它做过滤和标量混合查询时性能掉得厉害。另外提个醒，如果未来要上K8s，Milvus的operator一键部署确实省心，但你要预留好存储和资源配额，不然扩节点时候会头大。

说实话你这个量级pgvector还真能再撑一阵，但别指望它能做复杂过滤和动态更新，到时候索引重建够你喝一壶。Milvus部署重是真的，但上了K8s之后用operator管理其实比Qdrant省心，尤其你未来要扩分片的话。Qdrant单机跑起来很爽，内存控制也更好，但它的集群模式我记得对网络要求比较高，小团队运维容易踩坑。召回准确率这俩在暴力检索下没啥区别，主要看你的embedding和距离函数选得对不对。我个人建议先拿Qdrant顶着上线，等真需要分布式了再迁Milvus，反正数据量到了那个级别，迁移成本远小于一开始就折腾重型武器。

几百万条这个量级pgvector其实也能扛，但你要上K8s的话还是早点换专门的向量库省心。Milvus部署重是重，不过它的分片和索引策略在数据涨上去之后确实稳，Qdrant单机很爽但集群版我记得要企业版才有，这点你得确认下。召回率这俩其实都差不多，主要看你的embedding和检索参数调得怎么样，别指望换库能解决准确率问题。我建议你直接Milvus，反正都要容器化，迁移一次到位，别折腾两遍。

说实话几百万条用pgvector真够呛，我这边两千万向量pgvector查询延迟直接爆表，最后还是换了专门的库。Milvus部署确实重，但K8s迁移反而顺滑，官方operator一拉就起来；Qdrant单机爽，集群模式得自己折腾分片，而且内存吃紧的话它的过滤索引比Milvus费不少。召回准确率这俩其实都取决于你的embedding和距离算法，差别不大，主要看运维精力。你要是铁了心后续上K8s，建议直接Milvus起步，省得二次迁移。另外内存这关得提醒，几百万条float向量裸算下来快2GB，加上索引和overhead，单机32GB起步才稳。

说实话你这数据量上pgvector有点悬，几百万条加过滤条件之后延迟会很难看。我用过Milvus和Qdrant，召回率这块两者其实没啥感知差异，主要差在内存和运维，Milvus那套组件堆起来确实头疼，但Qdrant单机模式撑到千万级也没啥问题，而且它支持Rust写的那个存储引擎，内存控制比Milvus好不少。你要是确定以后上K8s，Qdrant的operator比Milvus的省心多了，我去年从docker-compose迁到k8s基本没改配置。不过你既然已经在用OpenAI embedding，建议先测下Qdrant的binary量化，能省一半内存，准确率掉得很少。

这规模pgvector真够呛，Qdrant单机玩起来爽，后面上K8s也方便，别纠结了。

说实话你这个问题我太有共鸣了，之前我们团队也是从numpy硬扛到几百万条才被迫迁移的。Milvus和Qdrant我都在生产环境跑过小半年，最直观的感受是Milvus的召回率确实稳，尤其复杂过滤场景下优势明显，但部署和调参是真的费劲，etcd、minio那一套下来，单机都能给你整出分布式的心累。Qdrant轻量是真轻量，docker一拉就起来，内存占用控制得也好，但如果你后续要做混合检索或者复杂标量过滤，它的灵活性会有点捉襟见肘。单机阶段我反而更推荐Qdrant，因为你现在的规模用Milvus纯属杀鸡用牛刀，运维成本会吃掉你写业务的时间。不过你要是明确未来要上K8s，那Milvus的Operator和生态会更平滑，Qdrant的集群模式虽然也在完善，但生产案例还是少一些。至于pgvector，我劝你别省这个事，几百万条加embedding后，pg的索引维护和查询延迟会让你怀疑人生，除非你的QPS低到可以忽略。最后提个醒，不管选哪个，先拿你的真实数据集跑一下benchmark，别只看官网的recall数字，实际场景里filter和并发会带来很大差异。

这个规模pgvector真够呛，Qdrant单机跑起来挺省心，后面上K8s也有官方operator，别纠结了。

这规模pgvector真别碰，召回率直接拉胯。我生产环境用的qdrant，单机部署一个月没出过幺蛾子，后面上k8s也顺。

几百万条这个量级其实pgvector配合HNSW索引真能扛，先别急着上重武器，我们当时三千万条照样pgvector跑得欢，只是要调好参数。Milvus部署确实折腾，etcd、pulsar那一套够喝一壶的，但上了K8s之后反而稳，Qdrant单机爽，集群版之前遇到过脑裂问题，不过现在好像修了。召回率这块差别真的不大，主要看embedding质量，别在这上面花太多心思。你要是图省心，先pgvector顶半年，真不行再迁，反正数据导出也不难。

其实你这数据量用pgvector真不是不行，几百万条embedding如果只是暴力检索，pgvector配合HNSW索引在单机上跑个几十毫秒也没啥问题，关键是看你后续要不要做过滤、混合检索这些。我前阵子刚把项目从Milvus迁到Qdrant，主要受不了Milvus那套依赖etcd、MinIO的部署，光调参就折腾了两周，Qdrant一个二进制文件起来就能跑，内存占用大概只有Milvus的三分之一。但你要说召回准确率这俩其实没本质区别，都是HNSW算法，差别在索引参数上，Qdrant的默认配置在召回率上稍微保守一点，得自己调ef和m值才能赶上。至于上K8s，我感觉Qdrant的operator做得比Milvus顺手，而且它的分片机制更简单，没有Milvus那种复杂的分布式协调逻辑。不过我得提醒你，Qdrant的过滤查询性能没有Milvus稳，如果后期加上metadata过滤条件特别多，响应时间会抖得比较厉害。要是你团队没专门的运维，我其实更推荐先上Qdrant单机，等数据量真到千万级再考虑迁移，毕竟那会儿K8s和集群能力也摸熟了。

几百万条pgvector真别硬扛，我这边之前同量级直接换Milvus了，部署重但稳，K8s迁移官方文档也全。

单机起步的话Qdrant确实香，但你要上K8s我劝你一步到位，省得后面迁移数据折腾到哭。

几百万条用pgvector真能撑住，但别指望召回率，Qdrant单机跑起来比Milvus省心太多，K8s迁移也顺。

你这数据量上pgvector其实也能凑合，但召回率跟专门优化的向量库还是有差距，尤其过滤场景一多就明显卡顿。我生产环境用的Qdrant，单机部署很省心，内存控制比Milvus好太多，而且它那个Rust写的底层查询速度是真的快。不过你要是确定未来要上K8s，Milvus的生态更成熟，Operator和监控都现成的，Qdrant的分布式版本还得自己折腾分片策略。建议先拿Qdrant跑通业务，真到了扩容瓶颈再迁也不迟，毕竟数据迁移也就几个小时的事。