Making AI write code in parallel isn't hard; the hard part is giving every agent a clean database

Parallel development with coding agents—the code-level answer is already fairly clear. Git worktree gives each agent an independent directory and branch, so files don't collide. But one layer down, the database is still shared.

Every agent needs to read the schema, run migrations, seed data, and execute tests. When one dev or staging database is used by three agents at the same time, the result is migrations overwriting each other, test data contaminating each other, or simply falling back to mocks—so what you're testing isn't the same as production.

Thibaut Gourdel, the author of the Databricks blog, calls this the overlooked bottleneck. Their solution is Lakebase database branching: an entire Postgres database can be branched into a complete copy in under a second, no matter how large the database. Under the hood it's copy-on-write; the child branch and parent branch share data pages, and additional storage is used only when a difference is actually produced. Idle branches can scale to zero and don't incur compute charges when not running.

Compared with native Postgres, where's the gap? A commenter pointed out that ordinary Postgres has CREATE DATABASE x TEMPLATE parent, but it copies every file, and it fails whenever there is any connection to the parent database. Copying is slow, it blocks, and it isn't suitable for giving every agent its own copy.

How does Lakebase's approach work in engineering practice? The blog gives a complete chain.

For local parallel agents, use Git worktree to isolate code. Add a post-checkout hook to the repository so that when a new worktree is created, it automatically calls the Lakebase CLI to create a database branch. The agent changes code and runs migrations in the worktree; the database belongs to it and has nothing to do with anyone else. When the work is done and a PR is opened, the worktree and the database branch are cleaned up together.

At the PR stage, switch to GitHub Actions. As soon as a PR is opened, CI creates a temporary Lakebase branch named after the PR number, with production as the parent branch. The migration tool runs schema changes against this branch—in the example, Drizzle—then deploys a preview app pointing at this branch's connection string, and finally generates a schema diff and posts it to the PR comment, telling the reviewer which table, which column, and which index changed. When the PR is merged or closed, the branch is deleted.

One detail worth noting: database branches are not merged back like Git branches. The parent and child branches can evolve independently, and merging data isn't realistic. Schema changes go through migration files in code, and the deployment process is responsible for advancing them to the parent branch. In other words, code is merged, and the database replays migrations.

Besides development and PRs, branches can do other things. Create a branch from a point in time in the production database to reproduce a bug, debug on real data, and delete it once fixed. Before release, create a branch to run migrations and tests, confirm everything is fine, then push to production. When you need real data but don't want to touch sensitive information, you can combine it with Unity Catalog for masking.

This doesn't solve a new problem; it's an old problem amplified by agents. Previously, three to five developers shared one dev database, and conflicts were handled by self-discipline and convention. Now agents run in parallel, fast and numerous, and manual coordination can't keep up. Database branching makes isolation the default: one per agent, discarded after use.

Databricks' original article and example repository are below; the GitHub Actions configuration can be copied directly.

Original article: https://www.databricks.com/blog/lakebase-and-agentic-sdlc-branching-databases-coding-agents

Example repository: https://github.com/databricks/tmm/tree/main/Lakebase-Agentic-CI