How to Time Travel a Delta Table in the Lakehouse

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

Time travel in Delta Lake lets you query a table exactly as it looked in the past — before an update, a deletion, or a load that went wrong. It works because Delta keeps a transaction log of every change and numbers the versions automatically. In a Microsoft Fabric Lakehouse every table is Delta, so this capability is available out of the box, with no configuration. It is perfect for auditing, recovering from mistakes, and reproducing old reports with the right data.

Prerequisites

A Microsoft Fabric workspace with a Lakehouse created.
A Notebook attached to that Lakehouse, where you will run Spark SQL cells.
A Delta table to explore (every Lakehouse table is Delta) or the willingness to create the example table below.
Basic SQL knowledge.

Step 1: Prepare the table and generate versions

Time travel is only useful if the table has history, and every write (INSERT, UPDATE, DELETE, or MERGE) creates a new version. Let's create a small vendas table and change it, so we have versions to explore:

CREATE TABLE vendas (id INT, produto STRING, total INT);
INSERT INTO vendas VALUES (1, 'Teclado', 80), (2, 'Rato', 25);
UPDATE vendas SET total = 120 WHERE id = 1;

The creation is recorded as version 0, the INSERT as version 1, and the UPDATE as version 2. That is enough history to work with.

Step 2: View the version history

The DESCRIBE HISTORY command lists every version of the table, with its number, timestamp, and the operation that created it:

DESCRIBE HISTORY vendas;

Look at the version, timestamp, and operation columns. Each row is one version; the more writes you make, the further back you can travel. This is where you decide which point in time to return to.

Step 3: Query a version with VERSION AS OF

To read the table as it was at a specific version, add VERSION AS OF followed by the version number. Let's look at the state at version 1, before the UPDATE:

SELECT id, produto, total FROM vendas VERSION AS OF 1;

The Teclado total shows as 80 (the original value), even though it is already 120 in the current table. The query reads the past without changing anything in the present.

Step 4: Query by date and time with TIMESTAMP AS OF

You can also travel to a moment in time instead of a version number — handy when you know "how it looked at a certain time" but not the exact number. Copy a timestamp from the timestamp column in Step 2:

SELECT id, produto, total FROM vendas TIMESTAMP AS OF '2026-07-06 04:02:00';

Delta returns the version that was active at that instant. The timestamp must fall within the table's history: it cannot be earlier than when the table was created.

Step 5: Restore a previous version

If you actually want to reset the table to an old state — for example, to undo a wrong change — use RESTORE. This command creates a new version with the old content and keeps the full history:

RESTORE TABLE vendas TO VERSION AS OF 1;

Tip: RESTORE does not delete versions. If you restore by mistake, you can travel back again — the history is still there.

Verify the result

Run DESCRIBE HISTORY vendas again and you will see a new entry whose operation is RESTORE. Then confirm the restored value:

SELECT id, produto, total FROM vendas WHERE id = 1;

The Teclado total should be back to 80, the value from version 1. If that is the number you see, time travel and RESTORE worked as expected.

Conclusion

With DESCRIBE HISTORY, VERSION AS OF, TIMESTAMP AS OF, and RESTORE you have gained a real time machine for your data — ideal for auditing, recovering from mistakes, and reproducing old analyses. Just keep in mind that the history is not infinite: the VACUUM command removes old data files (by default it keeps the last 7 days), which limits how far back you can travel. What is the first table where you wish you had had this safety net?