Versioned data with branches
Branching a database the way you branch code: a private copy for a pull request, a test run or an experiment, made in seconds, with history you can go back to.
What it asks of a system
Two kinds of system cover this. Storage-level branching, as in Neon, makes a copy-on-write clone of a whole database at a point in time: the branch shares unchanged data with its parent, so it is created almost at once and costs only what it changes, which suits preview environments and testing migrations on real data. Branches cannot be merged back, though. Data version control, as in Dolt, puts Git’s model on the tables themselves: commits, branches, row-level diffs and merges with conflicts, so changes to data can be reviewed and merged like code.
When you compare, check what a branch is (a whole database or a set of tables), how long creating one takes on a large database, whether you can diff and merge or only fork and discard, how far back history goes and what keeping it costs, and whether the branch speaks the same protocol as production so the application needs no changes.
Good at it · 4
Compare side by sideRelational databases
DoltOpen sourceCommits, branches and cell-by-cell merges are SQL procedures, diffs and history are system tables, and `AS OF` reads any past commit.A MySQL-compatible SQL database with Git’s model built in: every table can be branched, diffed, merged, pushed and pulled, and every commit keeps the whole database as it was.Sources
Why each technology is listed comes from the sources on its own page.
