How do I roll out database branching to my development team?

Summary

• Create a branch hierarchy with production, development, staging, and per-developer branches so each developer works in isolation.
• Set up a shared starting schema on your development branch so new branches inherit the same structure and sample data.
• Use Lakebase's copy-on-write technology to create branches in seconds and store only the changes developers make.
• Automate branch creation and deletion in your CI/CD pipeline so every pull request gets a fresh isolated database.

How do I roll out database branching to my development team?

Database branching lets each developer work in an isolated copy of your database, just like Git branching for code. Rolling this out to your team means establishing a branch strategy, starting with a common schema, and automating branch creation in your CI/CD workflow. Lakebase branching gives each developer their own workspace, eliminating contention and letting developers test against real data shapes from the first line of code.

What is database branching?

Database branching creates independent copies of your database schema and data that developers can modify without affecting each other or production. Changes in a child branch never affect its parent. Branches are copy-on-write, so they're created instantly and only store the data that actually changed, making them storage-efficient.

Branching strategy for teams

Branch Type	Purpose	Who Uses It
Production	Live database serving users	Automated deployments only
Development	Shared starting point with schema and sample data	All developers start here
Staging	Pre-production testing environment	QA and release leads
Per-Developer	Isolated workspace for individual development	Each developer gets one on demand

How Databricks approaches team branching

Step 1: Create your branch hierarchy

Lakebase creates a single production branch by default. Add a development branch as your team's shared starting point. You can also create staging for pre-release testing. Each branch is independent, so changes in development or staging never touch production.

Step 2: Set up a shared starting schema

On your development branch, create the database schema and tables that every developer needs. Add sample data so developers can test queries immediately:

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  email TEXT NOT NULL UNIQUE,
  created_at TIMESTAMP DEFAULT NOW()
);

CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  user_id INTEGER REFERENCES users(id),
  order_date TIMESTAMP,
  total DECIMAL(10, 2)
);

When a developer creates a personal branch from development, they instantly inherit this schema and data through copy-on-write. No manual setup needed.

Step 3: Implement per-developer branching

Each developer gets their own branch created on demand using the databricks postgres create-branch command or through the Lakebase UI. This isolates their work and eliminates the anti-pattern of sharing a development database where developers block each other. Developers can reset their branch in one command to pull in the latest schema from development if their branch drifts too far.

Step 4: Automate CI/CD integration

For pull request workflows, create a branch automatically when a PR opens and delete it when the PR merges or closes. This means every test run gets a fresh isolated database with no leftover state from previous tests. Migrations run against real data shapes and constraints, not empty test fixtures, so you catch problems before production.

Permissions and access

To create, delete, or update branches, team members need CAN MANAGE permission on the project. To create databases or roles within a branch, or to view and list branches, they need at least CAN USE permission. Assign permissions at the project level rather than per-branch to keep access management simple.

Benefits for development teams

Instant creation: Branches are created in seconds using copy-on-write technology. No waiting for provisioning or backup procedures.
Storage-efficient: Only modified data is stored separately. If a developer's branch hasn't changed much, it takes minimal storage.
No contention: Each developer works in isolation. There's no serialization, no shared locks, and no "production data in dev" problems.
Faster development: Developers test against real production-shaped data from the first line of code, eliminating the "works on my machine but breaks in staging" problem.

Use cases

Schema migration testing: Create a branch, run your migration, test it against real data, and if it breaks, reset and try again without affecting development or staging.
Feature branch development: A developer creates a branch, builds their feature with test data in isolation, then merges the schema and data changes back to development.
CI/CD automation: Every test suite run gets a fresh database. No flaky tests from leftover test data.
Rapid experimentation: Data engineers prototype queries and transformations without blocking other team members.

FAQs

How do developers create their own branch?

They run databricks postgres create-branch <branch-name> --parent development or create it through the Lakebase app. It takes seconds and inherits everything from the development branch.

Can a developer mess up the production branch?

No. Changes in a child branch never affect its parent. A developer working in their personal branch can't change production. Only intentional merges move data or schema back up the hierarchy.

What if my development branch gets out of sync?

A developer can reset their personal branch to pull the latest schema and data from development in one command. This is equivalent to deleting and recreating the branch.

Do branches cost extra?

Branches use copy-on-write storage. You only pay for the data that's actually different from the parent branch. A developer who makes minor changes to a few rows pays very little.

How do we handle database migrations across branches?

When you run a migration in development, all child branches automatically see the schema change. Developers can test how their code interacts with new schema versions before those changes reach production.