向量数据库全面对比Milvus、Qdrant 和 Weaviate 的实测数据一、向量检索不是数据库的全部RAG 系统的隐藏瓶颈向量数据库的选型很容易陷入一个误区——只关注 ANN 基准测试的召回率和 QPS。但生产环境的 RAG 系统需要的远不止向量检索元数据过滤、混合搜索向量 关键词、多租户隔离、滚动升级不丢数据这些才是决定系统稳定性的关键。Milvus 是国内社区最活跃的向量数据库设计上对标云原生架构。Qdrant 以 Rust 实现单机极简部署著称。Weaviate 则独树一帜地内置了向量化和混合搜索能力。三者在架构设计、存储引擎、查询模式上的差异最终会反映到运维成本和业务迭代速度上。本文不做概念介绍直接给出三个场景下的实测数据和选型逻辑。二、存算分离 vs 单机极致 vs GraphQL 原生三种架构在十万维度的表现Milvus 的存算分离Proxy、Query Node、Data Node 各自独立扩缩容。当查询量暴增时只扩 Query Node写入量大时只扩 Data Node。这在 10 亿级向量的集群中才有明显的经济收益——否则多出来的 4 个组件本身就是运维负担。Qdrant 的单文件引擎所有数据存储在磁盘上的 Segment 文件中内存和磁盘之间通过 mmap 映射。部署时只需要一个二进制文件没有外部依赖。100 万向量以下单机 Qdrant 的启动速度和资源开销是三者中最优的。Weaviate 的模块化把向量化text2vec、混合搜索hybrid、GraphQL API 都打包进一个引擎。不用额外部署 embedding 服务就能完成向量化检索。但这意味着引擎更新时向量化模块也必须同步更新耦合度高于前两者。三、实测数据三个维度看差距测试环境32C/128G 服务器NVMe SSD100 万条 768 维向量text-embedding-3-smallANN 索引类型均使用 HNSWefConstruction200, M16。3.1 写入性能指标MilvusQdrantWeaviate批量写入吞吐条/秒185003200012500写入时内存峰值28 GB12 GB35 GB索引构建时间100万条4.2 分钟2.8 分钟5.5 分钟Qdrant 的 Rust 实现和紧凑的存储格式在写入上优势明显。Weaviate 的写入时同步构建 HNSW 索引和倒排索引双索引构建拖慢了速度。3.2 查询性能指标MilvusQdrantWeaviateTop-10 召回率0.9920.9910.990纯向量检索 QPSef128420051003800向量 标量过滤 QPS280034004100P99 延迟纯向量8.2ms5.8ms10.4ms纯向量检索 Qdrant 最快。但当加上标量过滤如categorytech AND date2025-01-01Weaviate 的内置倒排索引带来了额外优势——先通过倒排索引缩小候选集再做向量检索减少了无意义的距离计算。3.3 资源消耗与扩展性指标MilvusQdrantWeaviate部署最小内存8 GB256 MB4 GB1000 万向量磁盘占用45 GB38 GB52 GB水平扩展原生支持组件级需 Raft 集群模式原生支持节点级多租户隔离Collection 级Collection 级 Payload 分区Class 级 TenantQdrant 的低资源消耗使其在边缘部署或小型私有化部署中独具优势。一个 Raspberry Pi 5 就能跑起 100 万向量的检索服务这是 Milvus 和 Weaviate 无法做到的。四、每个框架的硬伤Milvus 的运维负担依赖组件太多Etcd元数据、MinIO对象存储、Pulsar/Kafka消息队列。任何一个组件出问题都可能阻塞集群。最小化部署也需要 4 个 Pod对于团队只有 2-3 个人的情况是显著运维压力。版本升级的兼容性需要关注。从 2.2 升级到 2.3 时索引格式的变更导致某些场景下需要重建全部索引。建议在升级前做生产数据快照的完整验证。内存回收策略不够优雅。在某些删除大量数据后的场景下内存不会立即释放需要手动触发 compaction。Qdrant 的扩展天花板Raft 集群模式下所有写操作都要经过 leader 节点集群的写入吞吐受限于单节点性能。数据量超过 1 亿向量时Qdrant 的集群模式不如 Milvus 灵活。Payload 索引标量过滤的维护成本随字段数量线性增长。超过 20 个过滤字段时写入性能可能衰减 40% 以上。权限控制和多租户隔离不如 Milvus 的 RBAC 体系详细。Weaviate 的资源开销JVM 类的内存管理虽然是 Go 实现——启动时预分配大量内存闲置时内存回收不积极。对于按需付费的云环境成本不友好。GraphQL 查询语言虽然表达力强但与团队现有技术栈SQL/REST存在认知差异。排查慢查询时GraphQL 语句的可读性和分析工具链不如 SQL 成熟。内置向量化模块在使用外部 embedding 模型时反而成为消耗。如果团队已有独立的 embedding 服务Weaviate 的模块化架构会多一层不必要的依赖。结论选型对照表场景推荐理由10 亿级向量、需要独立扩缩容Milvus存算分离组件级伸缩100 万向量、单机部署、低资源环境Qdrant256MB 内存即可运行需要内置向量化 混合搜索Weaviate减少外部服务依赖多团队共享、强租户隔离MilvusRBAC Collection 级隔离高写入吞吐、边缘设备QdrantRust 实现写入最快复杂标量过滤 向量搜索Weaviate倒排索引加速过滤实际选型时建议先用业务数据中最典型的那部分10-20 万条在三个候选框架上做场景测试。注意测试的维度不仅是 QPS更要包括索引构建耗时、内存波动趋势、以及一天运行后有没有内存泄漏迹象。数据不会撒谎基础设施不需要漂亮话。