Turing DB
Most graph versioning conversations stop at temporal tracking: valid-time, transaction-time, bitemporal models that let you ask ‘what did this graph look like last Tuesday’. This is useful for audits, but less for asking ‘what would this graph look like if I changed it’.
The need for this is more common than you’d expect. In some of my projects it was, in fact, crucial. Clinical trial optimization (what if we do this before that?), logistic optimization (will cost be reduced if we reroute via this path?), water mining network optimization… Using a computational graph with, say, AMPL or Gurobi is a powerful technique.
Now, git-like versioning is a different proposition. Branching, commits, diffs, merges applied to graph state rather than file state. The operational payoff: a knowledge graph branch is a sandbox for simulation, not just a snapshot in history. Branch off production. Remove a supplier node, add a regulation node, reroute a relationship, bulk-reclassify a taxonomy. Run your queries, your centrality measures, your SHACL validation against the branch. See exactly what breaks, what cascades, what gets quarantined before any of it touches the graph people actually depend on.
That’s a fundamentally different workflow than ‘…log the change and hope someone checks the diff later’. It’s closer to how software teams treat infrastructure.
Few graph databases do this properly and most claim versioning and deliver an append-only changelog. The distinction matters, a changelog tells you what happened while a branch lets you find out what would happen, on the actual graph, with actual constraints, before you commit to anything. Note that all of this is not specific to RDF or LPG (or TypeDB, SurrealDB…).
⚛ TuringDB is one of the few actually built around this. Its storage layer is columnar and immutable by design which is what makes git-like branch/commit/merge semantics possible without locking readers out while writers experiment. You create a change, mutate it however you like, query it under snapshot isolation, and only merge to main once it survives scrutiny. Versioning isn’t bolted onto the engine after the fact; it’s the structural reason the engine can do zero-lock concurrent reads and writes at all.
If your pipeline already includes validation, branch-based simulation is where that validation earns its keep. Not gatekeeping single writes, but stress-testing entire hypothetical states.
⚛ TuringDB