什么时候用 pgvector什么时候单独部署 Milvus码海寻道 · 大模型、智能体与 RAG 工程组件系列第 14 篇PostgreSQL 加 pgvector还是 PostgreSQL 加 Milvus这是 RAG 项目非常常见的架构选择题。很多团队一开始想要“最专业”的向量数据库直接部署 Milvus也有团队为了减少组件试图把所有向量检索都放进 PostgreSQL。更稳妥的答案不是固定选其中一个而是先判断向量检索是业务数据库中的一个功能还是已经成为需要独立扩展的核心基础设施还要问三个运行问题谁负责数据事实谁负责向量索引谁负责故障恢复pgvector 把业务数据和向量放在同一个 PostgreSQL 体系中Milvus 则把向量检索拆成独立基础设施通常还需要单独考虑 Standalone/Distributed、元数据、对象存储和索引服务。拆分后能力更强但组件和同步链路也更多。一、两种架构先看懂方案 APostgreSQL pgvector应用服务 ↓ PostgreSQL ├── 用户、权限、文档和任务 ├── 会话、审计和业务数据 └── pgvector 向量检索向量和业务数据在同一个数据库中应用通过 SQL 完成过滤、关联和检索。方案 BPostgreSQL 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 pgvectorPostgreSQL Milvus部署复杂度较低较高业务关联查询方便需要跨系统关联事务一致性业务和向量更容易一起管理需要事件、补偿和同步策略向量检索扩展与 PostgreSQL 资源绑定可独立扩展小项目成本较低较高大规模向量能力需要评估更适合专用检索负载运维要求复用 PostgreSQL 体系需要额外管理组件和依赖故障边界系统较集中服务隔离更清晰但链路更多没有一列可以永久判定优劣关键是看你的业务约束。还要比较资源和故障域方面pgvectorMilvus资源竞争向量查询与业务 SQL、事务共享 PostgreSQL 资源可独立规划向量检索资源但要维护额外服务故障影响PostgreSQL 异常可能同时影响业务和检索Milvus 异常主要影响检索业务库可独立运行但答案链路仍需降级持久化使用 PostgreSQL 的 WAL、备份和复制体系需要同时管理 Milvus 元数据、对象存储、索引和部署依赖迁移成本业务关联简单需要维护 PostgreSQL 与 Milvus 的 ID、权限、版本和同步状态Milvus 不是“把 pgvector 换成另一个连接字符串”。生产部署还要明确 Standalone 或 Distributed 形态、对象存储、元数据和备份恢复方式。只有当这些额外能力真正解决了当前瓶颈拆分才有价值。六、从 pgvector 迁移到 Milvus 要提前设计什么不要把迁移理解成“把向量复制到另一个数据库”。还要迁移和验证文档和 Chunk 的唯一 IDEmbedding 模型与维度距离指标租户、权限和版本元数据删除和更新策略索引参数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 查询延迟RecallK过滤后的有效结果数量索引构建时间内存和 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 DocumentationWhat is MilvusMilvus DocumentationBasic Vector SearchMilvus DocumentationArchitecture OverviewMilvus DocumentationRun Milvus with Docker Compose本文为“码海寻道”原创技术文章。pgvector、Milvus 和 PostgreSQL 的版本、索引能力与部署方式会持续变化正式选型请结合实际版本和压测结果。 14.什么时候用pgvector什么时候单独部署Milvus
什么时候用 pgvector什么时候单独部署 Milvus码海寻道 · 大模型、智能体与 RAG 工程组件系列第 14 篇PostgreSQL 加 pgvector还是 PostgreSQL 加 Milvus这是 RAG 项目非常常见的架构选择题。很多团队一开始想要“最专业”的向量数据库直接部署 Milvus也有团队为了减少组件试图把所有向量检索都放进 PostgreSQL。更稳妥的答案不是固定选其中一个而是先判断向量检索是业务数据库中的一个功能还是已经成为需要独立扩展的核心基础设施还要问三个运行问题谁负责数据事实谁负责向量索引谁负责故障恢复pgvector 把业务数据和向量放在同一个 PostgreSQL 体系中Milvus 则把向量检索拆成独立基础设施通常还需要单独考虑 Standalone/Distributed、元数据、对象存储和索引服务。拆分后能力更强但组件和同步链路也更多。一、两种架构先看懂方案 APostgreSQL pgvector应用服务 ↓ PostgreSQL ├── 用户、权限、文档和任务 ├── 会话、审计和业务数据 └── pgvector 向量检索向量和业务数据在同一个数据库中应用通过 SQL 完成过滤、关联和检索。方案 BPostgreSQL 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 pgvectorPostgreSQL Milvus部署复杂度较低较高业务关联查询方便需要跨系统关联事务一致性业务和向量更容易一起管理需要事件、补偿和同步策略向量检索扩展与 PostgreSQL 资源绑定可独立扩展小项目成本较低较高大规模向量能力需要评估更适合专用检索负载运维要求复用 PostgreSQL 体系需要额外管理组件和依赖故障边界系统较集中服务隔离更清晰但链路更多没有一列可以永久判定优劣关键是看你的业务约束。还要比较资源和故障域方面pgvectorMilvus资源竞争向量查询与业务 SQL、事务共享 PostgreSQL 资源可独立规划向量检索资源但要维护额外服务故障影响PostgreSQL 异常可能同时影响业务和检索Milvus 异常主要影响检索业务库可独立运行但答案链路仍需降级持久化使用 PostgreSQL 的 WAL、备份和复制体系需要同时管理 Milvus 元数据、对象存储、索引和部署依赖迁移成本业务关联简单需要维护 PostgreSQL 与 Milvus 的 ID、权限、版本和同步状态Milvus 不是“把 pgvector 换成另一个连接字符串”。生产部署还要明确 Standalone 或 Distributed 形态、对象存储、元数据和备份恢复方式。只有当这些额外能力真正解决了当前瓶颈拆分才有价值。六、从 pgvector 迁移到 Milvus 要提前设计什么不要把迁移理解成“把向量复制到另一个数据库”。还要迁移和验证文档和 Chunk 的唯一 IDEmbedding 模型与维度距离指标租户、权限和版本元数据删除和更新策略索引参数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 查询延迟RecallK过滤后的有效结果数量索引构建时间内存和 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 DocumentationWhat is MilvusMilvus DocumentationBasic Vector SearchMilvus DocumentationArchitecture OverviewMilvus DocumentationRun Milvus with Docker Compose本文为“码海寻道”原创技术文章。pgvector、Milvus 和 PostgreSQL 的版本、索引能力与部署方式会持续变化正式选型请结合实际版本和压测结果。