What is data version control?

Data version control is keeping a history of changes to your data over time — like git does for code — so you can see what changed, compare states, and revert to any earlier version. Instead of only having the current state of a table, you keep the timeline of how it got there.

How is data version control different from a database backup?

A backup is a full snapshot you restore all-or-nothing, usually to recover from disaster. Version control is a fine-grained, ongoing history: you can revert a single change without rolling the whole database back, and you can see exactly what changed between versions.

Is data version control the same as a database transaction?

No. A transaction (COMMIT/ROLLBACK) is a short-lived, all-or-nothing unit of work that can only be undone before it commits. Version control keeps a durable history you can step back through long after changes were applied.

Can I version data across different databases at once?

With most tools, no — history is tied to one database engine. Varan keeps a git-style history across PostgreSQL, MySQL, DuckDB and files in one workspace, so you can revert changes regardless of where the data lives.

Varan Join the beta →

Varan › Data version control

Data version control: git for your data

Your code has a full history — every change, who made it, and a one-click revert. Your data usually has none of that. Data version control brings the git model to the tables and files you work with.

The Varan workspace running a cross-source SQL query, where a git-style version history of your data lives — Varan keeps a version history of your data alongside cross-source queries.

What it actually means

Most databases only keep the current state of a table. Do an UPDATE and the old values are simply gone. Data version control keeps the timeline instead:

History — every change is recorded, not overwritten.
Diff — see exactly what changed between two points in time.
Revert — roll a specific change back like reverting a commit, without touching everything else.

Why transactions and backups aren't the same thing

	What it protects	Limitation
Transaction (COMMIT/ROLLBACK)	A single in-flight unit of work	Gone the moment you commit — see database rollback
Backup / snapshot	Disaster recovery of the whole DB	All-or-nothing restore; loses everything after the snapshot
Version control	Every change, over time	Revert one change, keep the rest — like git

Transactions are a pre-commit safety net. Backups are a blunt whole-database rewind. Version control is the fine-grained, after-the-fact history most people actually want when they say "can I undo that?"

Why it's hard to get

Real data is scattered across a PostgreSQL server, a MySQL server, a DuckDB file and stray spreadsheets — and each has its own idea of history (or none). Stitching a single timeline across all of them by hand is impractical, so most teams just don't have one.

How Varan does it

Varan keeps a git-style version history across every source in your workspace — PostgreSQL, MySQL, DuckDB and files — so you can see what changed and revert an already-applied change without a DBA restore or an engine-specific flashback feature. It sits alongside cross-source SQL, column-level lineage and anomaly detection, so you can trust, trace, and undo your data in one place.

Give your data a history

Version, diff and revert across your sources. Free during the beta — macOS, Windows and Linux.

Request beta access →

FAQ

Is data version control the same as git?

Same idea, applied to data instead of code — a recorded history you can diff and revert. Varan brings that model to databases and files.

Can I undo a change after it's committed?

Yes — that's the point of a history. See what is database rollback for how this differs from SQL ROLLBACK.