Why Time Travel enables data recovery in Snowflake - Performance Analysis
We want to understand how the cost of recovering data using Time Travel changes as the amount of data grows.
Specifically, how many operations Snowflake performs when retrieving past data versions.
Analyze the time complexity of querying data using Time Travel.
-- Query data as it was 1 hour ago
SELECT * FROM my_table AT (OFFSET => -3600);
-- Restore a dropped table within retention period
UNDROP TABLE my_table;
-- Query data before a delete operation
SELECT * FROM my_table BEFORE (STATEMENT => 'delete_statement_id');
This sequence shows how Snowflake accesses historical data snapshots to recover or query past states.
Identify the API calls, resource provisioning, data transfers that repeat.
- Primary operation: Reading historical data snapshots stored in micro-partitions.
- How many times: Once per micro-partition involved in the query or recovery.
As the amount of data grows, the number of micro-partitions to scan grows roughly in proportion.
| Input Size (n) | Approx. API Calls/Operations |
|---|---|
| 10 micro-partitions | 10 snapshot reads |
| 100 micro-partitions | 100 snapshot reads |
| 1000 micro-partitions | 1000 snapshot reads |
Pattern observation: The operations grow linearly with the number of micro-partitions involved.
Time Complexity: O(n)
This means the time to recover or query past data grows in direct proportion to the amount of data scanned.
[X] Wrong: "Time Travel queries always take the same time regardless of data size."
[OK] Correct: Because Snowflake must read all relevant historical micro-partitions, more data means more reads and longer time.
Understanding how Time Travel scales helps you explain data recovery costs clearly and shows you grasp cloud data storage behavior.
"What if the retention period for Time Travel was doubled? How would that affect the time complexity of data recovery?"