#Branching and Merge Workflows

In most graph databases, there is one copy of the data and every change touches it immediately. Want to try a reorganization? You are doing it live. Want to test a data migration? Hope it works, because there is no undo. Want to know what the graph looked like last Tuesday? You can’t — that state is gone.

WWKG works like git, but for data.

#What you could not do before

Traditional graph databases have no concept of branches, commits, or history. Every write mutates shared state in place. That means:

• Draft changes and production data share the same state.
• There is no safe way to stage, review, or roll back a large change.
• Concurrent imports block each other or risk inconsistency.
• Historical state is lost the moment new data overwrites it.
• “What if” analysis requires copying the entire database.

Teams work around this with database snapshots, manual backups, and elaborate ETL staging pipelines. It works, barely, and it is fragile.

#What WWKG enables

Instant, zero-cost branching. Creating a branch records a pointer — nothing is copied. A billion-quad graph branches in milliseconds. The branch shares all existing data with its source until changes create new versions along diverging paths.

Safe parallel work. Multiple teams, import pipelines, and experiments can work on separate branches simultaneously. Nothing touches the main branch until the work is reviewed and merged. A failed import is simply abandoned — the main branch was never at risk.

Concurrent bulk imports. Upload hundreds of files in parallel, each on its own sub-branch, then merge them into a batch branch and finally into main — one clean merge instead of a fragile serial pipeline.

Three-way merge. WWKG finds the common ancestor of two branches, computes the changes on each side, and merges them. Because the data model is based on triples — atomic statements that are either present or absent — merges are clean by construction. There are no line-level conflicts to resolve.

Time travel. Every change produces an immutable commit. You can query the graph as it existed at any commit — what the org chart looked like last quarter, what a report contained before a correction, what the supply chain said about a supplier six months ago.

Diff between any two points. Compare branches, compare commits, or compare today’s data with last month’s. See exactly what was added, removed, or changed — like git diff for your knowledge graph.

Cross-branch queries. Run a single query that reads from multiple branches at once — compare the staging version of a dataset with the production version, in one request.

#A concrete scenario

A pharmaceutical company is preparing a regulatory submission. The regulatory affairs team stages the new data on a branch while clinical operations continues querying the current production graph. The regulatory team runs validation, fixes issues, and iterates — all without affecting live reporting. When the submission is ready, they merge. If the regulator asks “what did the data look like when you submitted?”, the answer is a single query against that commit.

The same pattern works for a corporate reorganization, a product catalog refresh, a pricing model change, or a merger integration.

#What makes this different

Most databases that offer any kind of versioning do it through snapshots — full copies at scheduled intervals. WWKG’s branching is fundamentally different: changes are proportional to what actually changed, not to the total size of the database. A branch that modifies 100 records in a billion-record graph creates only the blocks that differ. Old and new versions share everything else.

This means branching is not an expensive operation you do occasionally. It is a cheap, routine operation you do constantly — for every import, every experiment, every staging workflow.

Every commit is signed by the identity that created it. The full chain of changes — who wrote what, when, and what the data looked like before and after — is permanently recorded and independently verifiable. This is not an audit log bolted onto the side. It is the database itself.

#Next steps

Continue with the Branching guide for the operational workflow. Related features: End-to-End Encryption, Peer-to-Peer Distribution, and Reasoning and Validation.