Momentum One Academy · glossary
Delta Lake Time Travel
Definition
Delta Lake time travel is the read-only ability to query a Delta table as it existed at a specific table version or timestamp. Each committed change adds a version to the table’s transaction history. Delta uses that history, together with the referenced data files, to reconstruct the requested snapshot. A time-travel query does not roll back the table, overwrite its current version, or create a new current version. 1
Where it sits in Fabric
Fabric uses Delta Lake as its common table and storage format in OneLake. Time travel therefore sits at the Lakehouse table-history layer: the transaction log records changes, while Parquet files provide the data for each snapshot. The clearest hands-on surface is Spark SQL in a Fabric notebook or Spark job; PySpark can perform the same kind of historical read. A Lakehouse also exposes Delta tables through a read-only SQL analytics endpoint for supported T-SQL scenarios, but that endpoint is not a substitute for every Spark-only Delta operation. 2 3 4
When to use it
Use time travel to audit a prior state, investigate a pipeline change, reproduce an analysis against a known snapshot, compare current and historical results, or inspect data after an accidental delete before deciding whether a rollback is warranted. Use RESTORE when an earlier version must become the table’s new current state; time travel itself is for inspection and validation. 1
Practical example
Suppose a pipeline overwrote sales and the row count looks wrong. First inspect the available history, then query the suspected version without modifying today’s table:
DESCRIBE HISTORY sales;
SELECT * FROM sales VERSION AS OF 5;
SELECT * FROM sales TIMESTAMP AS OF '2024-01-01';
The history output helps select a valid version or timestamp. You can compare that snapshot with the current table and decide whether the issue is a data problem or a reporting expectation. 1
Production caution
Time travel is not an unlimited backup or a long-term archive. It requires both the relevant transaction-log entries and the historical data files. Fabric’s documentation describes a 30-day default for delta.logRetentionDuration and a seven-day default for VACUUM file retention; VACUUM permanently removes eligible unreferenced files, which can make older versions unqueryable even when their history entry remains. Set retention and maintenance schedules against audit, recovery, and reproducibility requirements before reducing cleanup windows. 1 5
Module 6 connection
In Module 6, connect Delta Lake’s versioned storage model to the Lakehouse’s shared data surface and Spark SQL practice. A historical query makes the distinction concrete: engineers can investigate a prior state while leaving the current table unchanged. Pair the exercise with DESCRIBE HISTORY, then discuss how retention policy determines how long that investigation remains possible.
Ready to apply these patterns in a governed delivery? Explore the Momentum One Academy Fabric Production Workshop.
References
Plan your workshop