How to Use Time Travel on a Delta Table in Databricks

João Barros 12 de July de 2026 4 min read

Time Travel on a Delta table in Databricks lets you query your data exactly as it was at an earlier version or point in time, with no manual backups. It is the right safety net when a MERGE goes wrong, a pipeline duplicates rows, or someone asks what the numbers looked like last week. With SQL and PySpark you can inspect the history, read an old version and restore the table in a few minutes.

Prerequisites

Access to a Databricks workspace with a running cluster or SQL Warehouse.
A table in Delta format (for example vendas) with at least two writes already made.
Read permissions on the table and, to restore it, write permissions (MODIFY in Unity Catalog).
Basic SQL. PySpark is optional.

Step 1: Confirm the table really is Delta

Time Travel only exists on Delta tables. First, check the format in a notebook or in the SQL editor:

DESCRIBE DETAIL vendas;

The format column should show delta. If it shows parquet or csv, there is no version history and this example does not apply.

Step 2: Look at the table version history

Every write (INSERT, UPDATE, DELETE, MERGE, OPTIMIZE) creates a new version. This command shows that list:

DESCRIBE HISTORY vendas;

The most useful columns are:

version: the version number (0, 1, 2, ...), which you will use for Time Travel.
timestamp: when the version was created.
operation: what happened (WRITE, MERGE, DELETE...).
operationMetrics: how many rows were inserted, updated or deleted.

Write down the number of the last good version, that is, the one just before the mistake.

Step 3: Query an old version with Time Travel

There are two ways to travel in time: by version number or by timestamp.

-- By version
SELECT * FROM vendas VERSION AS OF 12;

-- By date and time
SELECT * FROM vendas TIMESTAMP AS OF '2026-07-11 09:00:00';

The same in PySpark, useful when you want to work with the result as a DataFrame:

df_antigo = (spark.read
    .format("delta")
    .option("versionAsOf", 12)
    .table("vendas"))

df_antigo.count()

A common error here is asking for a TIMESTAMP AS OF that is older than the table's first version. Databricks returns an error saying the version does not exist: in that case, use DESCRIBE HISTORY to pick a valid timestamp.

Step 4: Compare two versions to measure the damage

Before restoring, it pays to know exactly what changed. Start with the row counts:

SELECT
  (SELECT count(*) FROM vendas VERSION AS OF 12) AS antes,
  (SELECT count(*) FROM vendas) AS agora;

Then look at the rows that exist now but did not exist before:

SELECT * FROM vendas
EXCEPT
SELECT * FROM vendas VERSION AS OF 12;

If the result is exactly the set of duplicated or wrong rows, your diagnosis is confirmed.

Step 5: Restore the table to an earlier version

Once you have identified the right version, restoring is a single line:

RESTORE TABLE vendas TO VERSION AS OF 12;

-- Alternative, by timestamp
RESTORE TABLE vendas TO TIMESTAMP AS OF '2026-07-11 09:00:00';

Note that RESTORE does not erase the history: it creates a new version whose content matches version 12. In other words, the restore itself is reversible too. If you would rather not touch the original table, create a copy:

CREATE TABLE vendas_backup
DEEP CLONE vendas VERSION AS OF 12;

Step 6: Know how far back you can travel

Time Travel depends on the old files still being there. VACUUM removes files that are no longer referenced (by default, older than 7 days), and the transaction log has its own retention. To widen the window on a critical table:

ALTER TABLE vendas SET TBLPROPERTIES (
  delta.logRetentionDuration = 'interval 90 days',
  delta.deletedFileRetentionDuration = 'interval 30 days'
);

Longer retention means more files kept and higher storage cost. Only tune it on tables where the history has real value.

Verify the result

After the restore, run the history again:

DESCRIBE HISTORY vendas;

You should see a new row with operation = RESTORE at the top. Then confirm the data is back to what you expected:

SELECT count(*) FROM vendas;

If the count matches version 12 and the query from Step 4 (EXCEPT) no longer returns rows, Time Travel has done its job.

Conclusion

With DESCRIBE HISTORY, VERSION AS OF and RESTORE TABLE you have a simple audit and recovery mechanism for any Delta table. The natural next step is automation: a data quality check at the end of the pipeline that, on detecting an anomaly, stores the previous version number for a fast restore. One final tip: before any risky load, run DESCRIBE HISTORY and note the current version — it is the Delta equivalent of fastening your seatbelt. Do you know what the Time Travel window is on your most critical tables?