Time Travel retention periods in Snowflake - Time & Space Complexity
We want to understand how the cost of keeping past data versions grows as we keep more history in Snowflake's Time Travel.
Specifically, how does the retention period affect the operations needed to store and access data?
Analyze the time complexity of managing Time Travel retention periods in Snowflake.
-- Set retention period for a table
ALTER TABLE my_table SET DATA_RETENTION_TIME_IN_DAYS = 7;
-- Query data as of a past time
SELECT * FROM my_table AT (OFFSET => -3600);
This sequence sets how long past data is kept, queries data from the past.
Look at what happens repeatedly as retention period changes.
- Primary operation: Storing historical data versions for each change.
- How many times: Once per data change, repeated over the retention period.
As the retention period grows, the amount of stored past data grows roughly in proportion.
| Input Size (Retention Days) | Approx. Storage & Access Operations |
|---|---|
| 1 | Stores 1 day's worth of changes |
| 7 | Stores 7 days' worth of changes |
| 30 | Stores 30 days' worth of changes |
Pattern observation: More retention days means more stored versions, so storage and retrieval work grows linearly.
Time Complexity: O(n)
This means the work to store and access past data grows in direct proportion to the retention period length.
[X] Wrong: "Increasing retention period does not affect storage or query cost."
[OK] Correct: Longer retention means more past data versions are kept, so storage and query operations must handle more data.
Understanding how retention settings affect system work shows you can think about cost and performance trade-offs in cloud data systems.
"What if we changed retention from days to hours? How would the time complexity change?"
Practice
Solution
Step 1: Understand Time Travel feature
Time Travel allows you to see and restore past versions of your data.Step 2: Identify what retention period controls
The retention period sets how many days you can access these past versions.Final Answer:
How long you can access previous versions of data -> Option AQuick Check:
Retention period = access duration for past data [OK]
- Confusing retention with storage duration
- Thinking it controls query speed
- Assuming it limits user access
sales_data?Solution
Step 1: Recall correct syntax for setting retention
The correct command uses ALTER TABLE with SET DATA_RETENTION_TIME_IN_DAYS.Step 2: Match syntax with options
ALTER TABLE sales_data SET DATA_RETENTION_TIME_IN_DAYS = 7; matches the exact syntax; others use incorrect keywords or commands.Final Answer:
ALTER TABLE sales_data SET DATA_RETENTION_TIME_IN_DAYS = 7; -> Option BQuick Check:
Use ALTER TABLE ... SET DATA_RETENTION_TIME_IN_DAYS [OK]
- Using UPDATE instead of ALTER TABLE
- Wrong keyword like RETENTION_DAYS
- Missing SET keyword
Solution
Step 1: Understand retention period limit
Retention period limits how far back you can access data versions.Step 2: Apply to 5 days query with 3 days retention
Since 5 days is beyond 3 days retention, data is unavailable and causes an error.Final Answer:
You get an error because data older than 3 days is not available -> Option AQuick Check:
Query beyond retention period = error [OK]
- Assuming data is always available
- Thinking query returns empty instead of error
- Believing retention auto-extends
Solution
Step 1: Know Snowflake retention limits
Snowflake limits Time Travel retention to a maximum (usually 1 to 90 days depending on edition).Step 2: Check if 100 days exceeds limit
100 days is beyond typical max, causing an error.Final Answer:
Retention period exceeds the maximum allowed limit -> Option DQuick Check:
Retention > max limit causes error [OK]
- Assuming syntax error without checking limits
- Thinking table lacks Time Travel support
- Believing service restart fixes retention errors
Solution
Step 1: Understand retention vs storage cost
Longer retention means more storage cost; shorter retention saves cost but limits recovery.Step 2: Evaluate options for 14-day retention and cost balance
Setting retention to 14 days meets recovery needs; purging old data helps control storage.Final Answer:
Set DATA_RETENTION_TIME_IN_DAYS to 14 and regularly purge old data -> Option CQuick Check:
Retention matches need + purge controls cost [OK]
- Setting retention too low losing data
- Setting retention too high increasing cost
- Disabling Time Travel losing recovery benefits
Ready to prove it?
Pass the test and this pattern moves unknown
