向量数据库全面对比：Milvus、Qdrant 和 Weaviate 的实测数据

发布时间：2026/7/29 17:08:15

向量数据库的选型很容易陷入一个误区——只关注 ANN 基准测试的召回率和 QPS。但生产环境的 RAG 系统需要的远不止向量检索：元数据过滤、混合搜索（向量 + 关键词）、多租户隔离、滚动升级不丢数据，这些才是决定系统稳定性的关键。

Milvus 是国内社区最活跃的向量数据库，设计上对标云原生架构。Qdrant 以 Rust 实现单机极简部署著称。Weaviate 则独树一帜地内置了向量化和混合搜索能力。三者在架构设计、存储引擎、查询模式上的差异，最终会反映到运维成本和业务迭代速度上。

本文不做概念介绍，直接给出三个场景下的实测数据和选型逻辑。

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 SSD，100 万条 768 维向量（text-embedding-3-small），ANN 索引类型均使用 HNSW（efConstruction=200, M=16）。

指标	Milvus	Qdrant	Weaviate
批量写入吞吐（条/秒）	18500	32000	12500
写入时内存峰值	28 GB	12 GB	35 GB
索引构建时间（100万条）	4.2 分钟	2.8 分钟	5.5 分钟

Qdrant 的 Rust 实现和紧凑的存储格式在写入上优势明显。Weaviate 的写入时同步构建 HNSW 索引和倒排索引，双索引构建拖慢了速度。

指标	Milvus	Qdrant	Weaviate
Top-10 召回率	0.992	0.991	0.990
纯向量检索 QPS（ef=128）	4200	5100	3800
向量 + 标量过滤 QPS	2800	3400	4100
P99 延迟（纯向量）	8.2ms	5.8ms	10.4ms

纯向量检索 Qdrant 最快。但当加上标量过滤（如category=tech AND date>2025-01-01），Weaviate 的内置倒排索引带来了额外优势——先通过倒排索引缩小候选集，再做向量检索，减少了无意义的距离计算。

指标	Milvus	Qdrant	Weaviate
部署最小内存	8 GB	256 MB	4 GB
1000 万向量磁盘占用	45 GB	38 GB	52 GB
水平扩展	原生支持（组件级）	需 Raft 集群模式	原生支持（节点级）
多租户隔离	Collection 级	Collection 级 + Payload 分区	Class 级 + Tenant

Qdrant 的低资源消耗使其在边缘部署或小型私有化部署中独具优势。一个 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 的模块化架构会多一层不必要的依赖。

选型对照表：