三个主流、三个场景，三选一
Vector Database 在 2026 年已经从”要不要上”变成”上哪个”。本篇把 Qdrant / Milvus / Weaviate 三个主流开源向量库放一起对比，从架构、性能、运维成本三个角度给个清晰选择。
它们的定位速览
| 数据库 | 语言/底层 | 强项 | 弱项 |
|---|---|---|---|
| Qdrant | Rust，单二进制 | 性能 + 部署简单 | 云生态弱 |
| Milvus | Go + C++，分布式 | 10亿+ 向量规模 | 运维复杂 |
| Weaviate | Go，模块化 | 多模态原生（向量+对象+LLM） | 大集群性能不如 Milvus |
性能对比（基于 ANN-Benchmarks 数据）
| 场景 | Qdrant | Milvus | Weaviate |
|---|---|---|---|
| 1M 向量 / 768 维 / recall@10 ≥0.95 | ~6ms | ~7ms | ~9ms |
| 10M 向量 | ~14ms | ~10ms | ~18ms |
| 100M+ 向量 | 需要分片优化 | 原生分布式快 | 需要企业版支持 |
1M 级 RAG 业务三家差不多；过 10M 之后 Milvus 开始领先；100M 量级基本是 Milvus 主场。
运维复杂度对比
Qdrant
- 单二进制部署，几分钟跑起来；
- 支持嵌入式模式（直接进 Python 进程），适合原型；
- 生产集群靠 cluster + sharding，文档清晰；
- 运维上手 1-2 天。
Milvus
- 基于 etcd + MinIO + Pulsar（默认 Standalone 用 Badger），分布式部署组件多；
- 运维资源占用大，资源不够容易踩坑；
- 运维上手 1-2 周。
Weaviate
- 单进程启动简化部署；
- 集群化配置比 Milvus 简单但比 Qdrant 复杂；
- 运维上手 3-7 天。
多模态与混合检索能力
Weaviate 的隐藏王牌：模块化
Weaviate 把向量、对象属性、LLM 拼装成一个一体化 schema，能直接做：
- 文本 + 图像混合向量；
- 按元数据过滤（”过去一个月 / 客户端类型 = 移动”）后再做向量召回；
- 原生支持 GraphQL API，业务侧上手快。
如果你的业务”非结构化文本 + 结构化字段 + 全文 + 向量”四件套都要，Weaviate 是这三家里最自然的。
Qdrant 的过滤王者
Qdrant 的 payload 过滤+向量召回组合速度是三家最快的，复杂条件 pre-filter + ANN 索引优化非常成熟。`should_match` 之类的复合条件也很自然。
Milvus 的标量 + 向量融合
Milvus 在传统标量字段（数值、字符串、JSON）做精确匹配后向量搜索的能力稳定，加上 Attribute Index 之后一些混合查询效率明显。
2026 选型结论
选 Qdrant，如果
- 数据规模在 1M-10M 之间；
- 运维资源有限（一两个工程师兼着管）；
- 需要快速上线，迭代频率高；
- 看重 response time 的稳定性。
选 Milvus，如果
- 数据规模是 100M+ 长期规划；
- 有专门的基础设施团队；
- 与 Spark / Trino 等大数据栈集成重；
- 公司对国产开源友好（Milvus 出自 Zilliz，国内生态成熟）。
选 Weaviate，如果
- 业务多模态（图像 + 文本 + 元数据）；
- 想要一个 DB 替代传统 ES + 向量库双写的复杂度；
- 前端 GraphQL 直接接比较友好；
- 愿意接受中等规模集群的运维负担。
最后提醒
三家都有云托管（Qdrant Cloud / Zilliz Cloud / Weaviate Cloud Services），不想自己运维直接用托管版本。但注意 egress 费用——大向量库最容易超预算的就是这一块。
选型前先算清楚：你的 QPS × embedding 维度 × 单向量字节数 × 总流量 = 月度带宽。这是真正决定 TCO 的数字。
