Explanation
Why the waste happens and who it affects.
For tables with high churn - meaning frequent INSERT, UPDATE, DELETE, or MERGE operations - this can cause a significant buildup of historical snapshot data, even if the active data size remains small.
This hidden accumulation leads to elevated storage costs, particularly when Time Travel retention periods are long and data change rates are high. Often, teams are unaware of how much snapshot data is being stored behind the scenes.
Billing model
The pricing dimensions that drive this cost.
- Storage is billed monthly at a flat rate per TB of compressed data, which depends on account type (Capacity or On Demand) and region, and includes historical data kept for Time Travel and Fail-safe
- Time Travel and Fail-safe fees are calculated for each 24-hour period from the time data changed; Snowflake stores only the changed data, except that it keeps full copies of tables that are dropped or truncated
- Permanent tables keep Time Travel for their retention period (up to 90 days, which requires Enterprise Edition) plus 7 days of Fail-safe; transient and temporary tables have no Fail-safe and at most 1 day of Time Travel
- High churn multiplies the changed data held in both windows, so historical bytes can exceed the table's active size
How to detect
5 checks to find it in your estate.
- Identify tables with high storage consumption relative to their current active data size.
- Query the TABLE_STORAGE_METRICS view and compare TIME_TRAVEL_BYTES and FAILSAFE_BYTES with ACTIVE_BYTES to detect high-churn tables.
- Review Time Travel retention settings at the table and account level to determine if default settings are unnecessarily long.
- Estimate the ratio of historical snapshot storage versus active storage for key tables.
- Confirm with application and data engineering teams whether frequent table modifications are necessary, or if design changes could reduce churn.
How to fix
4 ways to remove the waste.
- Optimize Time Travel retention settings: Reduce retention periods (e.g., from 90 days to 1 day) for high-churn tables where long recovery windows are not necessary.
- Convert high-churn staging or ETL tables whose data can be recreated from source to transient tables, which have no Fail-safe period and at most 1 day of Time Travel. Permanent tables always keep 7 days of Fail-safe, even with Time Travel set to 0.
- Recreating a heavily churned table does not reset its historical storage right away: Snowflake keeps a full copy of a dropped table through its Time Travel and Fail-safe periods, so recreating only stops further accumulation. Lowering the retention period is usually the more direct lever.
- Regularly monitor table storage metrics to proactively manage and clean up storage waste in evolving datasets.
Documentation
Vendor references for pricing and configuration.
