Agent写代码，数据库先学会分身

AI 改变了软件的建造方式，但有一个环节一直没跟上：数据库。

当编码 Agent 能一口气写出几百行代码时，工程师却发现，真正让“全自动开发”卡壳的往往不是代码，而是代码背后的状态——表结构、测试数据、迁移脚本。Databricks 推出的 Lakebase 给出了一个看似简单、实则釜底抽薪的答案：把 Git 的分支模型搬进数据库，让每个 Agent 都能秒级“分身”出一个独立库，做完实验就扔。

我的判断是：这不是又一个 Postgres 托管服务的例行发布，而是数据库工作流第一次为“机器开发者”而不是人类工程师重新设计。这件事的分量，比产品名听起来大得多。

🧩 AI 先学会写代码，还没学会动数据库

先看一个所有用过编码 Agent 的人都遇到过的场景。

你让 Cursor 或者 GitHub Copilot 改一个订单功能。代码改得又快又好，但接下来呢？新逻辑需要加一列、建一张表、刷一批测试数据。往哪儿刷？

往生产库上刷？没人敢。往团队共享的开发库上刷？Agent 一跑迁移，同事的调试环境当场崩掉。于是流程退回到最原始的样子：提工单，等 DBA 排期，审批、备份、快照、恢复，一轮下来几个小时甚至一天。

问题就在这里。Databricks 在收购 Neon 的官方博客里把话说得很直白：AI 正在改变软件的构建方式，当编码 Agent 承担的份额越来越大，软件工程的其他环节必须跟着重造——数据库正是最落后的那一环。

代码的迭代速度已经是分钟级，数据库环境的准备速度还停留在小时级甚至天级，这条鸿沟就是 Agentic SDLC 的真瓶颈。

而且这个瓶颈只会越来越宽。Agent 和人不一样：人一天开三个分支是常态，Agent 一天可能要验证二十种实现方案，每种方案都对应不同的 schema 假设和不同的数据集。如果每次验证都要“申请一个干净环境”，成本和延迟会把 Agent 的效率优势全部吃掉。

这一点不需要匿名从业者的转述，公开案例已经给出了佐证：Replit 的 Agent 每生成一个应用，就自动创建一个独立的 Postgres 数据库——背后正是 Neon 提供分支数据库能力。对这类产品而言，“一天开几十个库”不是夸张，而是基础设计假设。Neon 官方给出的数字是：通过 API 创建一个数据库分支耗时不到一秒，被收购前已支撑了百万级数据库的创建，Vercel、Retool、Copy.ai 等平台的 Postgres 服务同样跑在它的底座上。

🌿 Git 管住了代码的平行宇宙，数据库一直没有

理解 Lakebase 的关键，是理解“分支数据库”到底在解决什么。

Git 之所以成为软件工程的地基，是因为它给了开发者一样东西：廉价、可丢弃的平行宇宙。你可以随时开一个 branch，随便折腾，不满意就删掉，满意再合并，主线永远干净。

数据库一直没有这个能力。传统数据库的“复制”意味着两件事：要么拷贝全量数据，贵且慢；要么共享同一份数据，互相污染。所以数据库一直是软件工程里那个“被保护的稀缺资源”——改之前要审批，动之前要备份。

分支数据库的思路是把这个稀缺资源变成消耗品：每个分支就是一个完整的、可独立读写的数据库视图，创建它只是一次元数据操作，而不是一次物理拷贝。

底层的关键技术是 copy-on-write（写时复制）。开一个分支，并不真的复制整库数据，两个分支共享同一份底层存储，只在数据被修改时才写入增量。这意味着开分支从“小时的物理拷贝”变成“秒级的元数据操作”，存储成本也只随增量增长。

落到工程场景，收益是直接可感的：

• 每个 Pull Request 自动挂一个独立数据库分支，预览环境不再是奢侈品；
• Agent 可以在分支上放心地跑迁移、灌测试数据、验证边界条件；
• 实验失败，分支直接删除，主线毫发无伤；
• 出了线上问题，可以从过去某个时间点开一个分支，在不影响生产的情况下复盘和修复。

当数据库操作从‘高风险变更’变成‘可回滚的实验’，整个 SDLC 的安全感和并行度都会上一个台阶。 而这条路 Databricks 不是自研摸索，而是直接买下了走通它的人：2025 年 5 月，Databricks 宣布收购 Postgres 分支数据库公司 Neon——据 TechCrunch 等媒体报道，交易金额约 10 亿美元；两个月后的 Data + AI Summit 上，Lakebase 以公测（Public Preview）形态亮相。Neon 由 Nikita Shamgunov 等人于 2021 年创立，累计融资约 1 亿美元，这次收购相当于用平台级的资本把一个已被验证的技术路线直接焊进了数据平台。

🏗️ 没有存算分离，分支就是烧钱的复制

不过要把“每条 prompt 一个分支”变成现实，光有分支语义还不够，架构得先过关。

道理很简单：如果计算和存储绑死，每个分支至少要挂一套常驻计算资源。Agent 一天开几十个分支，就是几十套空转的实例，账单会把所有浪漫主义烧干净。

所以这类产品的共同底座是存算分离加无服务器化：存储层全局共享一份，计算层是按需拉起的独立端点。

翻译一下：分支不用了，计算可以完全暂停（scale to zero），只留数据在共享存储里躺着，几乎不产生费用；下次要用，秒级拉起一个新的计算端点。这样“开分支”才真正降到接近零成本，Agent 的“随便试”才在经济学上成立。

这张表的最后一行才是重点。前面几行是工程指标的改善，最后一行是心智模型的更换——前者是优化，后者才是范式。

落到 Lakebase 的具体产品形态，公开信息里能确认的能力清单包括：基于标准 Postgres 的完整兼容（存量驱动、ORM、迁移工具直接可用）；无服务器计算按用量计费、支持自动伸缩与缩容到零，暂停的分支只按存储增量付费；基于写时复制的分支与时间点恢复（time travel），可以从任意保留点拉出历史分支；以及与 Unity Catalog 的打通——权限、审计、血缘沿用平台统一治理，而不是另起一套。这套规格和 Neon 的原生能力几乎一一对应，收购逻辑一目了然。

当然，要补一句泼冷水的：存算分离本身已是行业共识，难的不是“分开”，而是分离之后还能保持事务语义和性能不下坠。Postgres 生态的兼容性是 Lakebase 聪明的地方——不发明新方言，直接继承全球最成熟的 OLTP 生态，让存量工具链和应用零成本迁移。这是产品判断，也是对开发者时间的尊重。

⚠️ 分支解决了实验自由，没解决合并纪律

好话说完，得讲讲难的部分。分支数据库不是银弹，至少有三块硬骨头还没啃完。

第一块：DDL 的合并远比代码合并难。 代码冲突，Git 用三方合并基本能兜住。但两个分支各自改了表结构——一边把列改名，一边给旧列加了索引——合并时机器怎么判断语义意图？目前的现实做法大多仍是“约定分支生命周期要短、主分支变更要串行”，也就是用纪律兜底，而不是用算法兜底。分支给了你实验的自由，合并的纪律还得自己重建。

第二块：数据从生产环境分支出去，就是一次合规事件。 分支数据库最常见的用法是从生产数据开分支做测试。但生产数据里可能裹着用户隐私，一开分支，数据的副本边界就扩散了。要么引入自动化脱敏和掩码管道，要么对分支数据的访问做严格隔离。这在 GDPR、个保法的语境下不是技术细节，是法务问题。Agent 越自动化，数据合规的审计点就必须越前置。

第三块：成本失控的新形态。 存算分离降低了单分支成本，但也降低了创建门槛——没人看管的话，僵尸分支会像僵尸云主机一样无声堆积。这要求平台层面有分支的自动回收策略和用量观测，也要求团队建立新的卫生习惯。

企业客户的优先级其实从公开的产品动线上就能读出来：Lakebase 发布时反复强调的第一批能力不是性能基准，而是 Unity Catalog 集成带来的统一权限与审计——治理叙事被放在了性能叙事前面。换句话说，技术可行性已经过关，工程治理才是落地的胜负手。

这也顺带重画了 DBA 的岗位画像：审批建库、盯备份这类活会大幅萎缩，而“数据环境治理”——分支策略、脱敏规则、成本预算——会成为新的核心职责。

📊 湖仓厂商做 OLTP，不是顺手，是补命门

最后跳出单个产品，看看这一步棋在产业棋盘上的位置。

Databricks 的基本盘是湖仓：管分析、管 BI、管模型训练数据。但 Agent 时代来了之后，一个缺口暴露得越来越明显——Agent 要跑起来，背后需要一个事务型后端：存会话、存工具调用状态、存应用自身的业务数据。这些是典型 OLTP 负载，湖仓管不了。

如果分析平台不自己补 OLTP，就只剩两条路：让客户去别家买数据库，然后忍受两套系统之间无休止的 ETL 搬数。前者放走收入，后者放走体验。Lakebase 的意义就是把这两条路都堵上：湖仓管分析，事务库管应用状态，两者同源打通，Agent 的数据在哪一层都不需要“搬家”。

这个动作背后是一条更长的行业主线：对象存储之上的数据库形态，正在从分析场景向事务场景蔓延。 当存算分离足够成熟，“数据库”就不再是某种绑定硬件的重资产，而成为数据平台上一组可以按需拉起的能力。分析平台厂商向下吃事务，事务数据库厂商向上做分析，两边的边界在 AI 时代被重新画了一遍。手握 2025 年初 100 亿美元新融资、620 亿美元估值的 Databricks，显然不打算把 OLTP 这块命门留给别人来补。

对于用户来说，这轮融合的实际好处很朴素：更少的数据搬运、更统一的安全边界、以及——对 Agent 工作流最关键的——更廉价的环境供给。

小结

回头看，Lakebase 这类分支数据库真正改写的，是数据库在软件工程里的“社会角色”：从那个需要审批、备份、小心翼翼对待的稀缺资源，变成 Agent 可以随意分叉、做完即弃的实验材料。

这是 Agentic SDLC 走向自动化的底层前提之一——代码有了 Git，数据库现在才开始有它的“Git 时刻”。

往前看，分支的创建和销毁会很快变成默认能力，真正值得押注的战场在两处：schema 变更的合并语义能不能做到接近 Git 的自动化程度，以及生产数据分支化的合规管道能不能标准化。谁先啃下这两块，谁就把“机器开发者时代的数据库工作流”定义权握在手里。

而对普通团队来说，现在能做的三件事其实很具体：把“每次实验一个分支”写进 Agent 的默认工作流，而不是让它继续共享开发库；把脱敏和分支回收策略提前纳入评审清单，而不是等审计找上门；以及，拿一两个低风险的内部服务先在 Postgres 分支上试跑完整的“迁移—验证—合并”闭环。数据库的 Git 时刻不会等人准备好了才到来，它只会奖励先动手的那批团队。