14.什么时候用pgvector什么时候单独部署Milvus
什么时候用 pgvector，什么时候单独部署 Milvus？
码海寻道 · 大模型、智能体与 RAG 工程组件系列第 14 篇
PostgreSQL 加 pgvector，还是 PostgreSQL 加 Milvus？
这是 RAG 项目非常常见的架构选择题。很多团队一开始想要“最专业”的向量数据库，直接部署 Milvus；也有团队为了减少组件，试图把所有向量检索都放进 PostgreSQL。
更稳妥的答案不是固定选其中一个，而是先判断：
向量检索是业务数据库中的一个功能，还是已经成为需要独立扩展的核心基础设施？
还要问三个运行问题：谁负责数据事实，谁负责向量索引，谁负责故障恢复？pgvector 把业务数据和向量放在同一个 PostgreSQL 体系中；Milvus 则把向量检索拆成独立基础设施，通常还需要单独考虑 Standalone/Distributed、元数据、对象存储和索引服务。拆分后能力更强，但组件和同步链路也更多。
一、两种架构先看懂
方案 A：PostgreSQL + pgvector
应用服务 ↓ PostgreSQL ├── 用户、权限、文档和任务 ├── 会话、审计和业务数据 └── pgvector 向量检索向量和业务数据在同一个数据库中，应用通过 SQL 完成过滤、关联和检索。
方案 B：PostgreSQL + Milvus
应用服务 ├── PostgreSQL：业务事实 └── Milvus：大规模向量检索PostgreSQL 负责用户、权限、文档和任务；Milvus 负责向量存储、索引和相似度搜索。两者通过document_id、chunk_id和元数据关联。
二、优先使用 pgvector 的场景
1. 项目处于原型和验证阶段
如果还在验证用户是否真的需要知识库，使用 PostgreSQL + pgvector 可以减少部署和运维成本：
FastAPI + PostgreSQL + pgvector + 一个 Embedding 模型先把“上传、切分、向量化、检索、回答”跑通，再根据数据和并发决定是否拆分。
2. 向量数据规模中小
向量数量较少、查询并发有限、延迟要求可接受时，pgvector 往往足够。具体上限不能只看一个数字，需要结合：
- 向量维度；
- 索引类型；
- 过滤条件；
- 查询并发；
- PostgreSQL 机器资源；
- 业务 SQL 的负载。
3. 业务过滤和 JOIN 很重要
如果每次检索都需要结合复杂业务条件：
用户可访问的部门 + 文档当前版本 + 租户条件 + 发布状态 + 业务对象关联pgvector 可以直接与 PostgreSQL 的 WHERE、JOIN、事务和权限模型结合，开发体验通常更简单。
4. 团队希望减少基础设施数量
少一个独立服务，就少一套部署、监控、备份、升级和故障处理流程。对于小团队，这是实际的工程收益。
三、考虑单独部署 Milvus 的场景
1. 向量检索已经成为核心负载
如果系统主要工作就是高并发向量搜索，且向量数据持续增长，把检索工作从业务数据库中分离出来，有利于独立扩展查询资源。
2. 业务数据库和向量查询互相影响
当向量索引占用大量内存和 CPU，业务 SQL、事务写入和用户请求可能受到影响。将 Milvus 独立出来，可以降低资源竞争。
3. 需要面向大规模向量的专用能力
Milvus 提供多种向量索引、近似搜索、过滤、混合检索和多种部署形态。它的 Standalone 和 Distributed 模式适合不同数据规模与可用性要求。
4. 需要独立扩展和隔离
查询节点、数据节点和索引任务需要按照不同负载扩展时，专用向量数据库更容易进行针对性设计。
5. 多模态和多向量场景增加
文字、图片、音频和稀疏向量同时进入检索系统后，数据模型和索引策略更加复杂。应结合 Milvus 的具体能力、版本和部署成本评估。
四、不要只用“向量条数”决定选型
“超过多少条就必须用 Milvus”通常是过度简化。真正影响选型的是多个变量的组合：
向量数量 × 向量维度 × 查询并发 × 延迟目标 × 过滤复杂度 × 写入更新频率 × 业务数据库负载 × 可接受运维复杂度100 万条低并发向量，可能在 PostgreSQL 中运行良好；10 万条高并发且严格低延迟的向量，也可能需要独立检索服务。
五、两种方案的对比
| 维度 | PostgreSQL + pgvector | PostgreSQL + Milvus |
|---|---|---|
| 部署复杂度 | 较低 | 较高 |
| 业务关联查询 | 方便 | 需要跨系统关联 |
| 事务一致性 | 业务和向量更容易一起管理 | 需要事件、补偿和同步策略 |
| 向量检索扩展 | 与 PostgreSQL 资源绑定 | 可独立扩展 |
| 小项目成本 | 较低 | 较高 |
| 大规模向量能力 | 需要评估 | 更适合专用检索负载 |
| 运维要求 | 复用 PostgreSQL 体系 | 需要额外管理组件和依赖 |
| 故障边界 | 系统较集中 | 服务隔离更清晰，但链路更多 |
没有一列可以永久判定优劣，关键是看你的业务约束。
还要比较资源和故障域
| 方面 | pgvector | Milvus |
|---|---|---|
| 资源竞争 | 向量查询与业务 SQL、事务共享 PostgreSQL 资源 | 可独立规划向量检索资源，但要维护额外服务 |
| 故障影响 | PostgreSQL 异常可能同时影响业务和检索 | Milvus 异常主要影响检索，业务库可独立运行，但答案链路仍需降级 |
| 持久化 | 使用 PostgreSQL 的 WAL、备份和复制体系 | 需要同时管理 Milvus 元数据、对象存储、索引和部署依赖 |
| 迁移成本 | 业务关联简单 | 需要维护 PostgreSQL 与 Milvus 的 ID、权限、版本和同步状态 |
Milvus 不是“把 pgvector 换成另一个连接字符串”。生产部署还要明确 Standalone 或 Distributed 形态、对象存储、元数据和备份恢复方式。只有当这些额外能力真正解决了当前瓶颈，拆分才有价值。
六、从 pgvector 迁移到 Milvus 要提前设计什么？
不要把迁移理解成“把向量复制到另一个数据库”。还要迁移和验证：
- 文档和 Chunk 的唯一 ID；
- Embedding 模型与维度；
- 距离指标；
- 租户、权限和版本元数据；
- 删除和更新策略；
- 索引参数；
- Top K 与阈值；
- 评测集和结果基线。
推荐采用双索引灰度方式：
PostgreSQL + pgvector（旧链路） ↓ 同步或重建 ↓ Milvus（新链路） ↓ 同一批评测问题比较召回率、延迟和成本 ↓ 逐步切换查询流量在切换期间保留旧链路，出现检索质量或稳定性问题时可以回滚。
迁移时建议使用稳定的chunk_id作为幂等键，并为每个目标批次保存迁移状态：
pending → embedding_ready → milvus_inserted → verified → serving验证不能只比较向量数量，还要抽样比较 ID、租户、文档版本、删除状态、过滤结果和 Top K 排名。切换前保留旧索引和回滚开关，切换后再按保留周期清理。
七、两种架构都需要解决一致性
无论使用 pgvector 还是 Milvus，以下事件都需要同步处理：
- 文档新增；
- 文档内容更新；
- 文档版本发布；
- 文档撤回；
- 权限变化；
- 租户删除；
- Embedding 模型升级。
pgvector 的优势是数据可以在同一 PostgreSQL 中一起提交，但如果向量更新由异步 Worker 完成，仍然需要状态管理。
推荐把 PostgreSQL 作为业务事实源，把向量系统作为可重建的检索索引。文档发布、撤回、删除和权限变化先在 PostgreSQL 中形成明确状态，再由 Outbox/队列驱动 Worker 更新向量索引。这样即使 Milvus 或 pgvector 暂时不可用，也能通过任务状态重试，而不是靠人工猜测哪些向量已经更新。
Milvus 方案则需要更明确的事件驱动或补偿机制：
PostgreSQL 更新业务状态 ↓ 发布索引更新事件 ↓ Worker 更新 Milvus ↓ 成功 / 失败回写 PostgreSQL ↓ 失败重试或人工处理八、如何做真实压测？
选型前至少准备三类数据：
业务数据
不同文档长度、不同权限和不同更新频率的真实样本。
查询数据
真实用户问题、长问题、无答案问题、关键词问题和权限边界问题。
负载数据
不同并发数、Top K、过滤条件、批量写入和更新操作。
至少比较：
- P50、P95、P99 查询延迟；
- Recall@K；
- 过滤后的有效结果数量；
- 索引构建时间；
- 内存和 CPU；
- 写入吞吐；
- 故障恢复时间；
- 运维与备份成本。
不要只测试一次查询，也不要只测“没有过滤条件”的理想情况。
九、一个实用的分阶段路线
阶段一：先用 pgvector 验证闭环
PostgreSQL + pgvector ↓ 验证解析、切分、Embedding 和回答质量阶段二：优化检索和数据模型
评估全文检索、混合检索、Reranker、过滤和索引参数阶段三：确认瓶颈
如果业务 SQL、事务和向量搜索资源竞争明显 或延迟、并发、规模达到独立扩展需求 ↓ 考虑迁移 Milvus阶段四：独立向量服务
PostgreSQL：业务事实 Milvus：向量检索 消息队列：索引同步 监控：跨系统链路追踪十、常见错误决策
错误一：因为 Milvus 专业，所以项目一开始就部署
专业能力需要用数据证明是否必要。复杂部署不等于更好的检索效果。
错误二：因为 pgvector 简单，所以永远不拆分
当向量检索明显影响业务数据库时，继续把所有负载绑在一起也不是好的架构。
错误三：迁移时只复制向量，不复制版本和权限
这样可能导致检索到旧文档、越权文档或无法显示引用来源。
错误四：只看平均延迟
企业系统更应该关注 P95、P99、故障恢复和高峰期资源竞争。
十一、选型决策表
| 问题 | 更倾向 pgvector | 更倾向 Milvus |
|---|---|---|
| 项目阶段 | 原型、小规模上线 | 稳定生产、大规模运行 |
| 业务关系 | 复杂 JOIN 和事务多 | 向量检索相对独立 |
| 向量负载 | 中小规模、并发有限 | 大规模、高并发 |
| 资源隔离 | 不强 | 强需求 |
| 团队能力 | PostgreSQL 运维成熟 | 能承担额外分布式组件 |
| 基础设施目标 | 少组件、低运维 | 独立扩展、专用检索 |
十二、上线前检查清单
- 不以向量条数单独决定选型；
- 已评估查询并发、延迟和过滤条件；
- 已比较 pgvector 精确与近似检索；
- 已评估业务 SQL 与向量搜索的资源竞争；
- 已定义文档、Chunk、版本和租户 ID；
- 已设计新增、更新、删除和权限变更同步；
- 迁移时保留旧索引和回滚方案；
- 使用同一评测集比较召回率和最终答案质量；
- 计算了部署、备份、监控和运维成本；
- 明确何种指标触发从 pgvector 拆分到 Milvus。
- 如果使用 Milvus，已明确 Standalone/Distributed、对象存储和元数据依赖；
- 如果使用 pgvector，已验证业务 SQL 与向量检索的资源隔离；
- 迁移具备稳定 ID、双写/灰度、校验和回滚方案；
结语：先用简单方案验证，再用数据决定拆分
pgvector 和 Milvus 不是“入门方案”和“高级方案”的简单关系。
pgvector 的核心优势是把向量检索与 PostgreSQL 的业务数据、SQL、事务和权限结合起来；Milvus 的核心优势是为专用向量检索提供更强的规模、索引和独立扩展能力。
最稳妥的路线通常是：先使用能快速验证业务闭环的方案，持续收集召回率、延迟、资源和运维数据，等瓶颈真实出现后再拆分。
至此，第三篇章“PostgreSQL 与业务数据”全部完成。下一篇章将进入 Milvus 与向量数据库，从《Milvus 是什么？为什么 RAG 系统经常使用它？》开始。
参考资料
- pgvector 官方项目
- Milvus Documentation：What is Milvus
- Milvus Documentation：Basic Vector Search
- Milvus Documentation：Architecture Overview
- Milvus Documentation：Run Milvus with Docker Compose
本文为“码海寻道”原创技术文章。pgvector、Milvus 和 PostgreSQL 的版本、索引能力与部署方式会持续变化，正式选型请结合实际版本和压测结果。