Skip to content

CONCEPT Cited by 1 source

Database branching

Definition

Database branching is the workflow primitive of creating an isolated sandbox copy of a production database's schema (and, on some platforms, its data surface) as the unit of schema-change development. The developer edits the schema on the branch, tests applications against it, and when satisfied opens a deploy request to merge the branch's schema back into the production target — the database-tier analog of a git branch + pull-request workflow. The branch is created from the production schema at fork time, which establishes the three-way diff baseline that later pre-flight conflict checks use to detect concurrent changes to the same columns/tables.

Canonical verbatim introduction (Burns, 2021 PlanetScale):

"We provide a database branching feature that allows users to create sandbox environments for testing database changes. When a user needs to make a schema change, they create a database branch from their production database, which is automatically deployed with a copy of the production schema. The user can test out schema changes on their branch without worrying about impacting the production database."

(Source: sources/2026-04-21-planetscale-non-blocking-schema-changes.)

Why it exists

The pre-branching alternative is editing production schema directly (with or without an ALTER review ticket) — which conflates two activities that should be separate:

  1. Authoring the change — iterating on a column type, a new index, a table rename. Wants fast feedback; wants to break things; wants a clean environment.
  2. Applying the change to production — is transactional, auditable, and must not interfere with live traffic.

Branching separates these into two stages. Authoring happens on the branch's copy-of-production; applying happens via a deploy request against main. The branch provides:

  • Isolation — edits on the branch don't touch production state.
  • Reproducibility of schema — the branch starts from the exact current main schema at fork time.
  • A diff baseline — later conflict checks compare branch-HEAD against main-HEAD-at-fork and against main-HEAD-now.
  • A testable unit — the developer can point their application's test suite at the branch to verify the schema change works end-to-end before requesting deploy.

Branching on PlanetScale's 2021-era stack

Burns's 2021 description canonicalises the following properties:

  • Branch is created on demand by the developer ("When a user needs to make a schema change, they create a database branch").
  • Branch is automatically deployed — the platform provisions the schema copy without operator intervention.
  • Branch inherits schema only from production — the 2021-era post emphasises schema isolation, not data cloning.
  • Branch is isolated from production's live traffic — schema experimentation cannot impact production.
  • On merge: a deploy request opens, conflict-checks run (see concepts/pre-flight-schema-conflict-check), and the change enters the deploy queue for non-blocking migration.

Contrast: schema-version tools without branching

Liquibase and Flyway provide schema versioning + deployment management but do not provide database branching — they track schema changes as ordered migration files in a VCS, which gives version history but not the isolated-sandbox development environment. PlanetScale's positioning in the 2021 post is that branching is the missing primitive: "While other technologies have grown more and more developer friendly, databases remain difficult to use, in part because of the challenges schema changes present." (Burns, 2021).

Seen in

Last updated · 378 distilled / 1,213 read