向量数据库选型指南：Qdrant、Milvus、pgvector 的架构差异与场景决策（2026）

先说结论：没有最好的向量数据库，只有最匹配场景的

RAG 知识库的落地链路里，向量数据库是最容易被低估、也最容易被选错的组件。选轻了（pgvector 扛不住亿级）要重做，选重了（一上来就分布式 Milvus）运维成本吞掉整个项目预算。

本文拆解四款主流向量数据库的架构差异，从五个维度给一张选型决策表，外加三个我们见过的高频坑。

---

1. 四款主流向量数据库的架构差异

Qdrant —— 上手最快、运维最简

Rust 实现，单机 Docker 几分钟即可启动。优势在过滤性能：支持按 payload（metadata）做精确过滤后再向量检索，过滤逻辑在索引层实现而不是在查询层做后过滤。适合业务场景中 metadata 过滤开销量大的场景（按客户/日期/权限过滤）。

特性	Qdrant
语言	Rust
部署	单机 Docker / K8s / 云托管
索引	HNSW 为主，支持量化
过滤	内置 payload 索引，过滤性能强悍
一致性	强一致性 / 可调
适用规模	单机千万级，分布式亿级（需 K8s）

Milvus —— 分布式、亿级扩展

Go/Java 实现，架构分层（Query Node / Index Node / Data Node），K8s 原生。优势在规模：支持百亿级向量检索，通过 Knowhere 引擎集成多种索引（HNSW、IVF_FLAT、IVF_PQ、DiskANN 等）。劣势是运维复杂度高——组件多、调参面广，小规模场景用它是杀鸡用牛刀。

特性	Milvus
语言	Go / Java
部署	K8s 原生（推荐）/ Docker Compose
索引	HNSW / IVF / DiskANN / 多种量化
过滤	标量倒排索引，性能中等
一致性	可调（强/有界/会话/最终）
适用规模	十亿级以上，分布式天然

pgvector —— 零新组件、复用 PostgreSQL

PostgreSQL 的向量扩展，把向量检索能力直接嵌入数据库。优势在零新增运维——已有 PG 的场景直接启用，不需要额外组件。适合数据量小（千万级以下）、已有 PG 基建、且对实时一致性和事务支持有要求的场景。

特性	pgvector
语言	C（PG 扩展）
部署	作为 PG 插件运行
索引	IVFFlat / HNSW（pgvector 0.7+）
过滤	依赖 PG 的 WHERE 条件，后过滤模式
一致性	PostgreSQL 事务保证
适用规模	千万级以下，已有 PG 场景

Elasticsearch —— 全文+向量一体

如果你的搜索架构已经跑在 ES 上，且需要同时做全文检索和向量检索，ES 8.x 的向量检索能力（kNN search + HNSW 索引）可以让你一套系统搞定混合检索，避免额外的组件维护。

特性	Elasticsearch
语言	Java
部署	单机/集群，已有 ES 基建
索引	HNSW（dense_vector 字段）
过滤	已有 ES 的 query DSL，灵活但复杂
一致性	近实时（NRT）
适用规模	已有 ES 场景，亿级可扩展

---

2. 选型决策表：五个维度打勾

决策维度	Qdrant	Milvus	pgvector	Elasticsearch
① 数据量千万级以下	✅ 推荐	❌ 过重	✅ 推荐	✅ 可接受
② 数据量亿级以上	❌ 需 K8s	✅ 推荐	❌	❌ 需集群
③ 已有 PostgreSQL 基建	—	—	✅ 推荐	—
④ 已有 ES 基建	—	—	—	✅ 推荐
⑤ 需要强事务/实时一致性	❌ 可调	❌ 可调	✅ 强一致	❌ NRT
⑥ 运维团队有限、要轻量	✅ 推荐	❌ 组件多	✅ 推荐	❌ 需 ES 运维
⑦ metadata 过滤量大	✅ 推荐	❌ 中等	❌ 后过滤	❌ 复杂
⑧ 大规模分布式	❌ 需 K8s	✅ 推荐	❌ PG 扩展	❌ 需集群

我们的默认路径：Demo/验证阶段用 pgvector（零成本启动）→ 生产后根据数据量和场景迁移到 Qdrant（单机够用）或 Milvus（亿级走分布式）。ES 只在已有 ES 基建设施时考虑。

---

3. 三个高频坑

坑一：索引选错

HNSW 和 IVF 的区别在实践中被严重低估。选错索引的直接后果是：要么查询太慢（用户等不了），要么索引太大（内存不够）。

场景	推荐索引	原因
在线检索、写少读多	HNSW	查询快（毫秒级），索引构建慢但可接受
批量写入、离线检索	IVF	构建快，查询稍慢但可调 nprobe 参数
资源受限（内存小）	IVF + PQ 量化	量化压缩向量，内存可降 4-8 倍
海量数据（亿级+）	DiskANN	磁盘索引，内存只存图结构

坑二：metadata filter 性能没考虑

向量检索的本质是”先找相似的，再过滤”。如果过滤条件太严格（如”只看 2026 年 + 客户 A + 类型 B”），传统做法是先向量检索 Top-K，再在结果集上做后过滤——如果过滤条件排除了大量结果，Top-K 里可能一条都不剩，召回率直接归零。

Qdrant 的 payload 索引在索引层做过滤，避免了这个问题。如果用的是 pgvector 或 ES 做后过滤，要把 Top-K 设得足够大（建议 10× 预期返回数），否则过滤后结果集空的风险很高。

坑三：embedding 维度选错

768 维是当前 balance 最好的选择（bge-m3、text-embedding-3-small 等主流模型都是 768 维）。1024 维以上（如 text-embedding-3-large 的 3072 维）召回率提升有限（约 2-5%），但内存和查询时间翻倍。小规模场景（百万级以下）用 384 维（如 all-MiniLM-L6-v2）足够了，内存占用仅为 768 维的一半。

---

4. 选型之后：效果评估不能忘

向量数据库选好了，不代表检索效果就好了。选型只解决”存得住、查得快”，检索质量取决于 embedding 模型、切分策略、元数据设计和混合检索配合。这些我们已经在 RAG 落地指南里详细拆解了：从评测集建设到混合检索调优，再到检索质量评估指标。

延伸阅读：

• AI Agent 记忆系统设计实战 — 向量库是长期记忆的存储层：记忆该存什么、怎么检索、怎么遗忘
• 企业私有知识库 RAG 落地实战 — 本文的姊妹篇：切分策略、混合检索、评估闭环
• AI 客服落地实战：为什么你的智能客服总是翻车 — 客服场景知识库落地：意图分流、混合检索与人工兜底设计
• AI 项目上线后怎么评估：从 Demo 指标到业务指标的度量体系 — 检索质量评估的 Recall@K、MRR 指标与评测集搭建
• AI 应用的可观测性设计 — RAG 系统的线上检索质量监控
• 模型部署测算器 — 按模型/量化/上下文/并发精确算硬件预算

向量数据库选型只是 RAG 落地的一个环节，但选错了代价极高——不是性能问题，而是项目启动后才发现选错了，回头的成本远超选型时多花几天调研的代价。我们团队做 RAG 知识库和 AI 工程补位服务时，选型阶段的评估流程是标准交付物之一：根据数据规模、场景特征和运维能力给出推荐方案，并在 PoC 阶段验证选型是否合理。

如果你正在评估 RAG 知识库的向量数据库选型，欢迎带着场景来聊。我们做 AI 工程补位与决策层服务：RAG 知识库、Agent 编排、私有化推理部署，以及技术路线评估与选型评审——不做什么都能做的承诺，只做我们擅长的领域。