07 · Tables A→ZI · Version, time-travel & recover
Rollback vs restore
Two ways back - by version number or by timestamp - both destructive. Which to use.
rollback_table and
restore_table both return a table to an earlier
state. The only difference is how you name the target.
| Rollback | Restore | |
|---|---|---|
| Target | Version number (version=41) | UTC timestamp ("2026-06-15T14:30:00Z") |
| Use when | You know the exact good version | You know roughly when it was good |
| Find it via | get_table_history version column | history timestamp column |
| Destructive? | Yes - discards versions after the target | Yes - discards versions after the target |
| Interface | CLI · MCP · Web UI | CLI · MCP · Web UI |
They both truncate forward
Heads up
Neither is a soft "new commit on top" - both discard the
versions after the target. So the choice is purely about whether you have a
version number or a timestamp. Always check the history,
confirm, and validate afterward.
Pick one
- You diffed two versions and know v40 was
good →
rollback_table(table, version=40). - A bad batch ran "sometime this morning" and you know the time →
restore_table(table, timestamp="…Z").
What neither can do
- Recover a dropped table -
drop_tabledeletes the data and the Delta log, so there's no history to roll back to. Rollback and restore work only on a table that still exists. - Reach past vacuum - pruned files make older versions unreachable (default retention 168h / 7 days).