向量数据库选型实战：pgvector vs Milvus vs Qdrant
------ 从 MVP 到生产级 RAG 的工程思考
在做 AI / RAG（Retrieval-Augmented Generation）系统时，向量数据库几乎是绕不开的基础设施 。
但真正落地时，大家很快会发现：
向量库不是"能用就行"，而是"选错就会拖垮系统"。
本文结合一个真实的 AI Service Desk MVP 项目，系统性对比三种主流方案：
- pgvector（PostgreSQL 扩展，省组件）
- Milvus（分布式专业向量数据库）
- Qdrant（工程友好的轻量向量数据库）
并给出 从 MVP → 生产的清晰选型路径。
代码仓库（完整可运行）：
👉 https://github.com/srk950606/ai-service-desk-mvp.git
一、背景：为什么向量库选型这么重要？
在典型的 RAG / 智能客服 / 知识库系统中，链路往往是：
文档 → Embedding → 向量库
用户问题 → Embedding → 相似度搜索 → LLM在这个过程中，向量库决定了：
- 🔹 搜索延迟（用户是否觉得"卡"）
- 🔹 召回质量（答案是否相关）
- 🔹 系统扩展性（数据涨 10 倍会不会崩）
- 🔹 运维复杂度（是不是要专人维护）
选型本质不是"哪个好"，而是"哪个适合当前阶段"。
二、pgvector：最低成本的入门方案
1. pgvector 是什么？
pgvector 是 PostgreSQL 的一个扩展，让 PG 能存储和搜索向量：
sql
CREATE TABLE docs (
id BIGSERIAL PRIMARY KEY,
content TEXT,
embedding VECTOR(1536)
);本质是：
关系型数据库 + 向量列 + ANN 索引
2. 优点：为什么很多 MVP 都选它？
✅ 省组件
- 不需要额外部署新系统
- 直接复用已有 PostgreSQL
✅ 工程友好
- SQL 查询
- ORM 兼容
- 事务、权限、备份一应俱全
✅ 非常适合 MVP
- PoC
- 内部工具
- 小规模 RAG
3. 现实限制（一定要知道）
❌ 不是为向量而生
- PG Executor 本质是行存系统
- 高维向量扫描成本高
❌ 规模瓶颈明显
- 10 万 ~ 100 万：很好
- 500 万：开始吃力
- 千万级：明显不适合
❌ 扩展性弱
- 以纵向扩展为主
- 向量一旦成为核心能力，PG 会成为瓶颈
📌 结论：
pgvector 非常适合「先跑起来」，但不适合「长期扛量」。
三、Milvus：为大规模而生的专业选手
1. Milvus 是什么？
Milvus 是一个 从零为向量检索设计的分布式数据库。
可以类比：
Elasticsearch : MySQL
Milvus : PostgreSQL
2. 架构特点（为什么它强）
Milvus 是典型的 分布式多组件架构：
- Proxy（入口）
- QueryNode（查询）
- DataNode（写入）
- IndexNode（索引构建）
- Etcd（元数据）
- S3 / MinIO（向量存储）
📌 核心思想：
- 计算 / 存储分离
- 天然分片
- 横向扩展
3. 能力边界
✅ 规模
- 千万级：轻松
- 亿级：常态
- 百亿级：生产可用
✅ 算法支持
- IVF / HNSW / PQ / GPU
- 可精细调参（精度 vs 性能）
❌ 代价
- 运维复杂
- 资源消耗大
- 学习成本高
📌 结论：
Milvus 是"企业级武器"，但不是"轻量级工具"。
四、Qdrant：工程体验非常好的中间路线
1. Qdrant 是什么？
Qdrant 是一个用 Rust 编写的向量数据库，定位介于 pgvector 和 Milvus 之间。
2. 为什么工程师喜欢它？
✅ 开箱即用
- 单二进制 / Docker 一行启动
- 无复杂依赖
✅ 核心算法聚焦
- HNSW 为主
- 搜索质量高
- 延迟低（10ms 级）
✅ 元数据过滤非常强
json
{
"must": [
{ "key": "category", "match": { "value": "faq" } }
]
}3. 适用规模
- 百万级：非常稳
- 千万级：合理配置可跑
- 亿级：需要集群
📌 结论：
Qdrant 是「大多数工程团队的甜点区」。
五、三种方案核心对比
| 维度 | pgvector | Milvus | Qdrant |
|---|---|---|---|
| 定位 | PG 扩展 | 分布式向量 DB | 专用向量 DB |
| 规模 | 百万级 | 百亿级 | 千万~亿级 |
| 运维成本 | 低 | 高 | 中 |
| 学习成本 | 低 | 高 | 低 |
| MVP 友好度 | ⭐⭐⭐⭐⭐ | ⭐ | ⭐⭐⭐⭐ |
| 长期扩展性 | ⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
六、真实选型决策树（强烈建议收藏）
1️⃣ 是否已有 PostgreSQL？
└─ 是 → 先用 pgvector
2️⃣ 向量是不是核心能力？
└─ 否 → pgvector
└─ 是 → 下一步
3️⃣ 规模是否 > 1000 万？
└─ 是 → Milvus
└─ 否 → Qdrant
4️⃣ 团队运维能力？
└─ 强 → Milvus
└─ 一般 → Qdrant七、工程实践：AI Service Desk MVP
在 AI Service Desk MVP 中，我们采用的策略是：
-
MVP 阶段 ：
👉 pgvector（快速交付、低成本）
-
架构设计上预留切换能力：
- 向量访问通过 Repository 抽象
- Embedding 维度、索引策略可配置
- 可平滑迁移到 Qdrant / Milvus
代码仓库：
👉 https://github.com/srk950606/ai-service-desk-mvp.git
八、最后的经验总结
向量数据库不是"一步到位"的选择，而是"阶段性最优解"
- 不要为了"未来可能的规模"过度设计
- 也不要让 MVP 的技术债锁死未来
先跑起来，再跑得快，最后跑得远。