当80%的数据库由AI自动创建：我们需要一个什么样的PostgreSQL？

作者：宇彭

01 前言：Agent 需要的不只是向量库

Agent 应用正在重新定义数据库的角色。

过去谈 AI 应用，视线大多停在模型调用、向量检索、RAG 与提示词工程上。真正进入生产后会发现，向量库只是 Agent 数据体系的一角——Agent 还要管理任务状态、权限边界、执行结果和异常记录，同时直面提示注入、数据污染等新型风险面（arXiv 2503.05445 研究显示，仅 0.44% 的污染数据即可让针对数据库的投毒攻击成功率达到 79.41%）。

从行业趋势看，PostgreSQL 已成为 AI 与 Agent 场景的主流选择。Databricks 收购 Neon 的官方公告披露，Neon 平台上超过 80% 的数据库已由 AI Agent 自动创建，而这一比例在 2023 年 10 月还只有 0.1%——不到两年，数据库的建库方式正在被 AI 重写。

与此同时，Stack Overflow 2025 开发者调查显示，PostgreSQL 采用率达到 55.6%，同比提升 7 个百分点，成为开发者中使用最广的数据库。

回到开头的问题——当 80% 的数据库由 AI 自动创建，我们究竟需要一个什么样的 PostgreSQL？ 基于阿里云内部 Agent 应用的实践经验，Agent 场景对数据底座提出了三个新要求——多租户隔离能力、秒级数据分支能力、多模态数据管理能力。这三个方向，也构成本文后续几节的核心议题。

作为阿里云瑶池数据库家族面向事务型 Agent 场景的核心产品，RDS PostgreSQL（以下简称 RDS PG）继承了 PostgreSQL 在事务、生态与扩展能力上的长期积累，围绕上述场景提供了面向生产环境的增强能力。

02 数据库基础能力：RDS PG 的综合优势

Agent 系统首先要能稳稳地管理状态。

一次 Agent 请求往往会拆成多个步骤、调用不同工具，数据库需要记录任务进度、执行结果与重试状态，避免同一操作被重复触发；与此同时，Agent 还会源源不断地产生 prompt、模型响应、工具参数、trace metadata 等结构不固定的数据，成为故障恢复、问题排查与日常运维的第一手素材。

PostgreSQL 可以把这些规则固化在数据库层：事务与并发控制避免状态冲突，唯一约束、外键与检查约束限制错误数据写入，jsonb 灵活承接结构不固定的数据并结合索引查询；DDL 可纳入事务、支持随事务回滚，WAL、PITR 与复制能力为数据恢复和容灾兜底。

RDS PG 基于云上高可用架构兼容开源 PostgreSQL 生态，通过备份恢复、监控报警、故障切换、在线大版本升级等企业级能力提供稳定可靠的数据库服务，并提供跨可用区高可用与任意时间点（PITR）恢复能力，帮助用户为 Agent 应用构建高可用、可观测、易运维的数据底座。

接下来三节，聚焦 Agent 场景下 RDS PG 的三项关键增强：多租户隔离、数据分支、多模态检索。

03 多租户：AI 数据库的租户隔离能力

Agent 应用几乎必然会演进为 SaaS 形态。

一个 Agent 平台可能同时服务多个企业、多个团队、多个用户。以海外 Vibe Coding 平台为例，Lovable 官方披露 2025 年年中平台每天新建的用户项目已超过 10 万个，每个项目都要求独立的数据库、认证与存储；国内 Agent 平台面对的租户规模同样在快速膨胀。不同租户之间的数据要隔离，权限边界要清晰，访问行为也需要具备可审计性。

PostgreSQL 支持多种多租户模式，包括 shared table + tenant_id、schema per tenant、database per tenant。权限层面，可以通过 role、grant、默认权限、对象级权限和 RLS 进行隔离，覆盖 database、schema、table、column、function、sequence 等对象，便于构建细粒度的访问控制。轻量场景可以用共享表或独立 schema；企业级 Agent 平台更适合 database per tenant——每个租户独立数据库，隔离边界更明确，备份恢复、迁移升级、资源统计与故障隔离都能落到租户维度。

面向企业级 Agent 平台典型的 SaaS 多租户形态，RDS PG 提供以下增强能力：

• 缓存淘汰优化：面向大量表对象和多租户访问场景，优化系统缓存管理，降低多表、多库场景下缓存膨胀和频繁失效带来的性能影响。
• PgBouncer 连接池：面向大量租户和大量短连接场景，通过连接复用降低后端连接数量和进程开销，提升高并发访问下的连接管理效率。
• SQL 限流：面向多租户共享实例场景，对高并发、重负载或高消耗 SQL 进行访问控制，降低单个租户或单类请求对整体实例稳定性的影响。
• 快速大版本升级：面向 database per tenant 等多库场景，降低大量数据库逐库升级带来的时间成本，提升多租户实例的大版本升级效率。
• database per tenant 隔离增强：针对 database per tenant 模式，RDS PG 支持限制普通租户仅可见与自身相关的 database 和 role，减少跨租户信息暴露风险，帮助用户构建安全、稳定、可管理的多租户 Agent 平台。

从初创 Agent 应用到企业级 Agent 平台，多租户模式可在同一 RDS PG 实例内自由组合、按需升级。

04 数据分支：AI 数据库的试验与沙箱能力

Agent 时代的数据环境会更强调可复制、可试验和可回退。

很多 Agent 任务并不适合直接修改生产数据。更稳妥的方式是先创建一个沙箱环境，让 Agent 在其中执行 SQL 或代码，比较执行前后的变化，再决定是否影响生产——自动化程度越高，这种“先试运行、再确认”的能力就越重要。数据分支同样适用于开发测试、灰度验证、回滚恢复、迁移演练，也可以为不同 Agent 提供隔离工作区。

传统 dump-restore 方式在数据量增大后，副本创建会从秒级劣化到分钟级甚至小时级，无法支撑 Agent 高频“创建—使用—销毁”的迭代节奏。PostgreSQL 18 新增的 file_copy_method 参数结合 XFS reflink、Btrfs、APFS 等写时复制文件系统，使 CREATE DATABASE 退化为一次文件克隆操作——近乎瞬时完成、初始磁盘占用接近零。

RDS PG 基于文件系统 clone 与阿里云 ESSD 云盘快照的写时复制架构，通过 秒级 CREATE DATABASE 提供数据分支能力，将数据分支创建时间从分钟级降至秒级、初始磁盘占用接近零、按变化数据块计费。这种能力适合 Agent 沙箱、灰度验证、回滚点和租户级测试库等场景；结合 database per tenant，平台可对单个租户做更细粒度的测试、恢复和升级，让 Agent 高频“创建—使用—销毁”的迭代节奏在生产环境中真正跑通。

05 多模态：AI 数据库的统一数据入口

Agent 处理的数据不再只是文本。

它可能需要处理业务表、文档、图片、音频、视频、地理位置、时间序列和向量等多种数据类型，不只是“检索一段文本”，还要理解这些数据之间的关系，并在权限允许的范围内执行动作。

PostgreSQL 适合承接这些数据的基本信息、索引、权限与关系：普通表保存业务对象和状态，jsonb 保存模型输入输出和工具参数，全文检索处理文档内容，pgvector 保存 embedding，并可以结合 AGE 图插件管理实体关系。

面向向量检索场景，RDS PG 在开源 pgvector 的基础上，围绕索引压缩、查询加速和执行器架构等关键路径进行了深度优化，提供以下增强能力：

• IVFFlat RaBitQ 量化：将 RaBitQ 量化技术应用于 IVFFlat 索引，在实现 32× 压缩的同时将查询性能提升 20×，让海量向量检索兼顾轻量存储和快速响应。
• HNSW 多比特 RaBitQ 量化：针对 HNSW 索引内存开销大的问题，实现多比特 RaBitQ 量化方案，在 4× 压缩、降低内存占用的基础上，查询性能进一步提升 50%，在高召回率场景下兼顾内存效率与查询速度。
• 向量检索内核优化：针对向量检索的查询执行路径和索引构建过程进行精细化调优，减少关键路径上的冗余开销，提升整体吞吐并降低响应延迟。
• 向量与标量混合检索：优化 PostgreSQL 执行器框架，支持向量相似度与标量过滤的混合检索，在一次查询中完成“语义相近 + 条件过滤”的复合搜索，提升查询表达能力和结果准确性。

以千万级向量索引为例，相比常规 HNSW 索引，索引空间从 689 GB 压缩至 16 GB（32× 压缩），索引创建时间从 4 天 1 小时缩短至 4 小时 23 分（23× 提速），写入延迟从 469 ms 降至 6.4 ms（73× 提升），Top100 查询延迟从 1789 ms 降至 359 ms（5× 提速），召回率损失控制在 1% 以内，并支持最高 16000 维向量索引，可适配多模态 embedding 场景。

面向图数据和关系分析场景，RDS PG 在社区版本 Apache AGE 的基础上提供以下增强能力：

• 图查询与 DML 优化：对图查询和 DML 热点路径进行性能优化和工程增强，通过减少查询冗余投影和执行开销、优化点边更新删除路径，在兼容 openCypher 的基础上实现百倍查询性能与 10 倍 DML 性能提升。并积极与社区贡献feature。
• 图 RAG 与本体建模：支撑图 RAG 和基于本体论的 Agent 知识建模，将结构化数据、实体关系、语义网络、规则依赖和推理链路统一沉淀在 RDS PG 中，为 Agent 提供可检索、可解释、可更新、可推理的企业级数据底座。
• 行业场景落地：图能力已在智能驾驶数据挖掘、财务经营分析、零售业务诊断、地产数据治理和智能运维故障诊断等场景中落地验证，帮助企业将分散在业务系统、数仓、日志平台和配置中心中的对象与关系转化为 Agent 可理解、可推理的业务语义网络。

06 结语：RDS PG 作为 Agent 的核心数据底座

Agent 时代需要新的核心数据底座。

综合来看，Agent 应用既需要可靠的事务一致性和运维能力，也需要面向多租户、数据分支和多模态数据管理的扩展能力。RDS PG 在 PostgreSQL 基础能力之上，进一步增强了多租户隔离、数据分支、向量检索和图关系分析等能力，是当下 AI Agent 应用云上数据底座的重要选项。

从数据底座，走向 Agent 开发平台。 但数据底座不是终点。生产级 Agent 应用需要的是一整套开发平台，而不只是一个数据库。阿里云 RDS PG 现已推出Agent 开发能力——面向 AI Agent 场景，以 RDS PostgreSQL 为数据底座，提供BaaS服务、Knowledge Graph、Agent Runtime三大能力的开放、高效的一站式开发环境。配套的三大核心组件我们简称为“Agent 三件套”：

• Supabase——面向应用层的 BaaS 后端，提供 Auth、Storage、Edge Function、Realtime 等模块，让 Agent 生成的全栈应用可以直接上线，无需额外部署数据接入层；
• Knowledge Graph——面向语义层的知识中枢，提供知识库 RAG、Ontology 本体建模、Skill Hub 能力沉淀三重能力，让 Agent 理解业务关系、约束行为边界、以确定性推理替代概率猜测；
• In-DB Agent Runtime——面向执行层的运行时环境，Sandbox 与 Edge Function 双模式覆盖长时任务与事件触发任务，让 Agent 具备贴数据的动作执行能力。

三件套共同建立在 RDS PG 之上，数据不搬家、SQL 方言不切换、心智模型不漂移。Agent 团队可通过一个 RDS PG 实例覆盖向量检索、图关系、对象存储、函数计算、认证鉴权等多项能力，替代传统架构中的多套独立组件，从根本上消除跨系统同步链路与一致性负担。

这，就是我们理解的、AI Agent 时代的 PostgreSQL——一个原生承担多租户、数据分支与多模态的云上数据底座。

对于三件套的详细能力剖析与协同方式，以及在真实业务场景中的落地路径与工程实践，将在本公众号后续的文章中详解。

您也可以点击 https://rdsnext.console.aliyun.com/rdsSupabase/cn-hangzhou

前往阿里云控制台体验RDS PG Agent开发能力，或扫描下方二维码加入 RDS PG 技术交流群，获取更多技术信息与客户实践案例。