14.什么时候用pgvector什么时候单独部署Milvus

什么时候用 pgvector，什么时候单独部署 Milvus？

码海寻道 · 大模型、智能体与 RAG 工程组件系列第 14 篇

PostgreSQL 加 pgvector，还是 PostgreSQL 加 Milvus？

这是 RAG 项目非常常见的架构选择题。很多团队一开始想要"最专业"的向量数据库，直接部署 Milvus；也有团队为了减少组件，试图把所有向量检索都放进 PostgreSQL。

更稳妥的答案不是固定选其中一个，而是先判断：

向量检索是业务数据库中的一个功能，还是已经成为需要独立扩展的核心基础设施？

还要问三个运行问题：谁负责数据事实，谁负责向量索引，谁负责故障恢复？pgvector 把业务数据和向量放在同一个 PostgreSQL 体系中；Milvus 则把向量检索拆成独立基础设施，通常还需要单独考虑 Standalone/Distributed、元数据、对象存储和索引服务。拆分后能力更强，但组件和同步链路也更多。

一、两种架构先看懂

方案 A：PostgreSQL + pgvector

text 复制代码

应用服务
   ↓
PostgreSQL
   ├── 用户、权限、文档和任务
   ├── 会话、审计和业务数据
   └── pgvector 向量检索

向量和业务数据在同一个数据库中，应用通过 SQL 完成过滤、关联和检索。

方案 B：PostgreSQL + Milvus

text 复制代码

应用服务
   ├── PostgreSQL：业务事实
   └── Milvus：大规模向量检索

PostgreSQL 负责用户、权限、文档和任务；Milvus 负责向量存储、索引和相似度搜索。两者通过 document_id、chunk_id 和元数据关联。

二、优先使用 pgvector 的场景

1. 项目处于原型和验证阶段

如果还在验证用户是否真的需要知识库，使用 PostgreSQL + pgvector 可以减少部署和运维成本：

text 复制代码

FastAPI
+ PostgreSQL
+ pgvector
+ 一个 Embedding 模型

先把"上传、切分、向量化、检索、回答"跑通，再根据数据和并发决定是否拆分。

2. 向量数据规模中小

向量数量较少、查询并发有限、延迟要求可接受时，pgvector 往往足够。具体上限不能只看一个数字，需要结合：

向量维度；
索引类型；
过滤条件；
查询并发；
PostgreSQL 机器资源；
业务 SQL 的负载。

3. 业务过滤和 JOIN 很重要

如果每次检索都需要结合复杂业务条件：

text 复制代码

用户可访问的部门
+ 文档当前版本
+ 租户条件
+ 发布状态
+ 业务对象关联

pgvector 可以直接与 PostgreSQL 的 WHERE、JOIN、事务和权限模型结合，开发体验通常更简单。

4. 团队希望减少基础设施数量

少一个独立服务，就少一套部署、监控、备份、升级和故障处理流程。对于小团队，这是实际的工程收益。

三、考虑单独部署 Milvus 的场景

1. 向量检索已经成为核心负载

如果系统主要工作就是高并发向量搜索，且向量数据持续增长，把检索工作从业务数据库中分离出来，有利于独立扩展查询资源。

2. 业务数据库和向量查询互相影响

当向量索引占用大量内存和 CPU，业务 SQL、事务写入和用户请求可能受到影响。将 Milvus 独立出来，可以降低资源竞争。

3. 需要面向大规模向量的专用能力

Milvus 提供多种向量索引、近似搜索、过滤、混合检索和多种部署形态。它的 Standalone 和 Distributed 模式适合不同数据规模与可用性要求。

4. 需要独立扩展和隔离

查询节点、数据节点和索引任务需要按照不同负载扩展时，专用向量数据库更容易进行针对性设计。

5. 多模态和多向量场景增加

文字、图片、音频和稀疏向量同时进入检索系统后，数据模型和索引策略更加复杂。应结合 Milvus 的具体能力、版本和部署成本评估。

四、不要只用"向量条数"决定选型

"超过多少条就必须用 Milvus"通常是过度简化。真正影响选型的是多个变量的组合：

text 复制代码

向量数量
× 向量维度
× 查询并发
× 延迟目标
× 过滤复杂度
× 写入更新频率
× 业务数据库负载
× 可接受运维复杂度

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 与阈值；
评测集和结果基线。

推荐采用双索引灰度方式：

text 复制代码

PostgreSQL + pgvector（旧链路）
                 ↓
            同步或重建
                 ↓
Milvus（新链路）
                 ↓
同一批评测问题比较召回率、延迟和成本
                 ↓
逐步切换查询流量

在切换期间保留旧链路，出现检索质量或稳定性问题时可以回滚。

迁移时建议使用稳定的 chunk_id 作为幂等键，并为每个目标批次保存迁移状态：

text 复制代码

pending → embedding_ready → milvus_inserted → verified → serving

验证不能只比较向量数量，还要抽样比较 ID、租户、文档版本、删除状态、过滤结果和 Top K 排名。切换前保留旧索引和回滚开关，切换后再按保留周期清理。

七、两种架构都需要解决一致性

无论使用 pgvector 还是 Milvus，以下事件都需要同步处理：

文档新增；
文档内容更新；
文档版本发布；
文档撤回；
权限变化；
租户删除；
Embedding 模型升级。

pgvector 的优势是数据可以在同一 PostgreSQL 中一起提交，但如果向量更新由异步 Worker 完成，仍然需要状态管理。

推荐把 PostgreSQL 作为业务事实源，把向量系统作为可重建的检索索引。文档发布、撤回、删除和权限变化先在 PostgreSQL 中形成明确状态，再由 Outbox/队列驱动 Worker 更新向量索引。这样即使 Milvus 或 pgvector 暂时不可用，也能通过任务状态重试，而不是靠人工猜测哪些向量已经更新。

Milvus 方案则需要更明确的事件驱动或补偿机制：

text 复制代码

PostgreSQL 更新业务状态
  ↓
发布索引更新事件
  ↓
Worker 更新 Milvus
  ↓
成功 / 失败回写 PostgreSQL
  ↓
失败重试或人工处理

八、如何做真实压测？

选型前至少准备三类数据：

业务数据

不同文档长度、不同权限和不同更新频率的真实样本。

查询数据

真实用户问题、长问题、无答案问题、关键词问题和权限边界问题。

负载数据

不同并发数、Top K、过滤条件、批量写入和更新操作。

至少比较：

P50、P95、P99 查询延迟；
Recall@K；
过滤后的有效结果数量；
索引构建时间；
内存和 CPU；
写入吞吐；
故障恢复时间；
运维与备份成本。

不要只测试一次查询，也不要只测"没有过滤条件"的理想情况。

九、一个实用的分阶段路线

阶段一：先用 pgvector 验证闭环

text 复制代码

PostgreSQL + pgvector
  ↓
验证解析、切分、Embedding 和回答质量

阶段二：优化检索和数据模型

text 复制代码

评估全文检索、混合检索、Reranker、过滤和索引参数

阶段三：确认瓶颈

text 复制代码

如果业务 SQL、事务和向量搜索资源竞争明显
或延迟、并发、规模达到独立扩展需求
  ↓
考虑迁移 Milvus

阶段四：独立向量服务

text 复制代码

PostgreSQL：业务事实
Milvus：向量检索
消息队列：索引同步
监控：跨系统链路追踪

十、常见错误决策

错误一：因为 Milvus 专业，所以项目一开始就部署

专业能力需要用数据证明是否必要。复杂部署不等于更好的检索效果。

错误二：因为 pgvector 简单，所以永远不拆分

当向量检索明显影响业务数据库时，继续把所有负载绑在一起也不是好的架构。

错误三：迁移时只复制向量，不复制版本和权限

这样可能导致检索到旧文档、越权文档或无法显示引用来源。

错误四：只看平均延迟

企业系统更应该关注 P95、P99、故障恢复和高峰期资源竞争。

十一、选型决策表

问题	更倾向 pgvector	更倾向 Milvus
项目阶段	原型、小规模上线	稳定生产、大规模运行
业务关系	复杂 JOIN 和事务多	向量检索相对独立
向量负载	中小规模、并发有限	大规模、高并发
资源隔离	不强	强需求
团队能力	PostgreSQL 运维成熟	能承担额外分布式组件
基础设施目标	少组件、低运维	独立扩展、专用检索

十二、上线前检查清单

结语：先用简单方案验证，再用数据决定拆分

pgvector 和 Milvus 不是"入门方案"和"高级方案"的简单关系。

pgvector 的核心优势是把向量检索与 PostgreSQL 的业务数据、SQL、事务和权限结合起来；Milvus 的核心优势是为专用向量检索提供更强的规模、索引和独立扩展能力。

最稳妥的路线通常是：先使用能快速验证业务闭环的方案，持续收集召回率、延迟、资源和运维数据，等瓶颈真实出现后再拆分。

至此，第三篇章"PostgreSQL 与业务数据"全部完成。下一篇章将进入 Milvus 与向量数据库，从《Milvus 是什么？为什么 RAG 系统经常使用它？》开始。

参考资料

本文为"码海寻道"原创技术文章。pgvector、Milvus 和 PostgreSQL 的版本、索引能力与部署方式会持续变化，正式选型请结合实际版本和压测结果。