Database Branching

A database is the place where an app permanently stores its data: user accounts, orders, messages. Anyone changing something in such an app doesn’t want to break that data. Database branching solves this problem by creating a branch: a second, independent version of the database that has the same content as the original at that exact moment. In this branch you can delete data, restructure tables, or test new features without the original noticing anything. If the test goes wrong, you simply throw the branch away. If it succeeds, you transfer the change to the real database.

Why developers no longer want to test on the real database

In the past, many teams had exactly one test database for everyone. Whoever was using it at the time blocked everyone else. And if someone accidentally deleted all the records, several people were stuck. With their own branches, every person and every task gets its own environment.

The second reason is realism. An empty test database behaves differently from one with millions of rows. Bugs that only appear with large amounts of data are never found there. A branch, on the other hand, contains exactly the structure and scope of the real data. This allows testing under realistic conditions without putting the original at risk.

It’s important to understand the difference from a backup. A backup is a safety copy for emergencies and is rarely touched. A branch is a temporary workspace that you deliberately use and then discard afterward. Both are copies, but they serve completely different purposes.

The trick with shared storage

A real copy of 500 gigabytes of data would take a long time and cost a lot of space. That’s why database branching initially copies nothing at all. The new branch only gets a reference to the existing data. It reads the same storage blocks as the original.

Only when something is changed in the branch does a real copy come into existence – and only of the tiny part that changes. This principle is called copy-on-write, meaning copying only happens upon writing. You can imagine it like a shared script: everyone reads the same original, and only whoever wants to edit a page pulls their own version of exactly that one page.

That’s why a branch is usually ready in one to two seconds and initially takes up almost no storage. It only grows to the extent that it is modified. A typical test branch therefore often stays under one percent of the original’s size. The model for this is the software Git, which programmers use to manage their program code in branches – database branching transfers this idea to data.

From the cloud database to the pull request

Providers of modern cloud databases such as Neon, PlanetScale, or Supabase explicitly advertise this feature. You click a button or type a command, and the branch exists. Classic databases on your own servers usually can’t do this without additional software. This is one of the reasons why many teams switch to the cloud in the first place.

In day-to-day work, it often happens automatically. If a developer proposes a change to the program code, the system automatically creates a matching database branch for it. The automated tests run there. Once the proposal is accepted or rejected, the branch deletes itself again.

The term is also increasingly appearing in connection with AI tools. When a coding assistant is supposed to independently try out changes to a database, it is given a branch instead of the real data. If it causes damage there, it costs nothing. Incidentally, a common misconception is that a branch is automatically privacy-compliant. It contains the same real customer data as the original – anyone who doesn’t need it must anonymize it beforehand.