Database branching is the missing primitive in modern development workflows. Every other part of the stack has evolved to support fast iteration. Code has Git. Infrastructure has Terraform. Deploys have CI/CD pipelines that run in minutes. But relational databases still work the way they did ten years ago.

Most teams share a single staging database. Within days of being set up, that database drifts out of sync with production. Schemas diverge as developers apply migrations in different orders. Sequence values no longer match. Test data accumulates and pollutes results. Someone eventually reseeds the whole thing, and the cycle starts over.

Setting up a new environment is worse. The standard approach is to run pg_dump against production, wait for it to finish (minutes to hours depending on database size), load it into a new instance, configure access, and hope the result actually reflects what is running in production. For a 500GB database, this means a 500GB copy operation, plus the compute and storage to keep it running.

The result is predictable. Teams avoid creating new environments because they are too expensive and too slow. Developers share a single mutable staging database. Migrations get tested against stale data, or not tested at all. Preview deployments run against empty fixtures instead of realistic schemas. CI tests share state and produce flaky results.

A database branch is not a database copy. This distinction matters because it changes the economics of isolated environments entirely.

When you copy a database, you duplicate all of its data and schema into a new, independent instance. The time and cost scale linearly with the size of the database. Every copy is a full clone, and every clone starts going stale the moment it is created.