07 · Tables A→ZK · Maintain & tune performance
Vacuum cuts time-travel
The trade-off between reclaiming storage and how far back you can recover.
Vacuum and time-travel pull in opposite directions, and it's the one maintenance interaction that surprises people: pruning old files reclaims space but shortens how far back you can go.
The trade-off
Time-travel, rollback, and restore work by reading old data files. Vacuum deletes files older than its retention window. So after a vacuum:
- The old versions still appear in
get_table_history… - …but recovering to them fails - their files are gone.
Heads up
A version showing up in the history list does not
guarantee you can roll back to it. If
vacuum pruned its files, rollback/restore
to that version fails. History is the log; vacuum can remove the data the log
points at.The knob: retention_hours
vacuum_table(retention_hours = N) - default 168 (7 days) - is your
recovery window.
- Keep ≥ 168 unless you're certain you won't need to recover that far back.
- Lower it only to aggressively reclaim space on tables where time-travel doesn't matter - and know you're trading away recovery depth.
Rule of thumb
Set retention to at least as long as your "oops, undo that" window - how long after a bad write you'd realistically still want to roll back. A week (the default) suits most master data.