# Excessive Time Travel and Fail-safe storage from high-churn Snowflake tables Canonical: https://www.pointfive.co/efficiency-hub/inefficiencies/excessive-snapshot-storage-from-high-churn-snowflake-tables Snowflake automatically maintains previous versions of data when tables are modified or deleted. By: Simar Arora Updated: 2026-09-28 [Cloud Efficiency Hub](https://www.pointfive.co/efficiency-hub) # Excessive Time Travel and Fail-safe Storage from High-Churn Snowflake Tables The short version Snowflake automatically maintains previous versions of data when tables are modified or deleted. [Simar Arora](https://www.linkedin.com/in/simarpreet-arora/) Value Engineer - FinOps @ Snowflake Snowflake service [Snowflake Snapshots](https://www.pointfive.co/efficiency-hub/cloud-services/snowflake-snapshots) Category [Storage](https://www.pointfive.co/efficiency-hub/service-category/storage) Reference CER-0111 Type Inefficient Architecture ## 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. - [Snowflake Time Travel & Fail-safe docs.snowflake.com](https://docs.snowflake.com/en/user-guide/data-availability) - [Storage costs for Time Travel and Fail-safe docs.snowflake.com](https://docs.snowflake.com/en/user-guide/data-cdp-storage-costs) - [Working with Temporary and Transient Tables docs.snowflake.com](https://docs.snowflake.com/en/user-guide/tables-temp-transient) - [TABLE\_STORAGE\_METRICS view docs.snowflake.com](https://docs.snowflake.com/en/sql-reference/account-usage/table_storage_metrics) ## Related inefficiencies [Browse the library](https://www.pointfive.co/efficiency-hub) - Snowflake Tables CER-0126 ### [Retention of Unused Data in Snowflake Table](https://www.pointfive.co/efficiency-hub/inefficiencies/retention-of-unused-data-in-snowflake-table) Retention of stale data occurs when old, no longer needed records are preserved within active Snowflake tables. Without lifecycle policies or regular purging, tables accumulate outdated data. Retaining large volumes of inactive or... Storage - Snowflake Tables CER-0516 ### [Large Snowflake Tables That Are Loaded but Never Read](https://www.pointfive.co/efficiency-hub/inefficiencies/large-snowflake-tables-that-are-loaded-but-never-read) Some Snowflake tables keep receiving data from COPY jobs, Snowpipe, tasks, dbt models or external ELT tools long after anything stopped reading them. The dashboard, model or export that consumed the table was retired or repointed, but the... Storage - GCP GCS CER-0336 ### [Excessive API Request Cost Overhead from I/O-Intensive Workloads](https://www.pointfive.co/efficiency-hub/inefficiencies/excessive-api-request-costs-from-filesystem-style-access-on-gcs) Google Cloud Storage exposes a flat namespace through an HTTP API, but many workloads consume it through filesystem-style abstractions - FUSE mounts, Hadoop/Spark connectors, or analytic engines that enumerate prefixes to discover state.... Storage --- Source: the public page above. Product screenshots and illustrative interfaces are examples, not live customer data.