Database Branching

FilesBranchingCI / CDIsolation

Stable On by default · production-ready

What it is

Database Branching lets you create a fully-functional copy of a database — schema, data, and history — in well under a second, regardless of how much data the original holds. The copy shares storage with its parent until you start modifying it; only the changes you make consume new space. A branch behaves exactly like the parent database for queries, writes, schema changes, and deploys.

This is the same branch / merge / rollback surface used for schema-as-code migrations — branching the data and branching the schema are one operation.

Why it matters

“Test on a copy of production” used to mean a dump-and-restore that took hours and cost a sizeable chunk of disk. So engineers either tested on undersized fixtures (and missed bugs) or risked changes directly against production. Cheap branches collapse that tradeoff.

Fast clone — branch creation is independent of data size.
Low overhead at create time — branches share storage until they diverge.
Atomic merge or discard — promote a branch in one operation, or drop it cleanly.
Conflict detection — concurrent edits to the same data are surfaced before merge, not silently overwritten.

sequenceDiagram
  participant Dev as Engineer
  participant Eng as AetheriusDB
  participant Main as production
  participant Feat as experiment_env

  Dev->>Eng: CREATE BRANCH experiment_env FROM production
  Eng-->>Feat: branch created (no data copied)
  Dev->>Feat: run migration + tests
  alt looks good
    Dev->>Eng: MERGE BRANCH experiment_env INTO production
    Eng->>Main: check conflicts, fast-forward
  else discard
    Dev->>Eng: DROP BRANCH experiment_env
    Eng-->>Feat: gone; production unaffected
  end

How you use it

Create a branch with one statement; query it like any database; merge or drop when done. Branches can fork from a specific historical moment, so you can debug a past state without losing the present.

-- Fork production as it stood yesterday.
CREATE BRANCH experiment_env
  FROM production
  AS OF TIMESTAMP 'yesterday';

-- Use the branch, run migrations and tests against it.
USE BRANCH experiment_env;
ALTER TABLE orders ADD COLUMN discount_v2 DECIMAL(5,2);

-- Merge the branch back if everything looks good…
MERGE BRANCH experiment_env INTO production;

-- …or throw it away.
DROP BRANCH experiment_env;

Branches respect your role and row-level security policies, so an analyst’s branch shows the same data they can already see in production — branching is never an escalation vector.

Key concepts

Concept	What it means
Branch	A named, isolated view of the database that shares storage with its parent until modified.
Fork point	The moment in history the branch was created from — “now” or any past timestamp.
Merge	An atomic operation that integrates a branch’s changes back into its parent.
Conflict detection	Checks at merge time that surface concurrent edits before they silently overwrite each other.

Schema-as-Code & Migrations →

The same branch / merge / rollback surface for schema changes.

Git-Native Source Fabric →

Branch database logic the same way you branch data.

Reactive Pipelines →

Branches preserve cascade definitions, so experiments include live processing.

Time Travel →

Read and fork from any past point in time.