How can I create and automatically delete a Lakebase branch for every pull request?

Summary

• Yes. Give every pull request its own isolated Lakebase branch: your CI creates a branch when a PR opens and deletes it when the PR merges or closes, so each change is tested against a real, full-size copy of production data.
• Branches are copy-on-write. Creating one doesn't copy data; it points at the parent's storage and diverges only as you write, so a branch of a large database appears in seconds and you pay only for what changes.
• Automate it with the Databricks CLI in your pipeline: databricks postgres create-branch when a PR opens, databricks postgres delete-branch when it closes.
• Set an expiration policy when you create a branch (a TTL, an explicit expiry, or no-expiry) so stray per-PR branches clean themselves up even if a delete step never runs.
• Branching is the model from Neon, now part of Databricks and the serverless Postgres engine behind Lakebase. Lakebase is generally available; the Terraform branch resource is in Public Beta, so confirm the current interface in the docs.

How can I create and automatically delete a Lakebase branch for every pull request?

Wire two steps into your CI pipeline: create a branch when a pull request opens, and delete that branch when the pull request merges or closes. Each PR then gets a private, full-size database to run migrations and tests against, with no shared staging database to corrupt and no synthetic fixtures to maintain. Because Lakebase branches are copy-on-write, spinning one up per PR is cheap enough to do on every change.

What is a Lakebase branch?

A branch is an independent Postgres environment that shares storage with its parent through copy-on-write. Creating a branch doesn't copy data. It creates a pointer to the same underlying pages, and the branch diverges from its parent only as you write to it. Each branch is fully isolated, with its own endpoint, its own data, and its own Postgres roles, so a schema change or a destructive test on a branch never touches production. Branches appear near-instantly regardless of database size, and you pay only for the data that actually changes. This is the branching model from Neon, now part of Databricks and the serverless Postgres engine behind Lakebase.
One limitation to design around: there is no merge operation between branches. A branch is for isolated testing, not for merging data back. A schema change validated on a branch gets reapplied to the target through your normal migration or deployment process.

The per-pull-request pattern

Stage	What happens	Why it matters
PR opened	CI creates a branch from production	Every PR tests against real, current data, not stale fixtures
CI run	Migrations and tests run on the branch's own endpoint	Isolated, so parallel PRs never collide
PR merged or closed	CI deletes the branch	No orphaned databases and no lingering cost
Safety net	The branch carries an expiration policy	Stray branches expire on their own if a cleanup job is skipped

How Databricks approaches this

Lakebase is generally available, and branching is part of it. You drive the workflow from the Databricks CLI, so it drops into any CI system that can run a shell command. On the event that opens a PR, create a branch from your production branch; on the event that closes it, delete that branch:

# pr.yml - runs when a pull request opens
databricks postgres create-branch projects/PROJECT feature-PR \
  --json '{"spec": {"source_branch": "projects/PROJECT/branches/production", "ttl": "DURATION"}}'

# merge.yml - runs when the pull request merges or closes
databricks postgres delete-branch projects/PROJECT/branches/feature-PR

When you create a branch you must set an expiration policy: a TTL, an explicit expiry time, or an explicit no-expiry. For per-PR branches, a TTL is the safety net. Even if a pipeline fails before the delete step runs, the branch expires on its own rather than accumulating cost. The delete call returns right away, though the underlying teardown can take a little time to finish.
Programmatic branch management continues to evolve: the Terraform resource for branches (databricks_postgres_branch) is in Public Beta, so confirm the exact commands and fields in the current branches documentation and expect the interface to change. Branching is supported on Lakebase Autoscaling; the Provisioned deployment does not offer it. For an end-to-end example, see the branch-based development workflow tutorial and the blog on Git-style database branching on Lakebase.

Use cases

• Migration testing: run a schema migration against a branch of production data on every PR, so you catch a bad migration before it merges, not after it ships.
• Preview environments: point a preview app at the PR's branch to demo a feature on realistic data, then throw the branch away on merge.
• Agent and app development: give each developer, experiment, or test run its own branch, so work is isolated and reproducible without a fleet of standing databases.

FAQs

Is Lakebase branching generally available?

Lakebase itself is generally available, and branching is included. The Terraform resource for branches (databricks_postgres_branch) is in Public Beta, so check the current docs before you build automation on it.

Does a branch copy my production data?

No. Branches are copy-on-write: a new branch points at the parent's storage and only stores the pages you change, so it is created in seconds and costs little until it diverges.

How do I make sure per-PR branches get cleaned up?

Delete the branch in the job that runs when a PR closes, and set an expiration policy (a TTL) when you create it. The TTL is a backstop that removes the branch even if the delete step never runs.

Can I merge a branch back into production?

No. Branches don't merge. Validate the change on the branch, then reapply the schema or data change to the target through your normal migration or deployment pipeline.

Which Lakebase deployment supports branching?

Branching is available on Lakebase Autoscaling. The Provisioned deployment does not support it.