PG 成了 AI 数据库最大赢家

先说背景, 今天如果你走进一家处于技术前沿的科技公司或头部企业研发中心，会发现一个普遍的变化：代码不仅是工程师在敲，各种各样的 AI Agent（智能体）正在以毫秒级的速度批量编写、测试并提交代码；日常系统的性能巡检与故障排障，也不再单纯依赖 DBA 的肉眼盯盘，而是由具备推理能力的自主运维 Agent（如 DBAgent、DBClaw）全天候自主感知、动态决策并下发治理策略。

AI 正在经历从“问答式辅助工具”到“自主行动智能体”的历史性跨越。智能体不仅能理解自然语言，更拥有了自主规划任务链路、调用工具（Tool Calling）、并在业务底座上并发读写真实数据的能力。智能体集群正在成为企业最核心的生产力单元。

然而，当众多团队雄心勃勃地将这支自主智能体大军接入企业核心业务时，后台却接连撞上了冰冷的现实：

• 一个自动化流水线并发唤起数十个 Code Agent 进行模块构建已经是家常便饭的事，但可能因为无法及时申请不到隔离的数据库环境而瞬间卡死；
• 某个执行复杂数据清洗的 Agent 因为大模型语义“幻觉”，在没有约束条件的情况下批量污染了核心业务表，DBA 紧急拉取数小时前的日志重放全库回档，生产业务全线中断；
• 突发的跨系统协同任务在几分钟内打出上万 QPS 的推理与写入脉冲，随后陷入漫长的数十小时沉睡，企业却不得不为这套高配常驻规格按月支付巨额空转账单；
• 为了给 Agent 维持跨会话的“长期记忆”，架构师在传统关系库外硬生生搭了一套专用向量库和图数据库，却陷入了双写不一致、多跳关联推理断层、以及敏感记忆越权串扰的泥潭。

问题的本质并不在大模型本身，而在底座。我们正在用一套原本为“人类操作者”设计的传统数据库，强行承载成百上千个“自主运行的智能体”。

传统数据库建立在“人类工程师”的假定之上：操作有审批流程、行为边界清晰可预期、并发规模与人类工作节奏对齐、Schema 变更谨慎而低频。而 AI Agent 的交互是海量突发的、行为是探索试错的、调用是不可完全预知的。这一代际跃迁，让现有数据库结构性地暴露出产品与用户的供需鸿沟、容错缺失、成本空转与多模态孤岛四大裂痕。

面对这场智能化生产力重构，数据库底座必须完成从“被动等待调用”到“主动适配智能体”的进化。

AI 时代究竟需要什么样的数据库？腾讯云自研云原生数据库 TDSQL-C PostgreSQL（以下简称 TDSQL-C PG）给出了清晰的答案。

供给之困：当并发调用从人类工程师变成自治智能体，如何跨越开库鸿沟？

在传统研发流程中，开发者需要一个数据库实例，标准链路是：提交审批单 ➔ 安全合规审查 ➔ 架构师评估容量 ➔ DBA 手动或脚本下发开通 ➔ 分配白名单与初始账号。这个周期短则几十分钟，长则两三天。对于人类团队以“周”为迭代周期的敏捷开发，这套机制行之有效。

但当调用主体切换为自主智能体时，这套人工审批机制瞬间瓦解。

在真实的 Agentic Workflow 中，智能体的生命周期极其短暂且高度动态：

• 一个持续交付（CI/CD）流水线可能同时触发 100 个自主测试 Agent，每个 Agent 都需要一个包含最新生产数据快照的隔离数据库来验证逻辑；
• 一个多智能体协作平台可能会在几分钟内根据任务队列，动态生成数十个垂直领域的分析 Agent，每个 Agent 只需要运行 3 分钟即可完成特定报表抽样；
• 如果让所有 Agent 共享单一测试库，多 Agent 并行写入产生的数据污染、主键冲突、脏读幻读将直接导致整套自治逻辑崩溃；而如果为每个 Agent 都预先常驻一个独立数据库，运维复杂度与资源开销将成为天文数字。

根因：有状态单体绑定的“重型物理供给”

传统数据库在架构上计算节点与物理存储深度绑定。创建一个新的数据库实例，意味着底层要经历物理卷分配、存储块格式化、初始化数据目录（initdb）、配置参数、建立高可用主备复制对。这是一套重量级的有状态分配过程，秒级动态伸缩在物理层面上根本无法成立。

TDSQL-C 的破局：Database-per-Agent 沙箱与即用即焚

TDSQL-C 采用自研的计算与存储彻底解耦架构。计算节点完全无状态，底层由高弹性云原生存储池统一兜底。基于这一天然底座，TDSQL-C 为 AI Agent 打造了全新的运行沙箱（Security Sandbox）体系：

[任务派发] ➔ [秒级拉起独立 DB 沙箱] ➔ [Agent 自治执行] ➔ [验证/合并] ➔ [即用即焚·自动销毁]

1. Database-per-Agent 物理级安全隔离：系统为每个运行中的 Agent 动态分配独立的数据库沙箱环境。各环境之间数据物理级隔离，彻底杜绝多租户或多 Agent 间的越权读写风险。一人百 Agent，也能一人百环境。
2. 自动化秒级供给：通过与腾讯云 DBClaw、DBAgent 运维生态及云 API 深度整合，Agent 在接收到任务的瞬间，调用 API 即可在 1 秒内 获得专属独立数据库凭证，完全抹平了人工审批的等待周期。
3. 即用即焚（Ephemeral Sandbox）：当 Agent 任务执行完毕，该沙箱环境与临时产生的数据被秒级自动销毁。不仅不留任何死数据与安全合规隐患，更将全局计算与存储资源利用率拉升至极致。

容错之问：大模型难免有“幻觉”，改坏了生产数据拿什么当“后悔药”？

AI 开发者最普遍的焦虑，莫过于大模型的“不可控性”与“幻觉”。

人类工程师在写 UPDATE 或 DELETE 语句时，有严格的代码评审（Code Review）和测试验证机制。但当智能体自主生成 SQL 并直接执行时，概率性的理解偏差是不可消除的客观规律：

• 一个原本负责“归档前年已退订客户”的智能体，可能因少拼装了一个日期子句，瞬间将线上核心客户表全量重置；
• 一个在执行自主代码重构（Vibe Coding）的 Agent，在进行多次 Schema 自动迁移尝试后，将数据库的索引拓扑与约束关系完全破坏。

在传统数据库上，发生此类事故的处理代价是灾难性的。由于关系数据库强依赖 ACID 事务与写前日志（WAL），一旦破坏性事务提交，DBA 只能启动时间点恢复（PITR）：先挂起生产访问，从远程对象存储拉取数十 GB 甚至数 TB 的物理备份基线进行解压还原，随后串行重放数小时的增量 WAL/Binlog 日志推演至事故发生前那一秒。

全库恢复通常耗时数小时，且全局业务被迫中断。这种高昂的试错代价，让许多企业在面对 Agent 落地时举步维艰——没有人敢把核心库的读写权限真正放给智能体。

根因：原地覆盖（In-Place）更新与日志强串行机制

传统数据库以单机数据页（Page）为单位组织数据，数据修改直接在内存缓冲池中就地更新（In-place update）并生成物理日志。若想对整库的历史状态做时间切片，必须依赖昂贵的日志串行扫描重放，缺乏针对特定瞬间进行“零拷贝冻结与多版本分叉”的底层存储能力。

TDSQL-C 的破局：Branch 极速数据分支，“数据的 Ctrl+Z”

TDSQL-C 给出的解法，是在存储底座层面直接提供类似于 Git 的分支能力——Branch 数据分支。

1. 基于 Copy-on-Write（写时复制）的极速克隆： TDSQL-C 底层将日志流与数据页分离管理。当 Agent 需要一个试验环境或准备执行复杂数据变更时，系统直接在底层存储快照上打点，新分支仅复制指向该数据页的元数据指针，不进行任何全量物理数据拷贝。 无论主库是 100GB 还是 PB 级 的海量数据规模，克隆操作均在 1 秒左右完成，且初始状态下产生零额外存储开销。
2. 独立 WAL 物理级隔离，主库性能 0% 损耗： 分支拉起后，Agent 可以在分支上拥有完全的读写权限。分支上产生的所有数据写入与结构变更，全部走该分支独立的 WAL 写入流，底层 PageStore 仅对发生修改的页面进行增量写入。 这意味着，即使 Agent 在分支上执行高消耗的批量更新或发生了严重的死循环慢查询，对线上核心主库的性能影响完全是 0%。
3. 无限制状态存档与无损丢弃： 支持创建无限制数量的数据分支。在 AI 模型强化学习微调、多策略横向对比以及 Agent 复杂决策链条中，每推进一个关键阶段都可以打下一个数据分支作为“状态检查点”。 Agent 执行成功，按需将结果或 Schema 变更合并；Agent 产生幻觉搞乱了数据，只需轻点删除该分支即可，主库连一毫秒都不受影响。

在美团等多环境高频联调的工程实践中，借助 TDSQL-C 这一数据分支能力实现研发沙箱环境秒级隔离，联调与排障效率整体提升了 300%。

成本之困：脉冲式爆发与漫长沉睡并存，如何终结空转买单的成本黑洞？

观察典型的 AI Agent 工作负载，你会发现它与传统互联网 Web 业务有极大的差异：

如果采用传统数据库的预留模式（Provisioned），为支撑 Agent 突发爆发期的高并发需求，企业必须常驻购买高规格的计算与内存实例（如 32 核 128GB）。而在 Agent 大量沉睡的长尾周期内，CPU 利用率长期在 2%~5% 徘徊。面对成百上千个面向不同业务细分场景的长尾 Agent，这种“为空气买单”的成本开销没有任何一家企业能够承受。

根因：计算资源分配的静态化与不可伸缩性

传统数据库节点由于持有内存 Buffer Pool 缓存、连接状态以及常驻后台进程，不支持在没有外部请求时完全关闭自身；即便具备横向只读扩容能力，拉起一个新节点往往也需要数分钟，根本赶不上 Agent 以秒为单位的计算洪峰。

TDSQL-C 的破局：Serverless 负载对齐与 Scale-to-0

TDSQL-C 原生基于 Serverless 架构构建，将资源的生命周期控制精确下沉至毫秒级：

1. 负载对齐，消除预留浪费：TDSQL-C 实现了计算切片与存储容量的解耦按需计费。计算资源的分配曲线能够毫秒级贴合 Agent 真实的计算负载曲线，彻底告别“为了 5% 的波峰时间，常驻付费 95% 空闲时间”的尴尬局面。
2. 闲时归零（Scale-to-0）：当 Agent 任务完成、客户端连接池彻底断开后，TDSQL-C 计算引擎能够自动缩容至零，停止产生任何计算计费，仅保留低成本的对象存储费用，使长尾 Agent 的持有成本趋近于零。
3. 秒级弹起，冷启动 ≤ 1 秒：对于 Serverless 数据库，最大的技术壁垒在于“冷启动时间”。如果弹起需要半分钟，Agent 的实时任务将全部超时。TDSQL-C 得益于无状态轻量化引擎底座，将冷启动时间死死压制在 1 秒以内。当上游网关或 Agent 发送第一条 SQL 的瞬间，引擎已就绪响应，完美化解突发计算脉冲。

记忆之困：Agent 的长期知识究竟放哪？“拼凑式”外挂向量库已到极限

大模型天生是无状态的（Stateless），其记忆受限于上下文窗口（Context Window）的长度与高昂的 Token 成本。为了让 Agent 拥有连贯的专业认知与长期记忆，近两年业界普遍采用“拼凑式架构”：在既有的关系数据库旁边，外挂一个独立的开源或商业专用向量库，甚至再挂一个独立的图数据库。

但在大规模生产实践中，这种“拼凑式架构”正在变成架构师的噩梦：

1. 数据孤岛与双写一致性破裂：业务数据留在关系库，向量与元数据写入外挂向量库。两者之间缺乏分布式事务保障，一旦写入中途失败，就会出现“关系库有订单，向量库查不到”或者“向量库检索命中，回表查询早已被物理删除”的数据漂移。
2. 内存成本黑洞：传统向量索引（如基于内存图结构的 HNSW）要求将全量高维向量常驻 RAM。在万级、亿级记忆资产场景下，单是维持向量索引所需的内存服务器集群开销，就已经超出了模型调用的成本。
3. 多跳拓扑推理盲区：单靠向量的“余弦相似度”只能做模糊语义匹配，根本无法理解严密的实体拓扑网络。例如在金融风控或运维诊断中，查询“受影响微服务的上下游依赖，且该节点上个月有过类似宕机记忆”，纯向量检索立刻失效。
4. 多 Agent 记忆越权串扰：缺乏原生细粒度的行级权限隔离，在多用户、多智能体并行调用时，极易发生 Prompt 注入攻击或跨租户记忆窥探，造成重大合规风险。

根因：存储引擎在数据模型上的烟囱式分立

长期以来，数据库界习惯于“一种模型造一个专用系统”的垂直烟囱思路：关系型存 TP、列存做 AP、向量存专用向量库、图存图引擎。这导致应用层不得不充当繁琐的“数据搬运工”，数据在网络间反复传输，丧失了事务统一性与计算局部性。

TDSQL-C 的破局：Agent Memory 金字塔与 One Database 统一闭环

面对记忆与知识存储的命题，腾讯云在 PostgreSQL 强大的多模态扩展底座之上，给出了从记忆建模到库内执行的完整全栈方案。

1. 结构化记忆分层：结合 tencentdb-agent-memory 与 Mem0

智能体的记忆绝不应该是一堆毫无章法的原始对话碎片。结合腾讯云在 GitHub 开源的 tencentdb-agent-memory 规范与 Mem0 最佳实践，Agent 记忆中枢被提炼为清晰的四层金字塔：

• L0 · 原始对话流水（Conversation Stream）：完整保留每轮对话的 Token、调用入参与执行日志，作为不可篡改的基础凭证与底层审计基线；
• L1 · 原子事实与规则（Atom Facts）：从原始交互中实时抽取的确定性实体属性、系统参数、约束条件与操作产物；
• L2 · 场景与工作流（Scenario Canvas）：利用 Mermaid 符号化语法将复杂业务状态流转编码为任务画布，Agent 不再是在盲目搜文本，而是在确定性的状态转移图谱上进行推理导航；
• L3 · 人格与偏好（Persona & Profile）：提炼用户和系统的最高原则、业务偏好与长期习惯，作为 Agent 行为的顶层约束。

在安全性上，底座深度利用 PostgreSQL 原生的行级安全控制（Row-Level Security, RLS）。在多 Agent 协同体系中，所有 Agent 物理共用一张高吞吐记忆宽表，但底层通过 tenant_id 与 agent_id 自动注入行级隔离策略。各智能体既能基于全局权限读取共享的行业公理库，其私有记忆又受到硬件级严格保护，彻底防止记忆污染与信息泄漏。

2. One Database 方案：数据不出库，一体化闭环

TDSQL-C 践行“计算向数据靠拢”的 One Database 哲学——数据不出库，在一套数据库底座上无缝闭环实现事务处理、向量检索、图查询与库内大模型推理：

• pgvector + DiskANN 磁盘友好索引： 突破传统内存索引（HNSW）的容量天花板，TDSQL-C PG 深度集成了基于磁盘优化的 DiskANN 近似最近邻检索算法。它将高维图索引结构持久化到 SSD 与分布式存储，仅在内存中保留轻量级路由压缩图。 在海量高维向量规模下，DiskANN 能在大幅压降内存成本的同时，保持 99%+ 的超高召回率。更关键的是，开发者可以通过一条标准 SQL，无缝实现“结构化标量过滤 + 向量相似度混合检索”（如 WHERE tenant_id = 101 AND status = 'active' ORDER BY embedding <=> query_vec LIMIT 10），杜绝了跨系统双写与回表延迟。
• Apache AGE 库内图引擎： 直接在同套数据库内实现图模型与关系模型的深度互通，全面支持标准 OpenCypher 查询语言。Agent 可以直接利用图查询语句挖掘复杂的实体依赖链条与多跳调用路径，真正具备“看清上下文全局拓扑”的深层认知。
• DuckDB 嵌入式 AP 实时加速： 为了应对 Agent 在执行决策时对数万行历史记录或日志指标的即时聚合分析，TDSQL-C PG 创新性地在计算节点内嵌了 DuckDB 向量化执行加速器，配合存储底座的列存格式，直接在库内实现轻量级 HTAP。复杂统计秒级出图，无需建立笨重的外挂数仓。
• tencent_ai 库内大模型直调： 过去，Agent 做数据分析需要把数据库里的海量行拉取到应用端，拼装成 Prompt 送进大模型；而通过 tencent_ai 扩展，开发者可以在 SQL 语句中直接调用大模型推理能力：

  SELECT
      ticket_id, 
      tencent_ai.chat_complete(
  model := 'hunyuan-standard', 
  prompt := '分析该故障描述的核心根因并输出建议：' || error_log
      ) AS root_cause_analysis
  FROM system_incident_logs
  WHERE created_at >= NOW() - INTERVAL'1 hour';
  

   敏感数据全流程留在数据库安全防火墙内部，消除端到端网络传输时延，彻底保障核心商业资产的合规安全。

协议之问：异构生态交织，智能体该以什么语言与数据库对话？

当大模型开发者习惯了使用 Python、Node.js 配合 LangChain、Dify、Cursor 等 Agent 研发工具链时，传统的 JDBC 驱动、长连接池配置以及手写复杂的 SQL DDL/DML，正在成为阻碍应用快速落地的摩擦力。

现代 Agent 的生态呈现显著的多样性：

• 桌面端与 IDE 辅助 Agent（如 Cursor）遵循开放协议进行上下文注入与工具发现；
• 边缘无状态计算（Serverless Function）倾向于使用最通用的 HTTP/JSON 进行资源操作；
• 企业级 ERP 与核心财务系统则必须坚守 ACID 强一致性的关系型 SQL 标准。

TDSQL-C 的多协议统一网关

TDSQL-C 在接入层实现了全场景的多协议原生兼容（Multi-Protocol Access），同一套数据底座，三种接入协议无缝并存：

1. MCP 协议（Model Context Protocol）：面向 AI Agent 时代设计的标准模型上下文接口。TDSQL-C 能够直接作为标准化 MCP Server 接入各类 Agent 编排系统，大模型无需学习复杂的方言，即可自主感知库内 Schema 元数据、自主调用检索与分析能力。
2. REST 协议（基于 PostgREST）：底层内置 PostgREST 协议栈，自动将数据库中的表、视图和存储过程映射为符合 OpenAPI 规范的标准 RESTful HTTP API。在无代码（NoCode）或前端轻量 Agent 场景下，开发者不需要编写任何后端中间层，几行 HTTP GET/POST 即可完成数据交互。
3. SQL 协议（100% 兼容 PostgreSQL）：完整保持与原生 PostgreSQL 100% 的语法与生态兼容。现有的 BI 报表、运维监控工具（如 pgAdmin、Grafana）以及存量业务系统可以平滑对接，成熟的 DBA 经验得到全面保留。

架构坚守：TDSQL-C AI-Native Storage 是如何炼成的？

支撑起上述极速分支、秒级沙箱、Scale-to-0 以及 One Database 多模态闭环的，是 TDSQL-C 全新演进的 AI Native Storage 存储底座。

整个技术底座自下而上遵循高内聚、弱耦合的现代化云原生体系：

1. 存算完全分离与无状态计算层

计算节点分为负责事务处理与 WAL 生成的 RW 读写主节点，以及按需弹性伸缩的 RO 只读节点集群。计算节点本身不持有持久化数据页，节点间通过内存页面快速共享技术避免脏页竞争，使得计算节点的故障切换（Failover）与弹性缩容能在秒级完成。

2. 3AZ 全对等写入与零数据丢失（RPO=0）

在数据持久化层，TDSQL-C 跨 3 个可用区（Availability Zone）部署对等的存储节点：

• LogStore（日志持久层）：针对写前日志（Redo Log）进行独立优化，事务提交时日志并行多副本强同步落盘，确保在任何单可用区故障时，数据零丢失（RPO = 0），故障切换时间 RTO ≤ 60 秒，彻底消除性能毛刺与抖动。
• PageStore（页面存储层）：突破传统固定块限制，采用行列混存技术。可用区内同时维护服务于在线高并发事务（TP）的高速行存页面，以及服务于复杂检索与 AP 加速的高压缩比列存页面。
• 对象存储 COS 底座分层：冷数据、历史归档快照自动沉降至低成本的对象存储 COS，具备几乎无限的横向扩展能力，存储上限可达 PB 级，免去了传统 DBA 频繁分库分表的架构重构梦魇。

在面对这轮席卷全球的 AI 变革时，技术决策者往往面临一个痛苦的抉择：为了拥抱 AI，我是必须抛弃过去十几年积累的关系型数据库资产、去采购一堆昂贵而前途未卜的专用 AI 数据库，还是能够平滑延展？

针对这一核心命题，腾讯云在本次全新架构发布会上，给出了极其明确的演进路径：“一个 PG 生态，两大形态——从 AI 就绪到 AI 原生”。

这两大形态绝不是孤立割裂的产品，而是同源同根、互为接力的演进连续体：

1. 第一形态：RDS PG（定位：AI 就绪） 对于绝大多数拥有庞大存量业务与核心生产库的企业，重构技术栈的风险与成本是不可接受的。RDS PG 致力于让存量客户“零改造、零迁移”即刻拥有 AI 能力。通过在成熟稳定的 PG 内核上叠加 Mem0 记忆管理、pgvector 向量检索与 AGE 图引擎，让企业在不破坏既有业务的前提下，迅速完成智能化试点与 AI 赋能。
2. 第二形态：TDSQL-C PG（定位：AI 原生） 对于今天从零开始构建智能体系统、重构业务流的创新团队与企业级 AI 原生应用，TDSQL-C PG 则提供了生产级、全弹性、高安全、高容错的下一代基础设施底座。它的 Branch 分支机制、Serverless Scale-to-0、多 Agent 沙箱以及多协议接入，专门为了承载大模型与自主智能体的严苛挑战而生。

两者共享完全一致的 PostgreSQL 技术栈、工具链、生态兼容性与开发经验。 开发者无需在专用向量库、专用缓存库、关系主库之间陷入技术栈推倒重来的认知内耗，而是可以在同一个生机勃勃的 PG 生态中，随业务深度平滑过渡。

终局推演：AI 时代需要什么样的数据库？

回到最初的时代命题：AI 时代到底需要什么样的数据库？

过去四十年，数据库的演进始终在回答一个问题：如何让计算机更高效、更安全地处理人类写入的数据。 从早期的行存表，到分布式分库分表，再到云托管实例，系统优化的核心假设都是“人在写 SQL，人在做审批，系统按既定逻辑运行”。

但在 2026 年的今天，这个基本假设已被彻底打破。调用数据库的主力正在变成自主规划、带概率性幻觉、脉冲式爆发的智能体集群。

在这一历史性拐点上，AI 时代的数据库必须具备四重特质：

1. 它必须具备极强的容错弹性：大模型的探索不能以污染生产为代价，数据库必须把试错成本降为零（Branch 1 秒克隆，数据自由回滚）；
2. 它必须具备极致的敏捷供给与沙箱隔离：为海量 Agent 提供秒级的独立运行空间与即用即焚机制（Database-per-Agent）；
3. 它必须具备与突发脉冲对齐的成本结构：呼之即来，挥之即去，闲时不费分文（Scale-to-0，冷启动 ≤ 1 秒）；
4. 它必须具备消灭系统割裂的融合能力：关系、向量、图、分析与大模型在库内闭环，让数据资产安全留在库内（One Database）。

TDSQL-C PostgreSQL 用云原生与 AI 原生的双重架构，将这些要求转化为了生产级的工程实践。它不仅是一座连接过去关系资产与未来智能体生态的坚实桥梁，更向整个行业清晰地宣告：数据库不必走向碎片化，智能体时代的统一数据底座，已经就绪。