Git worktrees isolate your coding agents' files. Databricks' Lakebase pattern isolates their databases
A Databricks reference workflow gives each coding agent and each pull request its own copy-on-write database branch. The pattern travels well; production data and migrations need rules.
Listen to this article · 5 min
AI-generated narration of the full article.
Run three coding agents in parallel and they will not collide in Git. Each has its own worktree, its own branch, its own files. They will collide in the database. One agent’s migration renames a column that another agent’s tests depend on, a third agent’s fixtures overwrite the rows both were using, and the failures look like bugs in code that is actually fine.
A Databricks post published on October 8 describes one way out. Written by Thibaut Gourdel, it is a reference workflow, not a product launch, built on Lakebase, Databricks’ managed Postgres, and its copy-on-write branching. Databricks says Lakebase can branch “an entire database in under a second, regardless of its size”. Branches share the parent’s data and consume extra storage only as they diverge, and idle branches can scale to zero, so they incur no compute cost while unused.
The workflow
The pattern gives a database branch to every unit of parallel work, at two levels.
Per agent. When a coding agent gets a Git worktree, a Claude Code post-checkout hook creates a matching database branch. The agent develops against its own copy, writes its schema changes as migrations, and when the pull request is open, the worktree and its database branch can be retired.
Per pull request. In CI, GitHub Actions creates a branch such as pr-123 as a child of production, runs the migrations (Drizzle in the example), deploys a preview app on Databricks Apps and posts a schema diff on the pull request. The branch is deleted when the pull request closes or merges.
- Agent gets a worktree
- Hook creates its database branch
- Agent writes code and a migration
- CI branches from production and runs the migration
- Schema diff and preview reviewed
- Merge applies the migration to production
- Per agent: Agent gets a worktree · Hook creates its database branch · Agent writes code and a migration
- Per pull request: CI branches from production and runs the migration · Schema diff and preview reviewed
Agent workspaceValidation in CI
Why the migration rule matters most
The most important sentence in the post is a limitation: “Lakebase branches are not merged back to the main branch.” Schema changes are tracked in code alongside the application and promoted through migrations.
That turns a constraint into a control. Whatever an agent does to its database branch, the only thing that reaches production is a migration file in a pull request, reviewed like any other change. It is the principle we described in agents as authors of production changes: an agent’s change counts only when it travels through the change process, as an artifact a person can read and reject.
Where the pattern needs rules
Which data the agent sees. The PR branch in the example starts from production, which is what makes migration testing realistic. But an agent working on a branch of production is working with production data. The post notes that branching from a seeded database “is also common” to avoid exposing sensitive data, and that production-derived branches can use Unity Catalog masking. We would make the safe choice the default: agent branches from seeded or masked data, and production branches only inside CI, under an identity that runs migrations without handing rows to the agent.
Whose credentials reach which branch. Isolation in data means little if every agent holds credentials for every branch. Each agent’s database identity should reach only its own branch, the same principle that applies to its cloud role.
Cleanup. Hundreds of short-lived branches are cheap only if they are actually deleted. Branch lifecycle belongs in the automation, not in a developer’s memory, and someone should check periodically for branches that outlived their worktree.
Status. The post does not state the release status of the branching features it uses, or any limits. Check those before planning a rollout.
Parallel agents expose every shared mutable resource a team has: databases first, then queues, caches, feature flags and external test accounts. Worktrees solved the easiest one. Database branching is a strong answer to the next, and the discipline it enforces, migrations as the only path to production, is worth adopting even where the tooling is different.