This "branching" could be thought of as a generalized kind of ACID transaction. After all, a transaction mimics having an isolated snapshot of your database, a

This "branching" could be thought of as a generalized kind of ACID transaction. After all, a transaction mimics having an isolated snapshot of your database, a one-level-deep temporary branch that is merged back on commit, and which can (like version control merges) fail on conflict. I'd love to see a database that supported branching in this way. The difficulty here isn't really the technical implementation of the branching at the data store level, which is rather trivial, but the merging. The challenge is exactly the same as a version control system like git. git can leave conflict merging to a human operator, but a database system can't, unless you bubble the conflict up to the client, which will work in some cases (interactive UIs) and not in others (automated sysrems). To support any kind of conflict resolution at all, values and updates need to be reformulated as CRDTs or some similar mechanism that can provide conflict-solving semantics. Instead of recording tuple changes as simple value assignments, they need to be merged as operations -- if x starts out as 42, then doing "update ... set x = x + 1" is the equivalent of "set x = 43" in a typical modern RDBMS transaction, but to preserve the semantics in the face of a conflicting merge, the transaction log needs to be recorded as "x = x + 1".