Parallel Coding Agents with Lakebase | Claude Code + GitHub Actions

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: Parallel Coding Agents with Lakebase | Claude Code + GitHub Actions · Channel: Databricks · 05:41 · Watch on YouTube

Topics: AI agents, Claude Code, Data, databases and embeddings, Software engineering with AI, AI developer tools

Summary

The video demonstrates an end-to-end workflow for running coding agents in parallel while keeping their database changes isolated. Each agent works in its own Git work tree and Lake Base database branch, allowing it to experiment, run migrations, and test without affecting other agents. When an agent opens a pull request, GitHub Actions creates a separate database branch for preview and validation, applies migrations, and runs tests. Database branches are temporary; schema changes are captured as portable migrations and can be applied to production after validation.

Key points

Sharing one development database can cause parallel coding agents to interfere with each other.
Liquibase Postgres supports database branching, using copy-on-write so branches add storage as they diverge from their parent.
Each agent receives an isolated database branch for migrations, tests, and experimentation.
Git work trees let multiple agents work on separate tasks in the same repository, each with its own working files and Git branch.
A Cloud Code hook automatically creates a dedicated Lake Base branch when a session starts with a work tree.
The demo launches four agents to add features to a to-do app and shows their isolated database branches and schema changes.
GitHub Actions creates a fresh Lake Base branch for each pull request’s preview and validation workflow.
Database branches are not merged into main; schema changes are captured as migrations, which can later be applied to production.

Chapters

Start	Chapter	Summary
00:00	Why parallel agents need isolated databases	The video introduces the risk of agents sharing a development database and presents database branching as a way to isolate their work.
01:32	Setting up agents with work trees and database branches	The demo explains Git work trees and a hook that creates a dedicated Lake Base branch for each agent session.
03:05	Inspecting agent branches and pull requests	The video shows agent-specific database branches and schema changes, then moves to automatically opened pull requests.
04:39	Validating previews and completing the workflow	Pull requests use isolated preview databases and tests, while portable migrations carry validated schema changes toward production.

Quotes

If all your agents share the same development database, how do you make sure they don’t interfere with each other? — 00:00

Git lets you create branches for your code, and Liquibase lets you create branches for your database. — 00:30

You can see that four branches have been created, one for each agent. — 03:05

So, the branch is temporary, but the migration is portable. — 04:39

If we can branch code, we should be able to branch databases too. — 05:41

Concepts and entities

Lakebase, Claude Code, Git worktrees, GitHub Actions, Liquibase, Drizzle, Codex, Cursor

Full transcript (original language)

00:00 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

00:30 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

01:01 diverge from its parent. 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,

01:32 and sometimes make mistakes. 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

02:02 useful for agents because multiple agents can work on different tasks in the same repository without interfering with one another. 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.

02:33 So, each agent can build and test its feature against its own database without touching anyone else’s environment or production. 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

03:05 branches, including the ones the agents are currently working on. You can see that four branches have been created, one for each agent. 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

03:37 finished. The agents are instructed to open pull requests once their work is done. So, let’s jump over to GitHub 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

04:08 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

04:39 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.

05:11 And that’s the complete workflow. We started with multiple coding agents working in parallel, each with its own isolated database branch. 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

05:41 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.