What is time travel in a lakehouse table?

Summary

• Time travel lets you query a table as it was at an earlier version or time. Delta Lake keeps each write as a version in its transaction log, and Apache Iceberg keeps each write as a snapshot. Spark SQL uses the same VERSION AS OF and TIMESTAMP AS OF clauses for both.
• Delta Lake time travel needs both the log and the data files. Log history is kept for 30 days by default, but VACUUM can remove unreferenced data files after 7 days, which ends time travel to the versions that used them.
• Iceberg keeps every snapshot until expire_snapshots removes it. That procedure's default cutoff is snapshots older than 5 days.
• Time travel reads old data without changing the table. To make an older state current, use RESTORE in Delta Lake or rollback_to_snapshot in Iceberg.

What is time travel in a lakehouse table?

Time travel is the ability to query a table as it existed at an earlier version or point in time. Table formats keep that history as metadata. Delta Lake records each write as a new version in its transaction log, and Apache Iceberg records each write as a new snapshot. A time travel query reads the data files that belonged to that version, and the current table stays as it is. The Delta Lake docs list these uses: re-creating analyses and reports, debugging and auditing, writing temporal queries, fixing mistakes in your data, and giving a set of queries snapshot isolation on fast-changing tables.

How does time travel work in Delta Lake?

DESCRIBE HISTORY my_table;                                     -- find version numbers
SELECT * FROM my_table VERSION AS OF 5;
SELECT * FROM my_table TIMESTAMP AS OF '2026-06-15 14:30:00';
RESTORE TABLE my_table TO VERSION AS OF 5;                     -- make version 5 current again

A version is a long that you can read from DESCRIBE HISTORY. A timestamp can be any string or expression that casts to a timestamp. In the DataFrame API, use the versionAsOf and timestampAsOf options. RESTORE is recorded as a new version in the history. Time travel by timestamp can break if you copy the whole table directory to a new location, because each version's timestamp comes from its log file. Time travel by version is unaffected.

How does time travel work in Apache Iceberg?

SELECT * FROM prod.db.table.snapshots;                          -- find snapshot IDs
SELECT * FROM prod.db.table VERSION AS OF 10963874102873;
SELECT * FROM prod.db.table TIMESTAMP AS OF '1986-10-26 01:21:00';
CALL prod.system.rollback_to_snapshot('db.table', 10963874102873);  -- Spark 3.x needs the Iceberg SQL extensions

VERSION AS OF takes a long snapshot ID or a branch or tag name. FOR SYSTEM_TIME AS OF and FOR SYSTEM_VERSION AS OF also work, but FOR SYSTEM_TIME AS OF expects a timestamp (a bare number is read as Unix seconds), so use FOR SYSTEM_VERSION AS OF for a snapshot ID. In the DataFrame API, the snapshot-id and as-of-timestamp options (milliseconds) select a snapshot. A tag pins a snapshot: expire_snapshots doesn't remove snapshots that branches or tags reference, and by default branches and tags never expire.

How do the two formats compare?

Aspect	Delta Lake	Apache Iceberg
Version identifier	Table version number	Snapshot ID (a long), or a branch or tag name
Spark SQL clauses	VERSION AS OF, TIMESTAMP AS OF	VERSION AS OF, TIMESTAMP AS OF, FOR SYSTEM_TIME AS OF, FOR SYSTEM_VERSION AS OF
DataFrame options	versionAsOf, timestampAsOf	snapshot-id, as-of-timestamp
List history	DESCRIBE HISTORY	history and snapshots metadata tables
Make an old state current	RESTORE	rollback_to_snapshot, rollback_to_timestamp
What ends time travel	Log cleanup (30 days by default) or VACUUM of data files (7 days by default)	expire_snapshots (default cutoff: older than 5 days)

How does Databricks handle time travel?

Databricks documents time travel for Delta Lake and Apache Iceberg tables, using TIMESTAMP AS OF and VERSION AS OF plus @ forms such as people10m@v123. Table history retention is logRetentionDuration, 30 days by default, but the docs say to rely on only the past 7 days unless you raise both the data and log retention settings. On Databricks Runtime 18.0 and above, time travel queries are blocked for versions older than deletedFileRetentionDuration (default 7 days), and Unity Catalog managed tables apply this on 12.2 and above. The docs list branching and tagging as unsupported for Iceberg tables, and for foreign Iceberg tables time travel works only for snapshots that were previously read in Databricks. The docs also say not to use table history as a long-term backup.

FAQs

How far back can I time travel?

In Delta Lake, as far back as both the log and the data files are retained. Log cleanup happens after checkpoints, so you can lose a version a little sooner than the interval suggests. To keep 30 days of data files even after VACUUM, set delta.deletedFileRetentionDuration to 30 days, which may raise storage costs. In Iceberg, expired snapshots are gone for time travel, and the table properties history.expire.max-snapshot-age-ms (5 days) and history.expire.min-snapshots-to-keep (1) set the defaults for expiry.

Does time travel change the table?

No. It reads an older state. To make that state current, use RESTORE or rollback_to_snapshot. To recover only some rows, query the earlier version and insert them back.

How do I use time travel from PySpark?

spark.read.option("versionAsOf", 5).table("my_table")
spark.read.option("snapshot-id", 10963874102873).table("prod.db.table")