How do you perform time travel queries in Iceberg?

Time travel queries use engine-specific SQL syntax to anchor a query to a past snapshot, either by its unique numeric ID or by specifying a timestamp, which Iceberg resolves to whichever snapshot was current as of that moment.

-- By snapshot ID
SELECT * FROM db.events VERSION AS OF 89347598;

-- By timestamp
SELECT * FROM db.events TIMESTAMP AS OF '2026-01-15 10:00:00';

Under the hood, resolving a timestamp-based time travel query means finding the most recent snapshot whose commit timestamp is at or before the specified time, then proceeding with normal query planning anchored to that snapshot's manifest list rather than the table's current one — the rest of the query execution pipeline (manifest pruning, file pruning, scanning) works identically to a normal query, just against an older, fixed point in the table's history.

Because time travel relies on the target snapshot (and its referenced data files) still existing, it only works as far back as the table's snapshot retention allows; if a snapshot has already been expired as part of routine metadata cleanup, time travel to that specific point is no longer possible, which is why tables that genuinely need long-range time travel capability need their snapshot expiration policy configured with that requirement in mind.