07 · Tables A→ZI · Version, time-travel & recover
How Delta versioning works
Every write is a numbered Delta version - the basis for diff, time-travel, rollback, and restore.
Because every Eddytor table is a Delta Lake table, every mutation creates a new numbered version. That transaction log is what makes diffing, time-travel, rollback, and restore possible - it's the "Ctrl+Z" for your data.
What counts as a version
Each committed write is one version: CREATE TABLE (v0), then every
MERGE / UPDATE / DELETE / ADD COLUMN / domain change, and also maintenance
(OPTIMIZE, VACUUM).
Good to know
Batch your writes. One
merge_rows
of 1000 rows is one version; 1000 single-row writes are 1000 versions. Fewer,
larger writes keep history readable and reduce compaction churn.Leave breadcrumbs
Add a comment to significant writes - it's recorded on the version and shows
up in the history, making good rollback points easy
to find:
{ "comment": "Q1 price adjustment - approved by finance", "rows": [ … ] }What you can do with versions
| Goal | Tool |
|---|---|
| See the list of versions | get_table_history |
| See what changed between two | diff_table_versions |
| Reset to a version number | rollback_table - destructive |
| Reset to a point in time | restore_table - destructive |
Heads up
OPTIMIZE / VACUUM are versions too - don't mistake an
OPTIMIZE commit for a data change when picking a recovery point. And
vacuum with low retention deletes old files, so you can
no longer roll back past them (default retention 168h / 7 days).The safety-net pattern
Before any destructive change (bulk delete, schema/domain change):
get_table_history→ note the current version.- Make the change.
validate_constraints+profile_table.- Wrong?
rollback_tableto the noted version.