Delta Lake time travel: how far back you can go, and how to keep more

By default you can time travel 7 days back on a Delta table, not 30. DESCRIBE HISTORY lists 30 days of versions, because the transaction log is kept that long, but a version also needs its data files, and VACUUM deletes replaced files after 7 days. On Databricks Runtime 18.0 and above, and on Unity Catalog managed tables from Runtime 12.2, a query older than that limit is refused outright.

That gap surprises people at the worst moment: someone finds a bad MERGE from 10 days ago, sees the version in the history, and cannot read it. This article is about how far back you can go and how to go further. How time travel and RESTORE work is in part 1 of our Delta Lake course module, and what VACUUM deletes is in VACUUM LITE explained.

The 2 settings

The shorter of the 2 is your time travel limit. Raising only the log retention lengthens the history list but not what you can read. Raising only the file retention does nothing past 30 days, because the log entries go. On Databricks Runtime 18.0 and above, and Unity Catalog managed tables, the log retention must be at least the file retention.

On Unity Catalog managed tables, predictive optimization runs VACUUM for you, so the 7-day limit applies whether or not anyone schedules a vacuum. In open-source Delta Lake, data files are deleted only when someone runs VACUUM, but the log still goes after 30 days.

To keep 90 days, set both:

ALTER TABLE main.sales.orders SET TBLPROPERTIES (
  'delta.deletedFileRetentionDuration' = 'interval 90 days',
  'delta.logRetentionDuration' = 'interval 90 days'
);

-- 60 days later, this still works:
SELECT * FROM main.sales.orders TIMESTAMP AS OF date_sub(current_date(), 60);

What longer history costs

Every UPDATE, MERGE, DELETE and OPTIMIZE writes new files and marks old ones as removed. Those removed files are what time travel reads, and they stay on storage for the whole retention period. So the extra storage is roughly what your daily changes replace, times the days you keep.

Take a 2 TB table where each day's MERGE rewrites files holding 5% of it, 100 GB a day, on S3 Standard at $0.023 per GB a month:

A year of daily history costs over 18 times what the table itself does ($46 a month). The table's size matters less than how much of it changes: an append-only table removes almost nothing and keeps history cheaply, while a table rewritten every night keeps a full copy for every day.

Try itWhat a longer time travel window costs

Table size

2000GB

Replaced each day

5%

Time travel window

90days

Compare with

12 monthly clonesNothing

90 days of history$253

12 monthly clones$598

The table Removed files kept for time travel Clones

History costs 4.5× the tableHistory costs lessRaise both retention settings

When to keep copies instead

Databricks says not to use table history as a long-term backup. For anything you must keep (month-end figures, the data a model was trained on, an audit snapshot), take a deep clone: an independent copy at one version, which VACUUM on the source never touches.

-- Month-end snapshot, kept as its own table
CREATE TABLE main.archive.orders_2026_10 DEEP CLONE main.sales.orders;

-- The exact data a model was trained on
CREATE TABLE main.ml.orders_train_v15 DEEP CLONE main.sales.orders VERSION AS OF 15;

12 month-end clones of the 2 TB table are 24 TB, $552 a month, against $839.50 of removed files for 365 days of history. Each clone holds the whole table, so for a table that changes little, a long retention can cost less; compare the 2 for your own table. A clone does not copy the source's history, only the version you clone.

If records must be gone for good (a deletion request, for example), long retention works against you: deleted rows stay readable in old files until VACUUM removes them after the retention period. With deletion vectors on, run REORG TABLE ... APPLY (PURGE) first, then let the retention pass and vacuum.

What to do

1. Treat 7 days as your undo window unless you have changed both settings. Check with SHOW TBLPROPERTIES.
2. If you need longer, raise both properties together, and estimate the storage from how much the table changes each day.
3. For month-end, audit or training snapshots, deep clone on a schedule rather than keeping a year of history.
4. Before a risky MERGE or backfill, note the version from DESCRIBE HISTORY ... LIMIT 1, so RESTORE TABLE ... TO VERSION AS OF is one line if it goes wrong.

The format itself is explained in Delta LakeDelta LakeAn open table format that turns Parquet files in cloud storage into a table with transactions, a version history, schema checks, and updates and deletes, so a data lake behaves like a database., and how Delta compares with Iceberg on history and maintenance is in Delta Lake vs Apache Iceberg.