Milvus vs Qdrant vs Weaviate：2026 年向量数据库选型实战指南
核心结论先行：这三者没有绝对的优劣。选型的核心不是比较"谁的性能分数高"，而是判断你的数据规模会不会在可预见的未来压垮单机架构，以及你的团队是否愿意为分布式能力支付相应的运维代价。在 1 亿向量规模下，三者的 Recall 差距仅在 0.988–0.991 之间；真正拉开差距的是架构选择带来的运维复杂度、扩展上限和功能侧重点。
一、同一基准下的性能与资源实测
先看硬数据。以下结果来自 2026 年一项在 1 亿向量、1536 维、HNSW 索引统一条件下的公开基准测试：
| 指标 | Qdrant | Milvus | Weaviate |
|---|---|---|---|
| Recall@10 | 0.991（最高） | 0.988 | 0.989 |
| QPS | 4,200 | 4,600 | 5,100（最高） |
| P99 延迟 | 12 ms | 11 ms | 9 ms（最低） |
| 每百万查询成本 | $0.18（最低） | $0.21 | $0.24 |
但如果把规模缩小到 10 万向量，差异会变得更加尖锐，这组数据更能反映中小规模起步阶段的真实体验：
| 指标（10 万向量） | Qdrant | Milvus | Weaviate |
|---|---|---|---|
| 默认召回率 | 99.3% | 94.8%（最低） | 99.3% |
| 中位搜索延迟 | 7.2 ms | 8.6 ms | 4.9 ms |
| 索引峰值内存 | 984 MB | 2,556 MB | ~1,243 MB |
| 启动就绪时间 | 5 秒 | 35 秒 | 6 秒 |
这组数据揭示了一个关键事实：Milvus 的默认配置在中小规模下并不是最优解。它的 AUTOINDEX 在 10 万向量级别给出了三家中最低的默认召回率（94.8%），且索引内存消耗是 Qdrant 的 2.6 倍。Milvus 的设计目标是十亿级分布式场景，在中小规模下需要手动调优才能释放其真实能力，而不是"开箱即用"。
注意：向量数据库的性能高度依赖测试规模、索引类型、硬件配置和召回率目标。上表应关注相对趋势，而非精确数字。
二、架构差异：这才是选型的真正分水岭
三者的架构从根上就不同，直接决定了运维成本和扩展路径。
Milvus：分布式优先，为"大"而生
Milvus 的架构包含 Proxy、QueryCoord、DataCoord、QueryNode、DataNode、IndexNode 等多个微服务角色，依赖 etcd、MinIO、Pulsar 等外部组件，生产环境通常需要 Kubernetes 编排。它的优势是存储计算分离，可以独立扩展查询节点和存储层，支撑十亿级向量。
代价是：一套最小集群也要同时管理多个角色与依赖组件，排障成本比另外两者高一个量级。阿里云文档明确指出，自建 Milvus 集群"需要专业的 Milvus 工程师团队，人力成本高"。
Qdrant：Rust 单体，为"简"与"快"而生
Qdrant 是一个用 Rust 编写的单体进程，底层使用 RocksDB/内存，单个 Docker 容器即可跑起来。它的运维负担显著低于 Milvus：部署简单，单机性能极强，从单机到小集群的扩展相对平滑。
但需要注意：Qdrant 的分布式集群模式比 Milvus 的分布式架构更新，在十亿级规模下 Milvus 仍是更强选择；社区版开源在早期不支持完整的分布式能力，多节点扩展通常需要 Qdrant Cloud 或自行处理。
Weaviate：单机优先，混合搜索是差异点
Weaviate 的架构同样是单机优先，内置倒排索引（BM25）和 HNSW 索引，持久化到对象存储。它的核心差异化不在于分布式规模，而在于将混合搜索（关键词 + 向量）作为一等公民。
如果你的场景需要同时利用 BM25 的精确关键词匹配和向量语义检索，Weaviate 的内置集成程度最高。但在运维复杂度上，它介于 Milvus 和 Qdrant 之间：比 Milvus 简单，但不如 Qdrant 的"单容器即跑"轻量。
三、过滤与混合搜索：细节决定场景适配
Qdrant 的过滤能力是隐藏王牌
Qdrant 引入了 ACORN 机制来处理"高选择性过滤 + 向量搜索"的困境。普通 HNSW 在过滤条件过严时召回率会急剧下降，而 ACORN 通过搜索时跳过被过滤掉的邻居来挽回召回率，代价是延迟增加（约为普通图的 2.1–2.9 倍）。
官方数据表明，在特定策略下 ACORN 能在四类过滤器上保持 99.9%–100% 的召回率。如果你的业务中"先按标签/时间/类别过滤，再做向量相似度"是常态，Qdrant 的过滤感知设计比另外两者更直接。
Weaviate 的混合搜索最"开箱即用"，但关键词臂并不总是最强
Weaviate 原生集成了 BM25，混合搜索在领域语料上比纯向量搜索可提升 12–18% 的召回。但在第三方基准中，Weaviate 的关键词臂得分（0.782）低于部分竞品，意味着它的混合搜索优势更多体现在集成便利性上，而非每一个子模块的绝对性能。
如果你需要"一套系统里同时搞定全文和向量"，Weaviate 是三者中最省事的；如果你对混合搜索的每一个环节都有极致要求，可能需要额外评估。
Milvus 功能覆盖面最广，但需要调优
Milvus 支持 IVF、HNSW、DiskANN 等多种索引，也支持 RRF 混合检索，功能维度上没有明显短板。但它的默认配置在中小规模下召回率偏低，需要团队理解索引参数和查询参数的含义并进行调优。“功能最全"和"开箱即用"在 Milvus 身上是两件事。
四、选型决策框架：按数据规模与团队能力分流
综合以上实测和架构差异，可以用一个清晰的决策树来收敛选择。
第一层判断：你的向量规模会不会在 1–2 年内突破 1 亿，甚至走向十亿级？
- 会，或明确有十亿级规划 → 进入 Milvus 的评估轨道。它的分布式架构建模了大规模场景下的扩展路径，但你需要准备好：专职的 Kubernetes/DB 运维能力，或者接受 Zilliz Cloud 的托管成本。腾讯云架构文章的推荐也是"大型 RAG（亿级）→ Milvus，理由：分布式能力”。
- 不会，规模在千万级到 5000 万以内 → 进入 Qdrant 与 Weaviate 的二选一。在这个量级，单机/小集群架构的 Qdrant 和 Weaviate 完全够用，引入 Milvus 的分布式复杂度属于过度设计。
第二层判断（在 Qdrant 与 Weaviate 之间）：你的检索模式以什么为主？
- 以"带复杂过滤的向量检索"为主，且对尾延迟敏感 → Qdrant。它的 Rust 实现带来了三者中最低的中位延迟（1 亿规模下 P99 12ms，10 万规模下内存占用最低），ACORN 机制让它在"先过滤再搜索"的场景中召回率有专门的保障。甜点区被概括为 <5000 万、过滤密集型负载。
- 混合搜索（BM25 + 向量）是刚需，希望一套系统同时服务关键词和语义检索 → Weaviate。原生 BM25 集成和开箱即用的高召回率（默认 99.3%）让它在这个维度上最省心。但需要接受它的内存消耗通常高于 Qdrant，以及在超大关键词臂性能上并非绝对领先。
一个常被忽略的"第三选项"
如果你已经在用 PostgreSQL，且规模不超过 5000 万，pgvector 的运维成本优势可能压过专用向量库的性能优势。用专用向量引擎意味着新增一套需要专人值守的基础设施；而 pgvector 复用你已有的备份、监控和运维体系，在中小规模下性能完全可接受。
五、最终建议
如果你的数据规模在 5000 万向量以内，且没有强烈的分布式扩展预期，优先从 Qdrant（过滤密集）或 Weaviate（混合搜索密集）中选一个做原型验证。
只有当你确认规模会突破单机/小集群的舒适区，并且团队愿意为分布式能力承担运维成本时，Milvus 才是正确的长期选择。
选型时最重要的判断不是"哪个更快"，而是"我能不能在不引入不可承受的运维负担的前提下，让这套系统在我未来 18 个月的数据量下保持稳定"。
参考项目官网
- Milvus：https://milvus.io
- Qdrant：https://qdrant.tech
- Weaviate：https://weaviate.io
- pgvector：https://github.com/pgvector/pgvector
本文性能数据引用自 2026 年公开基准测试，实际表现受硬件、索引参数和查询模式影响，建议在自身数据上做原型验证后再做最终决策。