DatabricksThibaut GourdelProblem & solution
Coding agents working in parallel on shared databases create schema conflicts, test interference, and data exposure risks. Lakebase Postgres solves this with database branching, which creates an isolated copy of an entire database in under a second using copy-on-write. Each agent gets its own database branch via a post-checkout Git hook tied to a worktree, and each pull request gets an ephemeral branch through CI tooling. Schema changes are tracked in code with migration tools such as Drizzle or Alembic and promoted to the parent branch during deployment, not by merging database branches. Idle branches scale to zero, so running many concurrent agents incurs no compute cost for unused branches.
Coding agents working in parallel on shared databases cause schema conflicts, test interference, and data exposure risks. Traditional single-development-database setups cannot safely isolate concurrent agent activity.
Lakebase Postgres uses copy-on-write database branching to give each coding agent and pull request an isolated, ephemeral database. A post-checkout Git hook creates a database branch per worktree; CI tooling (GitHub Actions) creates a branch per PR. Schema changes are tracked in code via migration tools (Drizzle, Flyway, Liquibase, Alembic) and promoted to the parent branch through deployments, not by merging database branches.
Database branching gives each coding agent an isolated, ephemeral database, preventing schema conflicts and test interference when agents run in parallel.
Lakebase branches use copy-on-write and scale to zero when idle, so running many concurrent agents does not consume extra storage or compute for unused branches.
Schema changes are tracked in code via migration tools (Drizzle, Flyway, Liquibase, Alembic) and promoted to the parent branch through deployment, not by merging database branches.
Lakebase branches are not merged back to the parent branch because both parent and child can change independently, making data reconciliation impractical. Instead, schema changes are tracked in code as migrations and applied to the parent branch during deployment.
Yes. Lakebase branches use copy-on-write, so they share the parent branch's data and only consume additional storage as they diverge. Idle branches scale to zero, incurring no compute cost, which is important when running many agents simultaneously.
A common setup uses one Databricks workspace per environment (dev, staging, prod) for security and compliance. Branching from a seeded database instead of production is also common to avoid exposing sensitive data like PII.
Summaries are generated from the original by a language model. Check the original before relying on it.
See the idea
A four-step pattern for letting a document agent write validated aggregation pipelines instead of arbitrary code, so results come back shaped and tenancy stays enforced.
A side-by-side comparison of the two accountability models engineers actually rely on: a named human owner per outcome, and system-enforced traces, budgets, and isolation.
Keep reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
One useful email. Unsubscribe anytime.
