向量数据库选型：pgvector vs Qdrant vs Milvus 实测思路
做 RAG / 语义搜索，逃不开"选哪个向量库"。本文不讲跑分榜单，讲选型逻辑：按数据规模、延迟、运维成本、混合检索四个维度，把 pgvector / Qdrant / Milvus / Chroma / Pinecone 放到真实场景里对比，给出"什么时候选谁"的明确建议。
本文要点
- 主题聚焦：大模型、RAG
- 适合人群：独立开发者、全栈工程师、AI 应用开发者
- 核心价值：快速理解背景、实践路径、常见误区和工程建议
做 RAG 的人，十个有九个在"用哪个向量数据库"上纠结过。市面上的横评文章大多罗列一堆 benchmark 跑分，看完更糊涂——因为脱离你的场景谈跑分，没意义。这篇不讲谁最快，讲怎么按你的场景选。
一、先问自己三个问题
选型前，先回答这三件事，答案直接砍掉一半候选：
- 数据规模量级？ 1 万条、100 万条、还是 1 亿条？这决定了能不能用轻量方案。
- 谁运维？ 你愿意自己搭/管一套，还是只想调 API？这决定了自建 vs 托管。
- 要不要混合检索（向量 + 关键词）？ 生产级 RAG 几乎都要。这把"只支持纯向量"的工具排除。
带着这三问看下面。
二、五个主流选项的定位
| 向量库 | 形态 | 甜区 | 短板 |
|---|---|---|---|
| pgvector | PostgreSQL 扩展 | 已有 PG、中小规模、要和业务数据一起查 | 超大规模（千万级以上）召回延迟和索引构建偏弱 |
| Qdrant | 独立服务（Rust） | 中大规模、低延迟、过滤强 | 多了一个服务要运维 |
| Milvus | 分布式（Go/C++） | 海量（亿级）、高吞吐、可分布式 | 运维复杂、资源占用大 |
| Chroma | 嵌入式 | 原型、本地、小项目 | 规模/性能天花板低，不适合生产高负载 |
| Pinecone | 全托管 SaaS | 不想运维、要弹性、企业级 | 贵、数据出境/合规、供应商锁定 |
注意它们不是互斥的——很多团队是"开发用 Chroma/pgvector，生产上 Qdrant"。
三、按场景给结论
场景 A：个人项目 / 内部工具 / 数据 < 100 万
→ pgvector。如果你已经在用 PostgreSQL，别犹豫。一个扩展 CREATE EXTENSION vector 就有向量检索，还能和业务表 JOIN（"只在我自己写的、未发布的笔记里做语义搜索"这种过滤，pgvector 一条 SQL 搞定，纯向量库要折腾 metadata 过滤）。
100 万条以内、召回延迟几十毫秒，pgvector 完全够用。混合检索用 PG 自带的全文检索 + RRF 融合，零额外组件。
场景 B：中等规模（百万–千万）、要低延迟和强过滤
→ Qdrant。Rust 写的，延迟稳、内存占用友好，payload 过滤（按 metadata 筛选再向量检索）是强项——这恰好是生产 RAG 最常用的模式。单机扛千万级轻松，集群也有。API 顺手，Docker 一行起。
场景 C：海量（亿级）、高写入、要分布式
→ Milvus。当你真的到了亿级向量、或者写入吞吐高到单机扛不住，Milvus 的分布式架构是正确选择。代价是部署运维重（etcd/MinIO/依赖一堆），小团队吃不消。不到这个量别上——杀鸡用牛刀，运维成本远超收益。
场景 D：不想运维、要弹性、预算够
→ Pinecone（或同类托管向量服务）。调 API 就行，弹性扩容、不用管索引重建。适合企业里"快速上线、不想养基础设施"的团队。注意：贵（按 pod/用量计费），数据出境合规要确认，且锁定供应商。
场景 E：原型 / 本地实验
→ Chroma 或干脆 SQLite + sqlite-vec。几行代码起来，不用起服务。只在原型阶段用，上了规模/生产就迁走。
四、被忽视的选型维度：混合检索的支持度
生产 RAG 几乎都需要向量 + 关键词混合检索（纯向量召回精确串不行）。各库对它的支持差异很大：
- pgvector：配 PG 全文检索，原生融合（同一库，一条 SQL）。
- Qdrant：支持稀疏向量（sparse vectors），可在同一库做 dense + sparse。
- Milvus：支持混合检索。
- Chroma / Pinecone：混合检索支持相对弱或需外挂。
如果你确定要混合检索（应该要），这一项就能砍掉几个候选。
五、一个务实的迁移路径
很多人卡在"选错了以后迁移难"。其实向量库的抽象层很薄，建议：
- 业务代码只依赖一层抽象接口（
search(query, k) → hits），底层是 pgvector 还是 Qdrant 实现细节。 - embedding 向量是标准资产——它和具体向量库无关，迁库时向量可复用，只需重新灌入。
- 数据源（原始文档）始终保留，迁库最坏情况是从原始文档重建索引，不是灾难。
这样从 pgvector 起步，到了瓶颈再迁 Qdrant/Milvus，成本可控。
六、别踩的坑
- 盲目追"最快的"。 向量检索在 RAG 全链路里通常不是瓶颈，切分和 rerank 影响更大。为一个快 5ms 的库换一套运维体系，得不偿失。
- 忽视过滤性能。 很多真实查询是"带过滤的向量检索"（只查某个用户/某个时间段）。有些库过滤后性能暴跌，benchmark 看不出来。
- 过度分布式。 单机能搞定的量，别上分布式。分布式向量库的运维复杂度是指数级上升的。
小结
向量库选型的正确姿势：先定场景（规模/运维/混合检索），再选库。
- 已有 PG、中小规模 → pgvector
- 中大规模、要延迟和过滤 → Qdrant
- 亿级、高吞吐 → Milvus
- 不想运维、预算够 → Pinecone
- 原型 → Chroma / sqlite-vec
最被低估的是 pgvector——大多数项目的数据量根本没到它的天花板，却一开始就上了更重的向量库，平添运维负担。从一个你能轻松 hold 住的方案起步，业务真的需要时再升级，比一上来就"为未来设计"聪明得多。
Related