WorkBuddy应用生成背后的数据层:腾讯云PG

1数据库的新用户,是 Agent

9月17日,腾讯 WorkBuddy 发布 5.5.6 版本,上线全栈「应用」生成能力:用户用一句话描述需求,就能生成一个带云数据库、文件存储、注册登录的完整网页应用,免部署,发布即得访问链接。

每一个开启云服务的 WorkBuddy 应用,它的表、它的行、它的用户权限、它未来可能长出来的向量索引,都跑在腾讯云数据库 PostgreSQL 上。

02一句话的背后:一次无人参与的数据库供给

对 WorkBuddy 的用户来说,整个过程被压缩成了一个动作:确认开启云服务,应用就"有了后端"。

但对数据库来说,这个动作在几秒内触发了一整条链路:

  1. 从资源池中分配一个独立的环境,完成初始化;

  2. 拉起对应的数据访问服务,签发一组只属于这个环境的访问凭据;

  3. 建表、建索引、定义行级安全策略(RLS),并把权限声明固化为 SQL;

  4. 对外发布一个可访问的 HTTPS 数据接口,应用立刻可读写。

没有人工开通,数据库拥有了一个不看控制台的用户------Agent。

这不是偶然现象,而是一个正在发生的产业拐点。IDC 预测,全球活跃 Agent 的数量到 2030 年,五年增长近 80 倍,年复合增长率 139%;这些 Agent 每年执行的任务数,将从 440 亿次增长到 415 万亿次(年复合增长率 524%)。Gartner 则预测,到 2028 年,80% 的生成式 AI 商业应用将直接构建在现有的数据管理平台之上 。因此未来新增的应用,绝大部分将由 Agent 生产;而这些应用的数据层,绝大部分会长在已有的数据库上 。于是数据库要服务的对象变了------不再是"几十个由工程师精心设计、长期维护、有明确容量规划的应用",而是"海量、由 Agent 在几秒内生成、绝大多数长期低频、却随时可能突然爆量的应用"。海量的数据库、完全不可预测的负载、全程没有 DBA------这不是"把原来的数据库卖得更便宜"能解决的问题,而是数据库这一层必须重新设计。

03腾讯云数据库 PostgreSQL,不只是"存数据"

腾讯云数据库 PostgreSQL 并非只是存表。WorkBuddy 生成的应用里,有相当一部分是 AI 应用------它们需要语义搜索、需要知识库、需要记住上下文。

这些能力我们没有让用户去拼接一套新的中间件,而是长在同一个 PostgreSQL 实例里:

一个 AI 应用不需要额外的向量数据库、图数据库和记忆存储。 业务数据、向量、图谱、记忆共享同一个实例、同一套 RLS 权限、同一份备份与监控。

04腾讯云 Supabase:同一个 PostgreSQL 的第二种打开方式

如果 WorkBuddy 代表的是"用户完全不感知数据库"的极致形态,那么腾讯云 Supabase (云开发 CloudBase for Supabase 版) 代表的是另一端:开发者要一套完整的、开源的、可迁移的后端。

它建立在同一个 PostgreSQL 之上,把开发者通常需要自己搭建的那一层补齐:

**● REST 服务:**建表即 REST API,前端直连,零后端代码;

**● Auth:**邮箱/手机/社交登录、MFA、SSO,登录即产生标准 JWT,直接驱动 RLS;

**● Realtime:**基于数据库变更的实时订阅推送;

**● Storage:**文件存储与 CDN,权限同样由 RLS 控制;

**● Edge Functions:**靠近用户的边缘计算;

**● Studio:**可视化的表编辑、SQL 与日志管理。

05如果你在做 Vibe Coding 平台,数据库这一层可以交给我们

除 WorkBuddy 外,当 AI 生成应用的速度和规模超出人力运维的边界,后端基础设施本身就必须先为 Agent 而设计------这是所有 Vibe Coding 平台正在遇到的同一道题。如果你正在构建 Vibe Coding 产品、企业内部的 AI 开发平台,或任何需要"为每个应用提供一个后端"的产品,数据库这一层我们可以提供:

**● 多租户资源隔离:**通过 API 批量创建和管理数据库环境,一应用一环境,资源与数据天然隔离,任一应用的异常流量不影响其他应用;

**● 基于凭据的权限收敛:**每个环境签发独立凭据,Agent 直连环境自行完成建库建表,无需平台后端中转,权限边界由基础设施保证;

**● 弹性升降配:**随时独立升降配、升配立即生效,超出额度自动转按量,业务不中断。

Agent 会写出越来越多的应用,这些应用会长出越来越多的表、越来越多的向量、越来越多的记忆。它们需要一个能在秒级内被创建、在无人值守时被隔离、在爆量时被单独升配、在不需要时被回收的数据库。这件事我们已经做了很久。现在,它开始跑在那些由 Agent 批量生成的真实应用背后。让 AI 负责 Coding,让 腾讯云 Supabase (云开发 CloudBase for Supabase 版) 负责后端,让 腾讯云 PostgreSQL 负责数据。

相关推荐
ss2731 小时前
03 -AI时代首先数据库-PostgreSQL发展历史:从伯克利到AI数据库
postgresql
东风微鸣5 小时前
精简 Ubuntu Linux 固件包:每个 N100 节点省下约 450 MB
linux·ubuntu·postgresql
yumgpkpm16 小时前
CDP 7.3.1(Cloudera Runtime 7.3.1)VS Acceldata ODP 3.3.6.4 核心引擎详细版本对比
大数据·hive·hadoop·postgresql·zookeeper·spark·hbase
明日清晨16 小时前
mobaxterm root身份登录Ubuntu
linux·ubuntu·postgresql
有想法的py工程师19 小时前
PostgreSQL【内核】 CBO 优化器的“早停下注”与数学模型失效分析
数据库·postgresql
有想法的py工程师1 天前
PostgreSQL 字符集双重转义击穿 磁盘 I/O
数据库·postgresql
l1t1 天前
DeepSeek总结的PostgreSQL因选择而宽松,因偶然而永久
数据库·postgresql
行业研究员1 天前
Agent Memory降低Token消耗原理解析
数据库·人工智能·oracle·腾讯云·智能体
IvorySQL1 天前
PostgreSQL 日报| PostgreSQL JDBC 安全更新(10 月 10 日)
数据库·postgresql·区块链
IvorySQL2 天前
PostgreSQL 日报|修复截断 zstd 备份检测(10 月 9 日)
数据库·postgresql