做一个“健身打卡”应用，你会怎么做？在以前你可能要先画页面、写代码、搭后端、配服务器，再考虑数据库和上线。
现在可以很快地完成这个任务，你可以直接让豆包来做。只需要和豆包说：“请帮我做一个带登录功能的健身记录打卡系统，需要能够注册、登录、并记录每天的各种不同运动情况，适合手机浏览。”
豆包接到你的指令后就会自动开始处理，它会理解需求、拆解任务、规划文件并写入代码。你能直接预览页面，有新想法可以通过对话继续修改：像把“导航栏换成深色”、“首屏加一张主视觉图”、“把每日健身内容改成卡片”这些要求你可以提给它。符合需求后，你还能继续完成发布与分享。
而豆包完成这项任务的背后，正是火山引擎云数据库 PostgreSQL Serverless 版。
从想法到可用应用，入口正在被压缩成一句话。
这就是 Vibe Coding 带来的变化：用户不必先掌握一整套开发工具，你只需要在对话框中把想法说清楚，就能直接将它变成现实。
「在对话框中说想法」
「豆包将想法变成现实」
「豆包背后的数据库构建」
01一句话造应用，改变的不只是写代码
千万不要低估这个能力，它不只是“AI 帮你写前端”这么简单。
如果你想做一个真正可用的应用，而不只是一个华而不实的页面。那它就得保存用户提交的内容，记录每次交互，能够管理账号和权限，能支撑搜索与分析；当需求改变时，还要能安全修改数据结构、验证新版本，出现问题时可以及时恢复。
换句话说，Vibe Coding 降低了开发的门槛，却也掩盖不了应用背后的数据问题。如果一个应用由 Agent 自动创建、频繁修改、快速上线，那么它的数据库需要比过去更敏捷好用。
这个数据库必须跟得上 Agent 的节奏：环境随开随用、资源随负载伸缩、项目彼此隔离、修改可以回退、不同类型的数据能够统一承载。
而豆包这项应用制作能力背后，是需要有强大的数据底座支撑的，它正是火山引擎云数据库 PostgreSQL Serverless 版。
02Agent 的应用节奏，为什么需要 Serverless 数据库
做一个传统应用，我们往往先规划容量，再购买固定规格的数据库资源；Agent 生成应用的方式却更像一连串高频实验。
今天创建一个活动报名工具，明天试做一套客户管理系统，后天可能又为一次临时活动生成新应用。每个项目的生命周期不同，访问量也可能从无人问津突然变成集中爆发。
真到业务里就会带来三种典型的矛盾：
- 速度与准备时间的矛盾： 应用已经生成好了，数据库还在等资源、等配置，前面跑得快，后面跟不上。
- 波峰与闲置的矛盾： 高峰要扛得住，低谷又不该让计算资源长期空转浪费。
- 高频试错与数据安全的矛盾： Agent 会不断改表、写数据、迭代版本，但一次错误不应该影响主数据和其他项目。
火山引擎云数据库 PostgreSQL Serverless 版的价值，就在于让数据库从“提前配好的一台机器”，变成一项可以被应用和 Agent 按需调用的数据能力，需要时就用，不用时也别一直占着。
图1：面向 Agent 应用的数据底座部分核心能力（示意图）
03七项能力，接住 Agent 的高频创造
如果说弹性、分支和恢复解决的是“Agent 如何更快、更安全地试错”，那么向量检索、AI Function 与开放连接能力解决的，则是“Agent 如何更直接地使用数据与模型”。二者携手才可以构成面向智能应用的完整数据底座。
资源跟着业务走：秒级弹性与 Scale to Zero
火山引擎云数据库 PostgreSQL Serverless 版采用存算分离架构，计算资源可以根据负载自动扩缩。请求上来时快速拉起和扩展，当负载下降时又自动缩减；没有请求时计算资源可以进入 Scale to Zero 状态，并按实际使用量计费。
这就非常匹配 Agent 应用的流量特征：试验项目不必为了“也许会来的访问”长期预留算力，但当真正的高峰出现时数据库又能及时响应。对于大量短生命周期的应用、项目和会话，固定供给的资源变成了按需供给，这样容量规划和闲置成本也随之降低。
像管理代码一样管理数据：Data as Git
Vibe Coding 的开发过程本质上是在不断尝试。代码可以开分支，数据也需要自己的“安全试验场”。
通过 Data as Git 数据分支能力就可以为不同项目、版本或测试任务创建彼此隔离的数据环境。新方案先在分支里验证，确认后再推进；不同分支共享存量数据，但数据操作彼此隔离，既避免一次试验直接影响主数据又减少重复复制。
代码分支解决“怎么改”，数据分支解决“在哪里安全地改”。
让高频迭代可回退：Time Travel
生成式开发最大的特点之一就是迭代快。但迭代越快，越需要可靠的后悔药。
Time Travel 能力支持基于历史时间点恢复数据。在版本切换、误操作或数据结构调整后，开发者不必重新搭建整套环境，而是可以更快回到可用状态。对 Agent 来说这意味着可以大胆尝试；对业务来说则意味着试错仍然在可控范围内。
一个 PostgreSQL，承载多种数据
Agent 应用处理的早已不只是传统表格数据：用户资料是关系型数据，对话和配置常以 JSON 保存，知识库需要向量检索，复杂知识关系还可能需要图数据表达。
火山引擎云数据库 PostgreSQL Serverless 版兼容 PostgreSQL 生态，可通过扩展承载关系型、JSON、向量、空间、图和消息队列等不同数据形态。应用不需要为了每一种数据重新拼装一套独立系统，所以数据链路更短，开发、治理和运维也更集中。
向量与混合检索：
让数据库成为 Agent 的“长期记忆”
Agent 要回答的专业问题不能只依赖模型参数，它还需要从业务数据和知识库中把与当前问题最相关的上下文打捞出来。PostgreSQL Serverless 版通过 pgvector、全文检索与相关扩展，支持向量存储、相似度检索及混合检索，为 RAG（检索增强生成）提供数据基础。
这样一来，结构化业务数据、文档向量和权限信息可以放在同一套事务体系中管理。Agent 接到问题后，可以先检索相关知识，再把结果交给大模型生成回答；知识更新后也可以直接写回数据库，无需额外维护割裂的数据同步链路。
AI Function：让 SQL 直接连接模型能力
给应用加上 AI 功能，调用模型往往只是其中一步。数据要先从数据库里读出来，模型返回的结果需要处理，处理完还要写回去。过去，这几步通常都要在业务代码里串好。
Serverless PostgreSQL 将 AI Function 和 AI 扩展能力引入数据库，开发者可以通过 ai_query、ai_embed 等函数，用 SQL 调用模型或生成向量。文本分析、Embedding 生成、结果落库，也就能放进平时使用的 SQL 工作流。
实际开发时，这省去了部分来回对接的工作。验证一个想法，可以先用 SQL 把处理流程跑通，不必为此单独搭一套跨系统调用流程。相关操作集中起来后，数据权限和处理记录也更方便统一管理。
连接 Agent 生态：框架、MCP 与自然语言管理
除了支持 SQL 调用，数据库还需要接入开发者已有的 Agent 工具和框架。Serverless PostgreSQL 支持对接 LangChain、LlamaIndex、EINO 等 AI 开发框架，也可以通过 MCP Server、Skills 等方式连接 Agent 平台和开发工具，让 Agent 在执行任务时调用数据库能力。
日常管理数据库，也不一定要从控制台里逐个找入口。AI 原生数据库管理平台支持自然语言交互，涉及实例、分支、回滚、监控和治理的操作，开发者可以直接用文字描述需求，减少查找菜单和逐项配置的步骤。Agent 能参与的工作，也从读写数据延伸到了数据库的日常管理。
从“存数据”，到“检索知识、调用模型、管理版本、承接 Agent”，数据库的角色正在被重新定义。
04它不只是豆包的数据库底座，更是 Agent 的通用能力底座
让我们回到最开始说的那句话。
当用户说“帮我做一个应用”时，前台看到的是页面在生成、功能在落地；后台真正发生的是计算、数据、版本和资源被一整套基础设施共同接住。
一个适合 Agent 的数据库，不能只回答“数据存在哪里”，还要回答：
- 新项目能不能快速拥有独立的数据环境？
- 流量突然变化时，资源能不能自动跟上？
- Agent 改错了，数据能不能及时恢复？
- 结构化数据、对话、向量和知识能不能统一管理？
- 应用不用了，闲置资源能不能自动释放？
- 知识库能不能直接完成向量化、检索，然后补充上下文给大模型？
- 应用能不能通过 SQL 调用模型，让数据分析和 AI 处理少绕一道弯？
- Agent 能不能通过框架、MCP 与 Skills 直接调用和管理数据库能力？
火山引擎云数据库 PostgreSQL Serverless 版给出的答案，是把弹性、数据分支、历史恢复、多模数据、向量检索、AI Function 与 Agent 连接能力放在一起，让数据库的供给方式和使用方式都跟着“Agent”走。
前台的一句话就能变成一个持续运行、能够记忆和不断进化的应用，是因为后台有一套同样敏捷的数据底座。
当应用开发越来越像对话聊天的时候，数据库也要从“预先配置的存储资源”，进化为“随 Agent 调用、随业务伸缩、随版本演进，并能连接知识与模型”的通用能力。
这正是火山引擎云数据库 PostgreSQL Serverless 版在 AI 时代的价值：它不只帮应用保存数据，也在成为 Agent 连接业务数据、知识和模型的关键接口。
