Dataset Version Control: Branch, Diff, and Merge a Table
Schemas have migrations and code has git; the rows themselves usually have neither. Dataset version control commits a table's contents, hashed row by row, so you can branch from a point in history, see exactly what changed between two commits, and merge a branch back with conflicts flagged rather than silently overwritten.
Before you start
- A Data Console source or an Agent Gateway.
- A table worth versioning — reference data, configuration, and curated datasets benefit most.
- An understanding that checkout is read-only: viewing history never writes back to the live table.
Steps
- 1
Open a Data Console source (or an Agent Gateway) and click 'Version control' — pick the table you want history for
- 2
Commit a snapshot: it's hashed row-by-row and stored — unchanged rows cost nothing extra, only what actually changed is written
- 3
Branch off any point in the history to try changes in isolation, without touching the branch others rely on
- 4
Diff any two commits to see exactly which rows were added, removed, or changed, with before/after values for a sample
- 5
Merge a branch back: rows only one side touched apply automatically; rows both sides changed differently are flagged as conflicts, not silently overwritten
- 6
Checkout any past commit to view the table exactly as it looked then — read-only, nothing is written back to the live table
- 7
On an Agent Gateway, every approved agent write auto-commits onto an 'agent-writes' branch — so an agent's change is diffable and revertible through full history, not just a single-action undo
What goes wrong
Storage is proportional to change, not to table size
Rows that did not change between commits are not stored again. A large, mostly-static table is cheap to version; a small, entirely-rewritten one is not.
Conflicts are surfaced, never resolved for you
When both sides changed the same row differently, there is no correct automatic answer. The merge flags it and waits, because guessing here means losing an edit somebody made deliberately.
Agent writes get history, not just undo
Approved agent writes commit onto their own branch. That means a change made three days and forty writes ago is still diffable and revertible — which a single-action undo cannot do.
Next
Agent Gateway: Connecting an AI Agent
Give an AI agent a scoped, audited door into a database — structured tools instead of raw SQL, with writes gated behind approval.
Data Console: Browsing a Database Safely
Give people access to production data without giving them production credentials, with PII masked unless explicitly granted.