Databricks 详细说明 Lakebase 分支用于并行编码代理

Databricks 于 2026年10月8日 发布了 一篇博客文章，详细说明了一种开发工作流，其中每个并行编码代理和每个拉取请求都在各自独立的、短暂的 Postgres 数据库上运行，该数据库通过其 Lakebase 数据库服务内置的写时复制分支创建。

在这篇文章中，Databricks 将数据库描述为开发工作流中常被忽视的部分，正值编码代理承担越来越多的开发工作且并行运行多个代理已成常态。使用传统的共享环境，例如单一的开发或预发布数据库，并发代理可能在模式更改上产生冲突、相互干扰，或回退到无法反映真实数据的模拟。文章指出，这些本已是开发者的痛点，但代理因运行更快、并行操作且需要一个安全的环境以避免生产数据风险或泄露敏感数据，从而使问题更加严重。

分支机制

Databricks 表示，Lakebase 分支可以让用户在不到一秒的时间内对整个数据库进行分支，无论其规模大小。分支依赖写时复制存储：新分支继承其父分支的模式和数据，同时共享底层存储，仅在分支发生分歧时才消耗额外存储。根据 Databricks 的 Lakebase 分支文档，每个项目默认创建名为 production 的分支，且除根分支外的每个分支都有父分支。子分支的更改永不影响其父分支，且这种隔离扩展到 Postgres 角色状态：在一个分支上创建的角色和数据库、应用的 GRANT 和 REVOKE、以及角色属性的修改，都不会对其他分支产生影响。

每个分支都有自己的计算资源，空闲时可自动缩减至零，计费仅针对活跃的计算时长，文档如此说明。存储计费取决于分支是否设置了过期时间：过期分支仅对其更改的数据计费，而没有过期时间的永久分支则按其完整数据量计费，类似独立数据库。分支重置会将子分支从父分支刷新，仅支持从父到子的单向操作。时间点恢复会在恢复窗口内从历史数据创建一个新的根分支，同时保持原始分支不变且仍可运行。

在 其产品页面 上，Databricks 将 Lakebase 描述为一项完全托管、无服务器的 Postgres 服务，运行的是开源的 Postgres 引擎，而非其分支版本。

每个代理一个分支

文章中的工作流将 Git worktree 与 Lakebase 分支配对。worktree 为每个代理提供其专属目录并检出各自的分支，从而消除代理之间的文件级冲突，随后在检出后钩子会自动为每个新 worktree 创建数据库分支。在示例中，使用 Claude Code 构建，代理运行 claude -worktree feature-123，Git 创建 worktree，钩子触发，代理最终拥有自己的代码目录和完全隔离的数据库。诸如 AGENTS.md 或 CLAUDE.md 等仓库指令文件会指导代理的行为，当代理完成后会打开一个拉取请求，随后 worktree 和数据库分支均可被删除。

文章指出，与 Git 的一个区别是，Lakebase 分支不会合并回主分支，因为父子分支可以独立更改，且调和它们的数据很快会变得不切实际。相反，模式更改会与应用逻辑一起在代码中追踪，并通过迁移工具（如 Drizzle、Flyway、Liquibase 或 Alembic）提升到父分支。示例使用 Drizzle：当需要模式更改时，代理会将相应的迁移添加到代码库，部署自动化在部署预览应用时以及更改合并到 main 时都会应用该迁移。

每个拉取请求一个分支

针对持续集成，文章阐述了一个 GitHub Actions 工作流：对 main 提交拉取请求会触发 Lakebase CLI 创建一个以该拉取请求命名的短暂分支，作为 production 分支的子分支，该分支成为该拉取请求的数据库环境。迁移工具在新分支上运行，部署预览应用并指向该分支的连接字符串，同时生成模式差异并以拉取请求评论的形式发布，精确显示哪些表、列或索引发生了变化。当拉取请求关闭或合并时，自动化会删除该分支。由于分支源自 production，模式迁移可以在更改进入生产环境前进行应用和测试。示例在 Databricks Apps 上部署预览，尽管文章指出该概念同样适用于其他托管平台，如 Vercel、Netlify 和 Cloudflare。

关于环境，文章指出常见的 Lakebase 配置是每个环境使用一个 Databricks 工作区，例如开发、预发布和生产，并且团队通常从预置数据库而非生产数据库进行分支，以避免泄露诸如 PII 等敏感数据。演练为了简化使用了单一工作区，同时说明相同概念也适用于多工作区的部署。

错误复现与迁移测试

除了每个代理和每个拉取请求的循环之外，文章还描述了示例仓库中未实现的分支工作流。开发者可以在特定时间点从生产环境创建一个独立分支，通常是在出现 bug 之前，使用真实数据复现并调查问题，并在验证修复后删除该分支。团队也可以在部署到生产之前创建分支，执行模式迁移、运行测试，并在推广更改之前验证应用仍按预期运行。这些工作流让开发者能够使用类似生产环境或来源于生产的数据，例如使用 Unity Catalog 掩码，而无需让实时数据库面临风险，文章指出。

文章链接到 GitHub 上的示例仓库，位于 databricks/tmm 仓库的 Lakebase-Agentic-CI 目录中，其中包含实现该模式的 GitHub Actions 工作流示例。文章总结说，这些模式共同构成了它所称的 Lakebase 开发循环：每个代理一个分支、每个拉取请求一个分支，以及用于生产验证的独立分支。