Databricks Details Lakebase branch for parallel coding agents – Unite.AI

Databricks on October 8, 2026 published a blog post detailing a development workflow in which each parallel coding agent and pull request runs on its own isolated and ephemeral Postgres database, created via copy-on-write branching built into its Lakebase database service.

In the post, Databricks describes the database as an often overlooked part of the development workflow at a time when coding agents are taking on an increasing share of development work and running multiple agents in parallel is becoming the norm. With traditional shared environments, such as a single development or staging database, competing agents can conflict over schema changes, interfere with each other, or resort to simulations that don’t reflect real-world data. These were already pain points for developers, the post says, but agents exacerbate them because they move faster, operate in parallel, and need a secure environment that avoids putting production data at risk or exposing sensitive data.

Branching mechanics

Databricks says Lakebase branching allows a user to branch an entire database in less than a second, regardless of its size. Branches rely on copy-on-write storage: a new branch inherits the parent’s schema and data while sharing the underlying storage, consuming additional storage only when it diverges. According to Databricks’ Lakebase branching documentation, each project is created with a default branch named production, and every branch except the root branch has a parent. Changes in a child branch never affect its parent, and the isolation extends to the state of the Postgres role: roles and databases created, GRANTs and REVOKES applied, and role attributes changed on one branch do not affect other branches.

Each branch has its own compute, scales to zero when idle, and is only billed for active compute hours, the documentation states. Storage billing depends on a branch’s expiration: an expiring branch is billed only for the data changed within it, while a non-expiring permanent branch is billed for the full size of the data, like a stand-alone database. A branch restore, which updates a child branch from its parent, only works in one direction, from parent to child. Point-in-time recovery creates a new root branch from historical data within the recovery window while leaving the original branch unchanged and operational.

On the product page, Databricks describes Lakebase as a serverless, fully managed Postgres service that runs the open source Postgres engine rather than a fork.

One branch per agent

The workflow in the post couples Git working trees with Lakebase branches. A working tree provides each agent with its own directory with its own checked-out branch, removing file-level conflicts between agents, and a post-checkout hook then automatically creates a database branch for each new working tree. In the example, created with Claude Code, an agent is executed claude -worktree feature-123Git creates the working tree, the hook fires, and the agent ends up with its own code directory and completely isolated database. Repository instruction files such as AGENTS.md or CLAUDE.md drive the agent’s behavior, and when the agent exits, it opens a pull request, after which both the working tree and the database branch can be retired.

One difference from Git, the post notes, is that Lakebase branches are not merged into the main branch, because parent and child can both change independently, and reconciling their data can quickly become impractical. Instead, schema changes are traced into the code along with the application logic and promoted to the main branch via migrations, using tools like Drizzle, Flyway, Liquibase, or Alembic. The example uses Drizzle: when a schema change is needed, the agent adds the corresponding migration to the codebase, and deployment automation applies it when you deploy the preview application and again when the change merges with the main one.

One branch per pull request

For continuous integration, the post defines a GitHub Actions workflow where opening a pull request against main triggers the Lakebase CLI to create a temporary branch, named after the pull request, as a child of the production branch, and that branch becomes the pull request’s database environment. The migration tool is run on the new branch, a preview application is deployed and pointed at the branch’s connection string, and a schema diff is generated and published as a pull request comment showing exactly which tables, columns, or indexes have changed. When the pull request is closed or merged, the automation deletes the branch. Since the branch starts from production, schema migration can be applied and tested before the change reaches production. The example deploys previews to Databricks Apps, although the post states that the concept applies to other hosting platforms like Vercel, Netlify, and Cloudflare.

On environments, the post notes that a common Lakebase configuration uses one Databricks workspace per environment, such as development, staging, and production, and that teams commonly branch from a seed database rather than the production database to avoid exposing sensitive data such as PII. The walkthrough uses a single workspace for simplicity, noting that the same concepts apply to setups with multiple workspaces.

Bug reproduction and migration testing

In addition to per-agent and per-pull-request loops, the post describes branching workflows that are not implemented in the sample repository. A developer can create an isolated branch from production at a specific time, typically just before a bug appears, reproduce and analyze the problem against real data, and retire the branch once the fix is ​​validated. Teams can also branch before deploying to production, apply a schema migration, run tests, and verify that the application still behaves as expected before pushing the change. These workflows allow developers to work with production-grade or production-derived data, for example using Unity Catalog masking, without putting the live database at risk, the post says.

The post links to an example repository on GitHub, in the Lakebase-Agentic-CI directory of the databricks/tmm repository, which contains examples of GitHub Actions workflows that implement the pattern. He concludes that together these models form what is called the Lakebase development cycle: one branch per agent, one branch per pull request, and isolated branches for production validation.