Lakebase 数据库分支：并行 AI 智能体各用一个 Postgres
秒级零拷贝，分支永不合并：模式变更必须写成迁移脚本才能推进
Databricks 发布了一套工作流文档，展示其无服务器 Postgres 服务Lakebase如何给每个并行的 AI 编码智能体一个完全隔离的数据库环境 —— 几秒内创建、不复制任何数据 —— 解决了多个智能体对着同一个代码库工作时最棘手的运维约束之一：协调问题。这套做法改变的不只是智能体开发期间数据库隔离的方式，还有模式变更必须如何被跟踪和推进：Lakebase 的分支永远不能合并，这意味着智能体做的任何模式修改，都必须先以版本控制下的迁移代码存在，才能进入另一个环境。
AI 智能体制造的共享数据库问题
让一个 AI 编码智能体对着开发数据库干活，还管得住。同时跑四五个就不行了。智能体编辑同一批模式表会产生竞态；一个智能体的迁移会弄坏另一个智能体正在进行的工作；回滚的模式变更会让数据库处于未定义状态。常规的解法 —— 一个共享数据库加小心翼翼的协调、每位开发者一个手工开的实例，或者 Docker Compose 起本地 Postgres 容器 —— 各自都有不小的运维成本，而 AI 辅助的工作流把这些成本放大了。
促成 Lakebase 这套工作流的核心观察是：AI 编码工具已经在没有人监督的情况下大规模开数据库了。无服务器 Postgres 创业公司 Neon ——Databricks 于 2025 年 5 月收购—— 报告称，被收购时其超过 80% 的数据库是由 AI 智能体自动创建的，AI 智能体开的数据库是人的四倍。这些数字是公司自报的，但它们描述了一个真实的工作流现实：AI 智能体需要按需取用数据库，而这些数据库需要隔离。
写时复制分支在存储层是如何工作的
Lakebase 建立在Neon 的存储架构之上，它用一个把计算与存储完全分离的云原生引擎取代了 Postgres 的标准存储层。正是这种分离让分支模型成为可能。
在标准 Postgres 里，复制一个数据库需要完整地pg_dump再pg_restore—— 耗时与数据库大小成正比。Lakebase 的分支模型不是这样。每一次写入都记录为一条 WAL（预写日志）条目，绑定一个具体的日志序列号（LSN）。创建分支是一次元数据操作：系统往 WAL 历史里的某个 LSN 写一个新指针。不传输数据，不复制页面。分支只是说「从这里开始」。
因此创建分支无论数据库多大都在几秒内完成，初始存储成本实际上为零。随着分支分叉，只有与父分支不同的页面才被单独存储。每个分支带有自己的计算进程，空闲时缩到零，有连接时重启 —— 所以完成任务的智能体不再产生计算费用。这个模型让隔离便宜到可以作为默认选项，而不是最后手段。
智能体 SDLC 循环：一个工作树、一个分支、一个智能体
实际的工作流把 Git 工作树和 Lakebase 分支配对使用。Git 的worktree命令从同一个仓库在另一个分支上创建第二个工作目录，无需克隆，让每个并行的智能体拥有自己的代码目录。一个 post-checkout 钩子创建一个与之对应的 Lakebase 数据库分支。于是智能体获得了完全的隔离：自己的代码状态和自己的数据库状态，两者都不会干扰任何并行工作的其他智能体。
这套工作流延伸进了 CI。正如 Databricks 在 2026 年 6 月的文档所述，当开发者或智能体打开一个拉取请求时，一个 GitHub Actions 工作流会创建一个以该 PR 命名的临时 Lakebase 分支 —— 比如pr-42—— 在上面运行待执行的迁移，部署一个预览应用，并把模式差异以评论形式贴到 PR 上。PR 关闭或合并时，分支及其计算资源被删除。预览环境只在 PR 存在期间存在，成本可以忽略。
Databricks 还记录了在分支中使用源自生产的数据的做法：先经 Unity Catalog 的脱敏策略处理，再暴露给开发环境。据 Thoughtworks 对 Lakebase 的一篇分析，脱敏策略会自动传播到新分支，所以在功能分支上工作的开发者或智能体永远看不到未脱敏的生产数据 —— 这在受监管行业尤其有用。HTEC 展示了这一模式在金融环境中做并行测试的应用，时间是 2026 年 6 月的 Databricks Data & AI Summit，实施对象是一家服务金融机构的风险与合规技术提供商。
模式变更不能合并：这要求的迁移纪律
Lakebase 分支模型中影响最深远的架构约束，不是分支机制本身，而是之后的事。与 Git 分支不同，Lakebase 的分支永远不会被合并。底层的存储语义不支持调和两段分叉的写入历史。
这意味着 AI 智能体做的每一次模式变更，都必须表达为迁移脚本 —— SQL，或者 Drizzle、Flyway、Liquibase、Alembic 这类框架里的 ORM 级代码 —— 才能进入另一个环境。智能体在自己的分支上测试迁移。迁移脚本和应用代码一起提交到版本控制。PR 落地时，迁移从已知的基线出发在目标环境上运行。
实际效果是，Lakebase 强制执行了许多团队视为可选的数据库 DevOps 纪律。在共享数据库的开发里，开发者 —— 或 AI 智能体 —— 先跑探索性的ALTER TABLE语句、事后再把它们重建成迁移脚本，是常见的做法。在 Lakebase 模型里没有别的推进路径：模式变更是代码产物，要经过评审、版本化和回滚。数据库实践成熟的团队会觉得这不足为奇。习惯了松散的共享数据库惯例的团队，则需要在整个组织范围内收紧模式变更纪律，而不只是在智能体专用的流水线里。
Lakebase 与 Supabase、PlanetScale、Aurora 的对比
Supabase 提供分支功能用于预览环境，但预览分支默认不带数据：系统开一个全新的 Postgres 环境并应用待执行的迁移，但不会复制任何生产数据。开发者可以选择用数据文件给分支灌数据，或在控制台勾选包含数据，但默认情况下，在预览分支里工作的智能体没有贴近生产形态的真实数据可测 —— 对依赖有代表性的数据量或数据分布的工作流来说，这是个实实在在的约束。
PlanetScale 的分支在模式层工作，用的是 MySQL 而不是 Postgres。新的开发分支得到源分支模式的副本，但没有数据。分支是彼此隔离的 MySQL 实例，所以一个分支里的数据变更不影响其他分支 —— 但在开发分支里工作的智能体从一个空数据集开始，而不是一个类生产的数据集。
Amazon Aurora Serverless v2提供可缩到零的 Postgres 兼容计算，但没有等价的写时复制元数据分支。要给每个智能体创建一个隔离环境，得单独开一个 Aurora 集群或从快照恢复 —— 正是 Lakebase 所取代的那条又慢又贵的路。Aurora Serverless v2 从零冷启动可能要 15 秒以上，而 Lakebase/Neon 平均约 500 毫秒。
架构上最接近的等价物是独立形态的 Neon —— 这说得通，因为 Lakebase 就是归于 Databricks 名下运作的 Neon 技术。差别在于定位和集成：Lakebase 加上了 Unity Catalog 治理、通过 Mooncake（Databricks 同样收购的 Postgres 兼容湖仓存储引擎）实现的 Delta Lake 互操作，以及企业级支持，代价是需要 Databricks 的基础设施，而不是 Neon 独立的云平台。
哪些尚未验证，架构的边界在哪里
分支创建时间和缩零计算的冷启动延迟是两回事。创建分支是几秒内完成的元数据操作，但如果分支的计算已缩到零，第一次连接会有一段重启延迟 —— 对 Lakebase 底层的 Neon 架构来说平均约 500 毫秒 —— 这是无服务器 Postgres 冷启动的标准代价，对延迟敏感的智能体工作流有影响。
写入活跃的长期分支会累积分叉的页面存储，所以近乎为零的初始存储成本不会一直成立。长时间运行分支的团队应当按实际写入量来测算存储成本。不可合并的约束还引入了一种共享数据库开发里没有的失效模式：两个智能体可能各自独立地做出在迁移层面相互冲突的模式变更。数据库本身在开发期间永远不会暴露这种冲突，但把两份迁移推进到同一个目标环境时会失败，除非手动解决冲突。
Databricks 通过其2026 年 4 月和2026 年 6 月的文档所确立的，与其说是一次产品发布，不如说是一次工作流的形式化 —— 这项能力自2026 年 2 月起就已正式可用，但对 CI 循环的官方记录把这个模式确立为受支持的工程实践，而不是一个巧妙的变通。随着并行 AI 编码智能体的工作流从实验走向生产基础设施，这些智能体如何共享和修改数据库成了一个一等的平台问题。Lakebase 模型的回答是：默认隔离、受治理的模式推进，以及一个明确的要求 —— 先把模式管理收紧，这套工作流才能兑现它的保证。