当 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 已推出基于 PostgreSQL 的 AI Agents 开发能力——面向 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 —— 一个原生承担多租户、数据分支与多模态的云上数据底座。

对于三件套的详细能力剖析与协同方式,以及在真实业务场景中的落地路径与工程实践,将在阿里云瑶池数据库微信公众号后续的文章中详解。
欢迎登录阿里云RDS控制台体验RDS PG Agent开发能力。
更多推荐



所有评论(0)