TL;DR
→ Time Travel is not a backup — it’s a versioned metadata pointer to immutable micro-partitions you already paid to store
→ Snowflake never overwrites data in place. Every UPDATE or DELETE creates new micro-partitions and marks old ones as expired
→ Standard edition gives you 1 day. Enterprise gives up to 90 days — but storage costs multiply fast on high-churn tables
→ After Time Travel expires, data moves to Fail-safe for 7 more days — but only Snowflake support can retrieve it
→ Zero-copy clones use the same micro-partition pointers — no extra storage until you diverge from the source
→ High-churn tables on 90-day retention can silently balloon your Snowflake bill by 10x
The misconception that costs people money
Most engineers who discover Time Travel think: “Great, we have backups.” That’s the wrong mental model — and it’s the one that leads to both security gaps and surprise storage bills. Time Travel is not a backup. It’s a metadata feature built on top of something Snowflake was already doing.
Understanding why requires understanding how Snowflake actually stores data under the hood.
How Snowflake stores data: micro-partitions
Snowflake doesn’t store your tables as traditional database files. It stores them as micro-partitions — small, immutable, columnar files in cloud object storage (S3, Azure Blob, GCS), typically 50–500MB compressed each.
The word immutable is the key. Snowflake never modifies a micro-partition once it’s written. Every micro-partition is a read-only snapshot of the data at the moment it was created. So what happens when you UPDATE a row? Snowflake writes a new micro-partition with the updated data and marks the old one as expired.
The old data doesn’t go anywhere immediately — it just gets a metadata flag saying ‘this version is no longer current.’ This is Copy-on-Write, and it’s the architectural foundation that makes Time Travel possible essentially for free.
Time Travel isn’t a feature Snowflake built on top of backups. It’s a feature Snowflake built on top of an immutable storage model they were already using. The retained partitions are a side effect of how writes work — Time Travel just decides how long to keep them.
What Time Travel actually is
Time Travel is Snowflake’s metadata layer keeping pointers to those expired micro-partitions, instead of immediately flagging them for deletion. When you query with AT(TIMESTAMP => ...) or BEFORE, you’re not restoring from a backup. You’re asking Snowflake’s metadata layer to temporarily re-point to the expired partitions. The data was always there — you’re just re-routing the query to read older versions.
This is why Time Travel queries are fast. There’s no restore process. No data movement. Snowflake reads directly from the older partitions.
The three-zone model: Active, Time Travel, Fail-safe
Understanding the full picture requires knowing all three zones data passes through after it’s written and then changed.
Active data is what your current queries see — the live micro-partitions. Time Travel holds expired micro-partitions for your configured retention window. You can query this with SQL, clone from it, and UNDROP tables dropped within the window. Fail-safe activates when Time Travel expires — Snowflake keeps those partitions for 7 more days, but only Snowflake support can retrieve them. After that, data is permanently gone.
Time Travel vs Fail-safe — the comparison you need
| Feature | Time Travel | Fail-safe |
|---|---|---|
| Duration | 0–90 days (edition dependent) | 7 days (fixed, non-configurable) |
| Who can access | You — via SQL queries | Snowflake support only |
| Query directly | Yes — AT / BEFORE syntax | No — support ticket required |
| Clone from | Yes — zero-copy clones | No |
| Storage cost | Yes — counts against your bill | No additional charge |
| Configurable | Yes — per table/schema/database | No — always 7 days |
| Best for | Operational recovery, auditing | Last-resort disaster recovery |
The storage cost nobody warns you about
Every expired micro-partition kept for Time Travel counts against your Snowflake storage bill. The formula is brutal: a table with 90-day retention that sees 100% of its rows updated daily is storing 91 versions of itself simultaneously.
Most teams set 90-day retention on everything because the docs say Enterprise supports up to 90 days and more seems better. Then they get their first monthly storage invoice and start asking questions.
⚠️ The fix for high-churn tables: Set DATA_RETENTION_TIME_IN_DAYS = 0 on transient staging tables, session event tables, or any table where Time Travel has no operational value. You lose time travel on those tables, but you stop paying for micro-partitions you’ll never query.
Zero-copy clones: same architecture, surprising implications
Zero-copy clones work through the same micro-partition pointer mechanism. When you CREATE TABLE clone CLONE source, Snowflake doesn’t copy any data. It creates a new table object whose metadata points to the same micro-partitions as the source. Storage only diverges when you write new data to either the source or the clone.
This is why ‘create a clone before a dangerous operation’ is nearly free — until you start modifying the clone. It’s also why clones on Time Travel windows are powerful: you can clone a table as it existed 7 days ago with zero storage cost at creation time.
Why Time Travel is not a backup
Account-level events affect everything. If your Snowflake account is compromised at the account level, or you accidentally drop the entire database, Time Travel data is in the same account. It’s not in a separate system.
Cloud storage failure. Time Travel data lives in the same cloud storage as your active data. A regional disaster that takes out your Snowflake data takes out Time Travel with it.
It expires. A backup you can restore from in 6 months is a backup. Time Travel data that’s gone after 90 days is a version history, not a backup. For genuine disaster recovery, you need cross-region replication or dedicated exports.
Practical SQL patterns
Here are the patterns I use most in production — from basic time travel queries to monitoring which tables are inflating your storage bill:
-- Query a table as it existed yesterday
SELECT * FROM orders
AT(TIMESTAMP => DATEADD(DAY, -1, CURRENT_TIMESTAMP()));
-- Query using a specific offset in seconds
SELECT * FROM orders
AT(OFFSET => -3600); -- 1 hour ago
-- Restore a dropped table
UNDROP TABLE orders;
-- Clone a table from 7 days ago (zero-copy, no extra storage)
CREATE TABLE orders_snapshot
CLONE orders
AT(TIMESTAMP => DATEADD(DAY, -7, CURRENT_TIMESTAMP()));
-- Check Time Travel storage usage by table
SELECT table_name,
active_bytes / 1e9 AS active_gb,
time_travel_bytes / 1e9 AS time_travel_gb,
failsafe_bytes / 1e9 AS failsafe_gb
FROM information_schema.table_storage_metrics
WHERE time_travel_bytes > 0
ORDER BY time_travel_bytes DESC;
-- Set retention to 0 for high-churn tables you don't need to travel
ALTER TABLE session_events
SET DATA_RETENTION_TIME_IN_DAYS = 0;Frequently Asked Questions
Q: How does Snowflake Time Travel actually work?
A: Time Travel works by retaining expired micro-partitions rather than deleting them. When you run UPDATE or DELETE, Snowflake writes new micro-partitions and marks old ones as expired but keeps them for your retention window. When you query with AT or BEFORE, Snowflake re-points to those expired partitions at the metadata level. No data is copied or moved — it’s a metadata operation.
Q: Is Snowflake Time Travel the same as a backup?
A: No. Time Travel is not a backup. It’s access to older versions of data in the same system. If your Snowflake account is deleted, compromised at account level, or if cloud storage fails, Time Travel disappears with it. For true disaster recovery you need cross-region replication or separate exports.
Q: How long does Snowflake Time Travel last?
A: Standard edition: maximum 1 day. Enterprise and higher: up to 90 days, configurable per table, schema, or database. Transient and temporary tables max out at 1 day regardless of edition.
Q: What happens after Time Travel expires?
A: Expired micro-partitions move to Fail-safe — a non-configurable 7-day window managed by Snowflake. You cannot query Fail-safe data yourself. Only Snowflake support can recover it, and recovery is not guaranteed. After Fail-safe expires, data is permanently deleted.
Q: Does Time Travel affect storage costs?
A: Yes, significantly. Every expired micro-partition counts toward your storage bill. High-churn tables on 90-day retention can cost 10x more storage than the active data alone. Set DATA_RETENTION_TIME_IN_DAYS = 0 on staging tables or high-churn tables where Time Travel has no operational value.
Q: What’s the difference between Time Travel and Fail-safe?
A: Time Travel is user-controlled — you query it with SQL, configure its duration, and clone from it. Fail-safe is Snowflake-controlled — only support can access it, it’s always exactly 7 days, and it exists for Snowflake’s disaster recovery, not yours.