AI 时代，为什么 PostgreSQL 正在成为新一代应用的数据库首选？

过去十几年，MySQL 几乎是 Web 开发领域最主流的数据库选择之一。

从传统 PHP 网站，到电商系统、企业管理软件，再到各种 SaaS 平台，MySQL 凭借成熟的事务机制、丰富的生态和较低的使用门槛，支撑了大量互联网业务。

但随着 AI 技术的发展，软件系统正在发生变化。

过去，一个典型的 Web 应用主要处理结构化数据，核心工作是增删改查。现在，一个现代应用可能同时需要管理关系数据、动态 JSON、文档内容、全文索引、向量数据，以及 AI Agent 的执行状态。

数据库面临的问题，已经不只是如何把业务数据存好，而是如何在保证数据一致性的前提下，让这些不同类型的数据协同工作。

这也是 PostgreSQL（以下简称 PG）越来越值得关注的原因。

AI 时代数据库选型的核心变化，不是传统数据库突然失去了价值，而是数据类型、检索方式和应用架构都在发生变化。

对于新一代 SaaS、AI Agent 和现代 Web 应用，PG 正在成为一个更值得优先考虑的默认选择。

一、AI 应用正在改变数据库的职责

先看一个典型的企业 AI 应用。

它需要存储企业、用户、角色、订单等结构化业务数据；需要保存文档、知识片段和模型生成的内容；需要记录 Agent 的任务状态、执行结果和工具调用历史；还需要根据用户的问题，从大量资料中找出最相关的内容。

这实际上包含了几种不同的数据处理需求。

• 关系型数据：强调事务、约束、关联查询和一致性。
• 半结构化数据：需要灵活存储模型输出和动态业务属性。
• 全文检索：需要根据关键词、词项和文本相关性查找内容。
• 向量检索：需要根据语义相似度，从高维向量中寻找相关内容。
• 任务状态数据：需要支持并发更新、状态转换和可靠的业务流程。

传统架构通常会为不同需求分别引入数据库或中间件。这种方式没有问题，但也会带来额外的运维、数据同步和一致性成本。

例如，企业删除一份知识文档时，不仅需要更新业务数据库，还要确保全文索引和向量索引中的相关内容得到清理。用户权限发生变化后，检索系统也必须及时应用新的访问控制规则。

当数据分散在多个系统中，开发团队就需要处理更多跨系统协调问题。

PG 的价值在于，它能够在同一套数据库体系内整合关系数据、JSONB、全文检索和向量检索等能力。

这并不意味着所有系统都应该只使用一个数据库，而是意味着很多应用不必从项目第一天起，就为每一种数据需求分别建设一套基础设施。

减少不必要的架构分裂，是 PG 在 AI 应用时代的重要优势。

二、JSONB：让关系型数据库适应快速变化的业务数据

AI 应用有一个非常明显的特点：输出结构并不总是固定的。

例如，合同审核 Agent 可能返回风险等级、风险条款和修改建议；设备诊断 Agent 可能返回故障类型、异常指标和处理建议；商品分析 Agent 则可能返回卖点、目标人群和营销建议。

这些结果既有共同属性，也有大量随业务变化的专有字段。

如果所有内容都采用固定的关系表结构，每增加一种输出属性，都可能涉及数据库结构调整。如果全部作为普通文本存储，又会失去结构化查询和索引能力。

PG 的 JSONB 提供了更灵活的解决方案。

它将 JSON 以适合数据库处理的二进制形式存储，支持嵌套属性查询、包含关系判断和 GIN 等索引方式。对于经常访问的特定属性，还可以通过表达式索引进行优化。

这意味着，应用可以把稳定的核心属性保留在关系表中，把变化较大的扩展属性存入 JSONB，同时根据实际查询需求建立索引。

这种设计尤其适合 AI 任务结果、Agent 上下文、可扩展的产品属性和动态配置。

当然，灵活不等于没有约束。涉及金额、权限、状态、外键和关键业务规则的数据，仍然应该优先采用明确的字段类型和数据库约束。

另外，MySQL 同样支持 JSON 类型和相关索引机制。因此，PG 的优势不是独占 JSON 能力，而是可以把 JSONB 与全文检索、向量检索及其他数据库能力进一步组合。

三、pgvector：让 AI 语义检索成为数据库的一部分

如果说 JSONB 解决了 AI 数据结构灵活性的问题，那么 pgvector 则让 PG 进入了 AI 应用最重要的数据领域之一：向量检索。

在 RAG 架构中，系统通常会先把文档切分成知识片段，再使用 Embedding 模型将片段转换成向量。

当用户提出问题时，系统将问题转换成向量，通过相似度计算找出相关知识片段，再把这些内容交给大模型生成答案。

传统架构中，业务数据可能存储在 MySQL，向量存储在独立向量数据库，文档检索则可能依赖另一套搜索引擎。

pgvector 允许 PG 存储向量，并执行相似度搜索，支持精确最近邻检索，以及 HNSW、IVFFlat 等近似最近邻索引方案。

这带来了一个重要变化：知识片段、所属文档、租户标识、业务元数据和 Embedding，可以在同一数据库中关联和查询。

例如，系统可以在检索知识片段时，同时考虑租户、文档状态和业务属性，再按向量距离排序。

这种组合减少了跨数据库查询和数据同步的复杂度，也让事务管理、业务关联和检索逻辑更容易统一。

需要注意，向量检索的效果仍然取决于 Embedding 模型、索引参数、过滤条件、数据规模和召回率要求。PG 并不意味着可以无条件取代所有专用向量数据库。

但对于大量企业知识库、智能客服、AI 助手和中小型 SaaS 应用而言，先以 PG 承担关系数据与向量检索，通常是一条值得优先评估的技术路线。

四、全文检索与向量检索融合，才是更实用的 AI 搜索架构

实际业务中的搜索，并不只是寻找语义相似的内容。

当用户搜索一个合同编号、产品型号、客户名称或专有术语时，关键词匹配可能比向量相似度更可靠。

而当用户提出一个自然语言问题时，仅依赖精确关键词，又可能错过表达不同但语义相近的内容。

因此，现代知识检索通常需要结合全文检索与向量检索。

PG 本身提供全文检索能力，可以利用倒排索引等机制进行文本匹配；配合 pgvector，则可以实现关键词召回与语义召回的组合。

在实际架构中，可以分别生成两路候选结果，再通过排名融合或重排序模型形成最终结果。

这使得一个数据库可以承担相当一部分传统业务查询、关键词检索和语义检索任务。

对于中小型 AI 应用，这种整合尤其有价值：系统不必一开始就部署和维护多套独立的检索基础设施。

当然，中文全文检索仍然需要合适的分词配置或分词扩展。如果业务涉及海量文档、复杂搜索分析、极高并发或特殊相关性排序需求，Elasticsearch 等专业搜索系统依然可能更合适。

PG 的意义不是让专业搜索引擎失去价值，而是让更多应用能够在不引入额外系统的情况下，先完成大部分实际需求。

五、真正拉开差距的，是多种数据能力的组合

单独比较某一种功能，往往不足以决定数据库选型。

MySQL 有成熟的事务引擎、JSON 支持、索引机制和高可用生态。对于大量传统 OLTP 系统，它依然是优秀的选择。

PG 的吸引力则体现在能力组合上。

它既能处理传统关系型数据，也能利用 JSONB 管理半结构化内容；既能进行复杂 SQL 查询，也能利用全文检索和 pgvector 处理不同类型的搜索需求；还可以通过 PostGIS 等扩展处理地理空间数据。

这些能力并非都由 PG 独占，但它们能够在统一的数据库内核、事务机制和 SQL 体系中协同工作。

对于现代应用而言，这种统一性很重要。

以企业 AI 助手为例，用户权限、知识文档、向量检索、业务元数据和任务状态之间往往存在紧密关联。如果每一种能力都由独立系统承担，开发团队就必须额外解决数据同步、接口协调和故障恢复问题。

而使用 PG 作为统一数据基础，可以减少这些系统之间的边界。

数据库的竞争力，不仅取决于单项功能有多强，也取决于它能否让不同功能以更低的复杂度协同工作。

这才是 PG 在新一代应用中值得重视的地方。

六、从传统 Web 到现代 SaaS，PG 更适合作为默认技术底座

除了 AI 应用，PG 对现代 Web 系统也具有很强的适应性。

一个 SaaS 平台通常需要处理多租户数据隔离、复杂查询、动态业务字段、统计分析、权限控制和不断演进的业务模型。

PG 的事务能力、约束体系、丰富索引和 SQL 功能，能够为这些需求提供稳定基础。

配合 Go、Java、Node.js 等后端技术，以及 Next.js、Nuxt 等支持 SSR 或 SSG 的前端框架，可以构建一套现代化的 Web 架构。

这里需要厘清一个概念：SSR、SSG 和 SEO 并不是数据库选择的直接结果。它们主要取决于前端渲染方式、页面内容组织和搜索引擎抓取策略。

但数据库的职责，是为这些应用提供稳定的数据模型、可靠的事务处理和高效的数据访问。

当我们同时考虑 SaaS、AI Agent、知识检索和复杂业务查询时，PG 的综合能力就体现出来了。

它不一定在每一项基准测试中都胜过 MySQL，但在需要融合多种数据处理方式的应用中，往往可以减少额外的架构组件。

七、技术选型应该有明确的迁移边界

既然 PG 更适合作为许多新应用的默认数据库，是否意味着所有 MySQL 系统都应该立即迁移？

我认为没有必要。

数据库迁移不是简单替换驱动程序。两者在 SQL 方言、数据类型、索引、事务细节、自动增长机制、执行计划和运维方式等方面存在差异。

如果一个系统运行稳定、业务简单、没有新的检索需求，而且已经形成成熟的 MySQL 运维体系，那么强行迁移未必能够带来足够收益。

更合理的策略是明确三个边界。

第一，新增项目默认采用 PG。

新建的 SaaS、AI 应用、知识库、智能办公系统和现代 Web 产品，优先以 PG 为标准数据库。

这样可以从一开始就统一数据模型、迁移工具、连接管理、监控和备份策略。

第二，核心系统重构时评估迁移。

当系统本身就需要重建数据访问层、调整业务模型和重新设计架构时，迁移数据库的边际成本可能更低。

此时应该结合 SQL 兼容性、业务规模、停机窗口和数据校验方案进行评估。

第三，成熟存量系统按价值决定是否迁移。

对于深度依赖 MySQL 的开源 CMS、接近下线的系统，以及迁移风险明显高于收益的业务，继续使用 MySQL 完全合理。

同时也要看到，PG 并非零维护成本。连接池管理、索引设计、执行计划分析、VACUUM、备份恢复和高可用建设，仍然需要专业的工程能力。

技术标准应当统一，但迁移动作必须服从实际业务收益。

结语：AI 时代，需要重新定义数据库的默认选择

过去，数据库选型更多围绕事务性能、成熟度、生态和运维成本展开。

这些指标今天仍然重要，但已经不足以覆盖新一代应用的全部需求。

AI 正在让结构化数据、半结构化数据、文档内容和向量数据更加紧密地结合。应用不仅需要存储业务记录，还需要围绕这些记录进行全文搜索、语义检索、复杂关联和智能化处理。

在这样的背景下，PostgreSQL 提供了一条值得认真考虑的路线：以关系型数据库为核心，通过 JSONB、全文检索、pgvector 和丰富的扩展能力，统一承载更多类型的数据处理需求。

这并不意味着 MySQL 已经过时，也不意味着 PG 可以替代所有专业数据库。

真正的变化在于：当我们为未来几年设计新系统时，不应该再仅仅沿用过去的默认选择。

存量系统尊重历史，新建系统面向未来。对于新一代 SaaS 与 AI 应用，PostgreSQL 值得成为优先选择的默认数据库。

技术选型不是追逐某个热点，而是选择一套能够在未来持续演进、降低架构复杂度，并且适应新业务形态的基础设施。

AI 时代，PG 的价值正在于此。