Skip to main content

Parallel Coding Agents with Lakebase | Claude Code + GitHub Actions

Summary

  • Isolated database branches: Lakebase provides copy-on-write database branches that are instant and cost-efficient, letting each coding agent experiment safely.
  • Parallel agent workflow: Use Git worktrees with any coding agent to enable multiple agents working simultaneously on different features without interference.
  • Automated CI/CD: Auto-create Lakebase branches via Claude Code hooks and capture schema changes as migrations for integrated GitHub Actions workflows.

Parallel Coding Agents with Lakebase | Claude Code + GitHub Actions

Watch: Parallel Coding Agents with Lakebase | Claude Code + GitHub Actions
Running coding agents in parallel is becoming the norm, but there's one part of the stack that gets overlooked: the database. If all your agents share the same dev database, they interfere with each other, and it's hard to let each one run tests, apply schema changes, and experiment safely.
This video shows to combine parallel coding agents, Git worktrees, Lakebase database branching, and GitHub Actions into a single agentic workflow. Each agent gets its own isolated, copy-on-write database branch (cheap, fast, and scaled to zero when idle) auto-created from a Claude Code hook, tested in a per-PR preview environment, and safely promoted to production as migrations.
Example repository and CI workflows:
Chapters
Learn more about developing with Lakebase on: https://developers.databricks.com/

Chapters

FAQs

Why is database isolation important for parallel coding agents?

If all agents share the same development database, they interfere with each other's tests and schema changes. Isolated branches let each agent experiment freely, fail safely, and roll back without affecting others.

How do Lakebase branches use copy-on-write to save costs?

Copy-on-write means a branch only uses additional storage when it diverges from its parent. Unmodified data is read from the parent, and compute scales to zero when the branch is idle, keeping temporary environments cost-efficient.

How do I govern Claude Code, Codex, Cursor, and other coding agents?

This video demonstrates governance through database isolation using Lakebase copy-on-write branching. By creating a dedicated database branch for each coding agent, you control what data each agent can access and modify. Git worktrees combined with Lakebase branching enforce separation at both the code and database layers, preventing agents from interfering with each other while allowing each to run tests and apply schema changes safely.

How can I apply consistent policies across multiple coding agents?

This video shows how to standardize governance across agents using Claude Code hooks and Lakebase database branching. Each agent gets an isolated copy-on-write database branch auto-created from a shared main branch, ensuring consistent schema and governance policies. GitHub Actions workflows capture schema changes as migrations, which are then safely promoted to production through a standard CI process.

Which managed Postgres platforms support creating database branches without full duplication?

This video features Lakebase, a managed Postgres platform that uses copy-on-write branching similar to Git. Branches only consume additional storage as they diverge from the parent, and compute scales to zero when idle, making temporary environments cost-efficient. The video demonstrates how this enables developers and agents to create isolated, production-like database branches for testing and experimentation without the overhead of full duplication.

Full transcript

0:00 The overlooked database bottleneck

Running coding agents in parallel is becoming the norm. The tooling has evolved quickly with things like skills, MCP, hooks, sub-agents, and more. But, there is one important part of the stack that often gets overlooked in their workflows, the database. If all your agents share the same development database, how do you make sure they don't interfere with each other? How do you let each agent run tests, apply schema changes, and experiment safely?
In this video, I'll show you how to combine parallel coding agents, Git work trees, Liquibase, and GitHub Actions to build an end-to-end agent CI workflow. Liquibase Postgres is a great fit for this kind of development because it supports database branching. You can think about it in similar way to Git. Git lets you create branches for your code, and Liquibase lets you create branches for your database. Liquibase uses copy-on-write branching, which basically means a branch only uses additional storage as it starts to diverge from its parent.

0:56 Copy-on-write: cheap, isolated branches

And when a branch isn't being used, its compute can scale down to zero, which helps keep temporary environments cost-efficient. Each agent gets its own isolated database branch, so it can run migrations, test changes, and experiment without affecting anything else. And once the work is done, we can simply retire the branch. This is especially useful for coding agents because they need room to experiment, try different approaches, and sometimes make mistakes.

1:14 A dedicated database branch per agent

If something goes wrong, they can simply roll back to an earlier point without affecting anyone else. In this demo, I'm going to use Cloud Code, but the same approach works with other coding agents like Codex or Cursor. Coding agents can use Git work trees to work in parallel. A Git work tree gives a developer or an agent a separate set of working files for the same repository, usually with its own Git branch. That makes work trees especially useful for agents because multiple agents can work on different tasks in the same repository without interfering with one another.

1:42 Git worktrees + any coding agent

Using Cloud Code's work tree integration, I'm going to run multiple agents on different features. Each agent will have its own folder and its own Git branch. I also set up a Cloud Code hook so that whenever I launch a new session with a work tree, it automatically creates a dedicated Lake Base branch from the main database branch. So, each agent can build and test its feature against its own database without touching anyone else's environment or production.

2:13 Auto-creating a Lakebase branch with a hook

Now, I'm going to launch four separate Cloud Code sessions with each one working on a different feature. Together, they'll improve a simple to-do app by adding things like priorities, due dates, and a few other features. While the agents are working, let's take a look at the Lake Base interface. Here, we can explore the database and all its branches, including the ones the agents are currently working on. You can see that four branches have been created, one for each agent.

2:42 Live demo: branching, preview environments & CI

Let's open one of them. If we check the schema diff, we can see that the agent added a new column to the database for the feature it's working on. So, this database change is completely isolated to that agent's branch. Now, let's go back to the agents and see how they're doing. It looks like a few of them have finished. The agents are instructed to open pull requests once their work is done. So, let's jump over to and take a look.
Here, we have a couple of pull requests that were opened automatically by the agent. As soon as a pull request is created, GitHub Actions start another automation workflow. At this point, the agent's database branch has done its job during development. For the pull request, CI creates a new Lake Base branch specifically for preview and validation. The workflow then deploys a preview version of the application and connects it to that dedicated database branch.
You can also see a migration step in the workflow. If the feature includes database schema changes, the migration runs against the isolated Lake Base branch and applies those changes, such as creating a new column or creating a new table. One important difference here is that Lake Base branches don't get merged back into main like Git branches do. Instead, we capture the schema changes as migrations using a tool like Drizzle.
So, the branch is temporary, but the migration is portable. For every pull request, this gives us a dedicated database for review and QA before anything reaches production. In this example, we can manually test the preview application and we also run automated smoke tests against it. And that's the complete workflow. We started with multiple coding agents working in parallel, each with its own isolated database branch.

5:15 The complete agentic workflow

Then, for every pull request, we created a fresh preview environment with its own database branch, applied the migrations, and tested the feature in isolation. And once everything was validated, those same migrations were safely applied to production. The example here uses Cloud Code and GitHub Actions, but the same pattern can work with other coding agents and CI systems. The idea is pretty simple. If we can branch code, we should be able to branch databases too.
So, agents can work safely in parallel. You can find the example repository and the full CI workflow in the description.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.