向量数据库：选型而非“首选”——Qdrant、Milvus、pgvector、Weaviate 企业级对比

很多团队在做 RAG 或语义检索时，第一反应是：

“哪家向量数据库是第一名？”

这个问题本身就不太对。
在企业场景里，向量数据库几乎没有“全场通吃”的首选，只有“和你当前阶段最匹配”的方案。

这篇文章会详细拆解四类主流方案：

• Qdrant
• Milvus
• pgvector
• Weaviate

并且不只讲“功能点”，而是聚焦企业真正会遇到的决策问题：

• 数据规模怎么增长？
• 并发和多租户要求有多高？
• 你是“语义检索为主”，还是“关键词 + 语义”双检索？
• 你们团队的数据库与运维能力在哪个区间？
• 你们能接受增加一个新中间件吗？

一、先统一一个共识：向量数据库不是“替代一切”的系统

向量库的核心目标很明确：

高效存储向量，并支持相似性检索与过滤。

但在真实业务里，它通常只是检索链路的一部分。你还需要：

• 文本分块策略
• Embedding 模型治理
• 重排（rerank）策略
• 权限隔离与审计
• 观测与容量规划

也就是说，向量库选型是“系统工程”的一环，不是全部。

二、企业选型先看这 6 个维度

在对比具体产品前，先用一套统一维度看问题。否则会陷入“参数对参数”的局部最优。

1) 数据规模与增长曲线

• 你当前是百万级还是亿级向量？
• 3~6 个月后是否会翻倍？
• 是否需要弹性扩容？

2) 检索模式

• 仅向量相似度检索？
• 是否需要关键词检索（BM25）？
• 是否需要混合检索（vector + keyword）？

3) 过滤与业务约束

• 是否有复杂 metadata 过滤？
• 是否有租户、部门、权限、时间窗等约束？
• 过滤命中率在高并发时是否稳定？

4) 一致性与事务需求

• 是否强依赖事务与 JOIN？
• 是否需要和现有业务表强耦合查询？
• 是否已有成熟 PostgreSQL 体系？

5) 多租户与隔离策略

• 是否 SaaS 平台化部署？
• 租户隔离是逻辑隔离还是强隔离？
• 是否需要不同租户独立扩缩容？

6) 团队能力与运维预算

• 团队偏应用开发还是平台工程？
• 能否接受维护新集群？
• 是否优先“少组件、快上线”？

这 6 个维度比“哪家 benchmark 更高”更决定成败。

三、四类主流方案逐一拆解

1) Qdrant：轻量、上手快、过滤能力强

一句话定位

适合中小规模知识库和快速验证，尤其是希望低运维成本起步的团队。

关键能力（官方信息）

• Qdrant 文档明确提到可通过 Docker 快速启动，开发测试门槛低。
• Qdrant 支持把 JSON payload 附在向量上，并进行丰富过滤。
• Qdrant 支持 Java/Python/JS/Rust/Go/.NET 等多语言 SDK（含 Java）。
• Qdrant 既可单节点，也支持分布式部署（官方文档给出集群建议与副本策略）。

为什么它常被认为“轻量”

很多团队说 Qdrant “轻量”，本质是两个工程体验：

1. 单机或小规模环境可以很快跑起来
2. 过滤能力和检索能力能较快满足第一阶段业务

典型适用场景

• 中小规模知识库（内部文档问答、客服知识检索）
• 需要快速 PoC 的 Java/Python 团队
• 暂时不想上复杂分布式架构、优先快交付

边界与注意事项

• 若进入高并发、多租户、超大规模阶段，需要认真做分片/副本/容量规划
• 生产建议至少按官方分布式建议规划节点和副本，而不是长期单节点

2) Milvus：分布式与大规模能力优先的平台型选择

一句话定位

适合大规模、高并发、多租户、平台级项目。

关键能力（官方信息）

• Milvus 官方文档强调分布式架构，组件可独立扩展，适配大数据和高负载。
• 文档明确给出存算分离/解耦思路（Storage/Computing Disaggregation）。
• 支持多租户策略（数据库、集合、分区、分区键等层级）。
• 支持全文检索（BM25）并可与稠密向量检索组合（混合检索）。

为什么平台团队偏爱它

当你面对的是平台级负载，重点不是“能不能搜”，而是：

• 是否能独立扩读扩写
• 是否能支撑多租户治理
• 是否能在复杂流量下保持稳定

Milvus 的架构设计就是为这类问题准备的。

典型适用场景

• 亿级以上向量规模
• SaaS 场景下多租户隔离
• 高并发检索平台
• 需要语义 + 关键词混合检索能力的平台

边界与注意事项

• 架构能力强通常意味着运维复杂度也更高
• 需要更成熟的平台工程能力（K8s、容量与成本治理、可观测性）

3) pgvector：PostgreSQL 体系内的“最小增量方案”

一句话定位

适合已经深度使用 PostgreSQL，希望统一数据栈、减少新组件的团队。

关键能力（官方信息）

• pgvector 官方 README 的核心定位是“把向量和业务数据放在同一个 Postgres 里”。
• 支持 ACID、PITR（时间点恢复）、JOIN 等 Postgres 原生能力。
• 支持精确检索与近似检索，常见索引类型包括 HNSW 与 IVFFlat。
• 官方文档明确提醒：近似索引下过滤是“索引扫描后过滤”，并提供 iterative index scan 来改善结果不足问题。

它最大的价值

不是“向量性能极致”，而是：

数据统一、事务一致、组织成本低。

你可以在一个系统里完成：

• 业务数据管理
• 向量存储
• SQL 查询与事务控制

对很多传统后端团队，这比引入新中间件更现实。

典型适用场景

• 已有成熟 PG 体系（备份、容灾、监控、DBA 流程齐全）
• 检索规模中等，且业务查询强依赖 SQL/事务/JOIN
• 组织上不希望再维护一个独立向量集群

边界与注意事项

• 当向量检索成为超高吞吐核心链路时，需评估 PG 集群压力与成本
• 近似索引 + 复杂过滤要重点验证召回和延迟（尤其是高过滤选择性场景）

4) Weaviate：混合检索与检索 API 体验优先

一句话定位

适合“关键词 + 语义”双检索的搜索类产品，以及偏 GraphQL 查询体验的团队。

关键能力（官方信息）

• Weaviate 提供 GraphQL 与 gRPC 查询接口，文档对 GraphQL 搜索链路支持很完整。
• 官方文档定义了 Hybrid Search（向量检索 + BM25F 融合）并支持权重调节与过滤。
• Weaviate 的模块体系支持向量化集成，可在导入时自动向量化，并支持 nearText/nearImage 等检索。

为什么它在“搜索产品化”里常见

很多搜索产品不仅要“语义相关”，还要“关键词命中可解释”。
Weaviate 的 hybrid 思路天然贴近这类需求。

典型适用场景

• 站内搜索、文档搜索、内容发现等搜索产品
• 需要关键词与语义同时兼顾
• 希望在查询层使用 GraphQL 风格组织检索逻辑

边界与注意事项

• 模块配置和向量化策略要尽早定好，避免后期改造成本高
• 对团队来说，GraphQL 与模块化配置有学习曲线

四、企业场景横向对比表

维度	Qdrant	Milvus	pgvector	Weaviate
核心定位	轻量起步、过滤友好	分布式平台级向量库	PG 内统一向量能力	混合检索与 GraphQL 友好
部署复杂度	低到中	中到高	低（基于现有 PG）	中
扩展能力	单机到分布式	强分布式、存算解耦	随 PG 架构扩展	多节点可扩展
过滤能力	强（payload 过滤）	强	可用，但需结合索引策略调优	强（可与 hybrid 结合）
混合检索	可实现（生态方案）	官方支持 BM25 + dense	需自行组合 SQL/检索策略	官方 Hybrid Search 明确
事务 / JOIN	非主要优势	非主要优势	强（Postgres 原生）	非主要优势
多租户	可做（需架构设计）	官方多租户策略完整	依赖 PG 逻辑隔离方案	支持多租户配置
最匹配团队	追求快速上线的小中团队	平台工程成熟的大团队	PG 深度用户团队	搜索产品与 API 驱动团队

五、怎么选：一个可执行决策流程

如果你希望快速做决策，可以按下面顺序：

1. 先看组织约束
   如果你们已强绑定 PostgreSQL 且事务/JOIN 非常关键，优先评估 pgvector。

2. 再看规模与并发目标
   如果目标是平台级多租户高并发，优先评估 Milvus。

3. 再看交付速度与运维能力
   如果要快速上线、低运维起步，优先评估 Qdrant。

4. 最后看检索产品形态
   如果你要做关键词 + 语义双检索且偏 GraphQL 查询体验，优先评估 Weaviate。

六、别跳过 PoC：两周选型验证模板

很多团队选型失败不是因为工具差，而是 PoC 方式错了。
建议用 2 周做一个标准化 PoC。

第 1 周：功能和正确性

• 数据集：真实业务语料（不要只用公开 demo 数据）
• 检索任务：至少覆盖 3 类查询（精准词、同义表达、长尾问题）
• 验证指标：Recall@K、MRR、Top-K 命中质量
• 过滤验证：权限/租户/时间范围过滤是否稳定

第 2 周：性能与运维

• 压测指标：P95/P99 延迟、QPS、写入吞吐
• 扩展验证：增加数据量后性能曲线是否线性恶化
• 故障验证：节点重启、索引重建、备份恢复
• 成本验证：资源占用、集群复杂度、日常运维工时

最终评分建议

你可以按下面权重打分（示例）：

• 检索质量：35%
• 性能与稳定性：30%
• 运维复杂度：20%
• 开发效率：15%

这样选出的结果，通常比“听口碑”稳定得多。

七、常见误区

误区 1：只看 ANN 性能，不看过滤

企业检索里，过滤往往决定结果是否可用。
忽略过滤能力，线上会很痛。

误区 2：只做语义检索，不做关键词通道

很多场景（法规条款、型号、错误码）关键词命中非常关键。
混合检索常常比纯语义更稳。

误区 3：把“单机跑通”当成“生产可用”

PoC 成功只是第一步。生产要看：

• 故障恢复
• 扩容路径
• 观测与告警
• 成本可控

误区 4：低估组织迁移成本

技术上能做，不等于组织上能长期维护。
中间件数量、团队技能结构、值班能力都是真成本。

八、结论：没有“最强”，只有“最合适”

把这四类方案压缩成一句话：

• Qdrant：低门槛、快交付、过滤友好
• Milvus：分布式与平台化能力优先
• pgvector：PostgreSQL 体系内最小增量
• Weaviate：混合检索与 GraphQL 体验突出

如果你还在纠结，可以先用这个“保守且有效”的策略：

• 短期验证速度优先：Qdrant / pgvector
• 中长期平台能力优先：Milvus
• 搜索产品体验优先：Weaviate

选型正确的标志不是“参数最好看”，而是：

3 个月后你还能稳定迭代，而不是被架构反噬。

---

参考资料（截至 2026-04-21）

• Qdrant 安装文档：https://qdrant.tech/documentation/installation/

• Qdrant 过滤文档：https://qdrant.tech/documentation/search/filtering/

• Qdrant 分布式部署：https://qdrant.tech/documentation/operations/distributed_deployment/

• Qdrant SDK 列表：https://qdrant.tech/documentation/interfaces/

• Qdrant GitHub：https://github.com/qdrant/qdrant

• Milvus Overview：https://milvus.io/docs/overview.md

• Milvus Main Components：https://milvus.io/docs/main_components.md

• Milvus 存算分离：https://blog.milvus.io/docs/four_layers.md

• Milvus Full Text Search：https://milvus.io/docs/full-text-search.md

• Milvus 多租户：https://milvus.io/docs/multi_tenancy.md

• pgvector README：https://github.com/pgvector/pgvector

• Weaviate GraphQL API：https://docs.weaviate.io/weaviate/api/graphql

• Weaviate Hybrid Search：https://docs.weaviate.io/weaviate/search/hybrid

• Weaviate Modules 配置：https://docs.weaviate.io/weaviate/configuration/modules