11.PostgreSQ、-MySQL与MongoDB-AI应用如何选择数据库

PostgreSQL、MySQL 与 MongoDB：AI 应用该如何选择数据库？

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

做大模型应用时，数据库选型经常被简化成一句话：PostgreSQL 功能最全，MySQL 最常见，MongoDB 最灵活。

这类结论太粗。AI 应用中的数据库选择，真正取决于你要保存什么数据、数据之间的关系有多复杂、查询模式是否稳定、是否需要事务，以及团队已经掌握什么技术。

本文不做"谁绝对更好"的排名，而是比较 PostgreSQL、MySQL 和 MongoDB 在 AI 应用中的职责边界和适用场景。

数据库选型还要考虑它如何进入系统：是直接被 API 访问，还是通过数据服务、只读副本、同步任务和缓存被访问。一个数据库即使功能丰富，如果连接数、备份、迁移和权限体系无法满足团队能力，也不一定是合适的选择。

一、先问数据是什么，而不是先问数据库是什么

一个 AI 应用可能同时处理：

text 复制代码

用户与权限 → 强关系、强约束
文档与版本 → 关系数据 + 半结构化元数据
模型调用记录 → 高写入、可扩展字段
对话消息 → 时间序列式增长
向量 → 相似度检索
原始文件 → 对象存储

不同数据未必需要同一种存储。常见组合是：

text 复制代码

PostgreSQL / MySQL：业务事实
MongoDB：灵活的文档型数据
Milvus / pgvector：向量检索
MinIO / S3：原始文件
Redis：缓存和短期状态

数据库选型首先是工作负载设计，其次才是产品偏好。

二、PostgreSQL：关系、事务和扩展能力较均衡

PostgreSQL 适合承载企业 AI 应用的核心业务数据：

用户、组织、租户和角色；
文档、版本、权限和发布状态；
对话、反馈、审计和任务；
结构化业务对象；
JSONB 半结构化字段；
全文检索和 pgvector 向量检索。

它的优势在于关系模型、约束、事务、SQL 查询和扩展能力组合得比较完整。

适合 PostgreSQL 的场景

企业知识库的文档与权限管理；
需要事务的一致性业务；
RAG 应用的会话和引用记录；
需要同时查询结构化字段和向量的轻量级应用；
团队希望使用一种数据库完成较多职责。

需要注意的地方

复杂 JSONB 设计可能逐渐失控；
大规模向量检索需要评估 pgvector 的能力和资源；
高写入日志和消息数据要规划分区、归档；
"什么都放 PostgreSQL"会让职责过度集中。

三、MySQL：成熟、普及，适合已有业务体系

MySQL 在互联网业务中非常普及，拥有成熟的运维、云服务、备份、复制和开发生态。如果企业已有大量 MySQL 数据和经验，没有必要为了 AI 项目强行迁移到 PostgreSQL。

适合 MySQL 的场景

AI 应用需要读取已有订单、用户、商品和客户系统；
团队已有成熟的 MySQL 运维体系；
业务数据模型清晰，主要使用关系查询和事务；
向量检索由独立的 Milvus 或其他向量数据库承担。

需要注意的地方

AI 应用中的 JSON、全文检索和向量能力需要结合具体版本与扩展评估；
不要为了让模型直接查询生产库而放宽数据库权限；
复杂 AI 元数据和检索状态可能需要单独设计服务层；
读取生产 MySQL 时，建议使用只读副本或数据服务接口。

如果企业订单系统已经稳定运行在 MySQL 上，最合理的做法通常是保留 MySQL 作为业务事实源，再通过 API、CDC 或同步任务为 AI 应用提供数据。

四、MongoDB：灵活文档结构和快速演进

MongoDB 以文档模型保存数据，适合结构变化频繁、嵌套关系明显、字段不完全固定的场景。

在 AI 应用中，它可能用于：

原型阶段的会话文档；
模型调用的可变请求和响应记录；
Agent 状态快照；
多种工具返回结果；
文档解析后的层级结构。

适合 MongoDB 的场景

数据结构变化快；
业务对象天然以文档形式组织；
主要按文档或聚合对象读取；
团队已有 MongoDB 运维经验。

需要注意的地方

多文档关系、复杂关联和强约束需要更谨慎设计；
不要因为字段灵活，就完全放弃数据校验；
高风险业务仍需明确事务、幂等和一致性边界；
复杂统计查询要提前验证索引和聚合性能。

MongoDB 的灵活性适合快速迭代，但"结构灵活"不等于"无需设计"。没有规范的文档结构，长期维护同样会变困难。

五、三种数据库的核心比较

维度	PostgreSQL	MySQL	MongoDB
数据模型	关系型，支持 JSONB	关系型	文档型
事务与约束	强	强	支持，但模型设计影响更大
SQL 与关联查询	强	强	通过聚合和应用逻辑完成
半结构化数据	JSONB	JSON 类型	原生文档结构
AI 业务元数据	很适合	很适合	适合灵活对象
全文检索	内置能力较完整	依版本和方案	有文本检索能力，需评估
向量检索	可用 pgvector	常与独立向量库组合	依具体版本与方案
适合已有系统接入	适合	非常适合	适合已有文档型系统
典型优势	能力均衡、扩展丰富	普及和运维生态	结构灵活、开发快速

表格只能用于建立初步认识，最终仍要以具体版本、数据量、查询和团队能力测试为准。

AI 应用不要只比较"能不能存 JSON"

还应比较以下运行时问题：

问题	需要验证
并发	在线问答、批量导入和报表是否会争抢连接与锁
查询	权限过滤、时间范围、全文检索和聚合是否有稳定执行计划
演进	Schema 迁移、字段废弃和历史数据回填如何完成
恢复	备份、复制、故障切换和恢复演练是否成熟
AI 集成	pgvector、全文检索、JSON、CDC 或外部向量库如何接入

不要用单个 Benchmark 替代真实业务压测。AI 应用的瓶颈经常来自连接池、长事务、批量任务和权限过滤，而不是单条简单 SQL。

六、AI 应用最常见的四种选型方案

方案一：PostgreSQL 一体化

text 复制代码

PostgreSQL
  ├── 业务数据
  ├── 会话和任务
  ├── JSONB 元数据
  ├── 全文检索
  └── pgvector

适合个人项目、中小型知识库和希望减少基础设施数量的团队。

方案二：已有 MySQL + 独立向量数据库

text 复制代码

MySQL：现有业务事实
Milvus：Embedding 和向量检索
MinIO：原始文件

适合企业已有大量 MySQL 业务，不希望迁移核心数据库的情况。

方案三：PostgreSQL + Milvus

text 复制代码

PostgreSQL：权限、文档、版本、会话、审计
Milvus：大规模向量检索

适合业务关系复杂，同时向量数据量和检索并发较高的系统。

方案四：MongoDB + 向量检索能力

适合数据以文档对象为主、结构变化快，且团队已经围绕 MongoDB 建立应用体系的场景。是否直接使用 MongoDB 的向量能力，要结合具体版本和规模评估。

七、不要让 AI 服务直接拥有生产库全部权限

无论选择哪种数据库，都建议在模型和数据库之间增加业务服务层：

text 复制代码

大模型 / Agent
  ↓
受控工具 API
  ↓
参数校验、权限校验、审计
  ↓
数据库只读或限定写入接口

不要把生产数据库连接字符串直接交给 Agent，也不要让模型自由生成 SQL 后直接执行。

推荐至少拆分三类数据库访问角色：

text 复制代码

在线 API：只读业务查询 + 受控写入接口
异步 Worker：文档、任务和索引状态的限定写权限
管理/迁移账号：仅由发布流程使用，不能交给模型

如果使用 PostgreSQL，还可以结合独立数据库角色、最小化 GRANT、只读副本和 Row-Level Security 做更细的边界控制；但数据库权限不能替代应用层的身份认证、业务授权和审计。

更安全的方式是：

对查询操作使用参数化 SQL；
给不同工具配置不同权限；
对写操作使用白名单和人工确认；
设置超时、行数和资源限制；
记录完整请求、调用者和结果摘要。

八、AI 项目中的数据库选型决策树

text 复制代码

是否已经有稳定业务数据库？
  ├── 是 → 优先复用，增加数据服务层
  └── 否 → 继续评估

是否需要复杂关系、事务和审计？
  ├── 是 → PostgreSQL 或 MySQL
  └── 否 → 继续评估

数据结构是否快速变化、以文档对象为主？
  ├── 是 → MongoDB 可作为候选
  └── 否 → PostgreSQL 通常是稳妥起点

向量规模和并发是否很高？
  ├── 是 → 考虑独立 Milvus
  └── 否 → pgvector 或现有数据库能力

九、迁移和演进比初始选型更重要

不要只设计"今天怎么存"，还要考虑：

文档版本是否会增加；
Embedding 模型升级如何重建向量；
会话日志如何归档；
业务数据库如何扩容；
读写是否需要拆分；
向量检索是否未来独立出来；
是否需要跨区域复制和灾备。

一个好的选型应该允许系统在数据量增长后逐步拆分，而不是一开始就把所有服务拆成无法运维的复杂集群。

十、上线前检查清单

结语：数据库选型首先是业务问题

PostgreSQL、MySQL 和 MongoDB 都可以参与 AI 应用，但它们适合的职责并不完全相同：

PostgreSQL 适合关系、事务、JSONB、全文检索和较完整的 AI 业务数据；
MySQL 适合复用成熟的企业业务体系；
MongoDB 适合结构灵活、文档化程度高的对象。

真正重要的不是追逐某个"AI 首选数据库"，而是明确数据事实源、权限边界、查询模式和未来演进路径。

下一篇进入 PostgreSQL 的具体能力：

《JSONB、全文检索与事务：PostgreSQL 适合哪些 AI 业务数据？》

参考资料

本文为"码海寻道"原创技术文章。数据库能力与版本持续变化，选型时应结合实际版本、数据量、团队经验和压测结果。