Time Travel

Time Travel keeps earlier versions of data queryable for a retention window, so a table can be read as it stood before an update, or restored after being dropped. It turns a class of mistakes that used to require a restore from backup into something resolvable in place.

Snowflake’s Understanding & using Time Travel page lists three capabilities: “Query data in the past that has since been updated or deleted,” “Create clones of entire tables, schemas, and databases at or before specific points in the past,” and “Restore tables, schemas, databases, and some other kinds of objects that have been dropped.”

The window is shorter by default than people assume. “The standard retention period is 1 day (24 hours) and is automatically enabled for all Snowflake accounts.” Enterprise Edition and above can set it “to any value from 0 up to 90 days” for permanent objects — but only if someone configures it, and a mistake discovered on Monday about Friday’s load is outside a one-day window.

Retention is not free. Keeping prior versions means keeping the storage they occupy: “extended data retention requires additional storage which will be reflected in your monthly storage charges.” A high-churn table rewritten daily carries a much larger retention overhead than its current size suggests.

It is also not a backup. The window is short, it is bounded by a setting anyone with privileges can lower, and it protects against operational error rather than against account loss. Treat it as an undo for recent mistakes and verify the retention setting before relying on it — the assumption that it is longer than it is tends to surface at the worst moment.

Further reading

• Snowflake, Understanding & using Time Travel

See the worked examples in Snowflake Architecture and Workload Design.