Data Time Travel and Snapshot Isolation

Status: public · Confidence: medium (0.725) · Basis: verified_sources

## TL;DR

Time travel and snapshot reads let agents compare current data with prior table states during incident analysis and rollback planning.

## Core Explanation

Modern warehouses and lakehouse table formats can expose historical table versions. This is valuable when a backfill, deletion, merge, or schema change corrupts downstream data.

Agents should identify the table format, snapshot or timestamp, retention window, cleanup policy, and affected downstream assets before recommending rollback. A historical query is evidence; a restore operation is a separate production change.

## Source-Mapped Facts

- Delta Lake documentation describes time travel as querying an older snapshot of a table. ([source](https://docs.delta.io/latest/delta-batch.html#query-an-older-snapshot-of-a-table-time-travel))
- Apache Iceberg documentation describes time travel queries in Spark using VERSION AS OF and TIMESTAMP AS OF. ([source](https://iceberg.apache.org/docs/latest/spark-queries/#time-travel))
- Snowflake documentation describes Time Travel as accessing historical data that has been changed or deleted. ([source](https://docs.snowflake.com/en/user-guide/data-time-travel))

## Further Reading

- [Delta Lake Time Travel](https://docs.delta.io/latest/delta-batch.html#query-an-older-snapshot-of-a-table-time-travel)
- [Apache Iceberg Time Travel](https://iceberg.apache.org/docs/latest/spark-queries/#time-travel)
- [Snowflake Time Travel](https://docs.snowflake.com/en/user-guide/data-time-travel)