向量数据库到底该怎么选？Milvus和Qdrant上手哪个更合适？

几十万条这个量级其实挺尴尬的，pgvector慢不一定纯是数据量问题，大概率是索引参数没调好或者硬件瓶颈，不过换专用库也确实能省心。Milvus部署确实重，但你要是用它的托管版（Zilliz）或者K8s上装个Milvus Operator，日常维护其实还好，就是得花时间理解它的segment和index那套概念，不然出问题排查起来想骂人。Qdrant那边我反而觉得单机版性能很够用，而且它那个payload索引做得是真舒服，标量过滤走的是独立索引，不像Milvus早期版本还得靠filtered search硬扫，现在新版也优化了但调参经验还是得积累。混合查询这块，如果你过滤条件特别多且复杂，Qdrant的filter语法写起来更直观，Milvus的布尔表达式稍微绕一点但能力更强，得看你实际查询模式。我的建议是别一上来就追求高可用，先用Qdrant单机Docker跑起来，数据量真到百万级再考虑迁移或者加集群，反正向量库迁移写脚本抽数据也不算太痛。另外提醒一句，RAG项目瓶颈经常不在向量库而在embedding和rerank那层，别本末倒置把优化火力全怼在存储上。

几十万数据Qdrant完全够用，过滤查询也丝滑，维护比Milvus省心多了。

几十万文档这个量级其实两个都能扛，关键还是看你团队有没有人愿意折腾运维。Milvus功能确实全，但它的组件多，etcd、MinIO、Pulsar这些一堆依赖，单机版玩玩还行，真上生产没个懂K8s的人会挺痛苦。Qdrant我用过一段时间，单二进制部署是真的省心，Rust写的性能也不差，几十万到几百万这个区间完全够用，别被"轻量"两个字吓到。过滤这块Qdrant的payload filter做得挺顺手，标量字段建索引后混合查询响应很稳，Milvus的表达式过滤也行但配置起来更绕一些。维护成本上Qdrant明显低一档，快照备份、集群扩展都相对简单，Milvus的运维文档虽然全但坑也不少。我的建议是起步阶段直接上Qdrant，等真到了千万级再考虑换，迁移成本没想象中那么高，别一上来就把自己搞死在部署上。

几十万文档量其实两个都能扛，关键还是看你团队有没有人愿意折腾运维。Milvus功能确实全，但你要是用standalone还好，集群版那套etcd、pulsar、minio的组合，没点k8s底子真容易踩坑，我见过不少团队光调部署就耗了一两周。Qdrant单机部署是真的省心，一个二进制文件跑起来就能用，过滤这块它的payload索引做得挺顺，按时间戳或user_id筛基本是原生支持，混合查询写起来比Milvus的expression顺手一些。不过数据量真涨到千万级、还要多副本高可用的时候，Qdrant的分布式还在演进，心里得有个预期。如果现在只是起步、又想快速验证，我倾向先用Qdrant把链路跑通，等真到瓶颈再迁也不迟，向量库迁移成本没想象中那么高。倒是pgvector慢这事，先确认下是不是索引没建对或者没走HNSW，有时候不是数据库的锅。

几十万文档这个量级其实两个都能扛，关键还是看你团队的运维底子。Milvus功能确实全，但那一堆组件（etcd、MinIO、Pulsar）堆起来，起步阶段真容易把自己绕进去，我见过不少人光调依赖就劝退了。Qdrant单机二进制跑起来是真的省心，Docker一条命令的事，RAG早期用它迭代速度会快很多。你担心的数据量问题，几十万到几百万这个区间Qdrant其实没太大压力，真正扛不住一般是上千万以后再说分片的事。混合查询这块Qdrant的payload filter做得挺顺手，按时间或user_id过滤基本是原生支持，写起来比Milvus的表达式舒服一些。我的建议是先用Qdrant把业务跑通，等真到了瓶颈再考虑迁移，别一开始就为了想象中的规模把自己绑死在重运维上。