Summary

  • Snowflake charges for historical storage through Time Travel and the following seven-day Fail-safe period for permanent tables. A successful DROP leaves a recovery lifecycle to finish.
  • Shorter retention, transient tables and clone cleanup change different parts of that lifecycle. The decisive spending measure is retained billable bytes, including those attached to dropped tables.

A permanent table can leave the database catalogue while its storage keeps a reservation. Snowflake accepts the deletion; the recovery machinery still has work to do, and the retained data stays on the meter.

Snowflake's storage guide identifies several sources of storage charges. Active table data is one; history in Time Travel and Fail-safe adds others. Data retained because clones still reference it also counts. Snowflake compresses table data and uses the compressed size in its storage calculation.

The bargain is useful. An accidental deletion can be reversed during Time Travel. A further recovery service stands behind that window for permanent tables. Buying those extra chances also buys more time in storage. Finance and engineering need the same definition of “finished” when a cleanup project promises savings.

Seven days after the self-service window

Fail-safe lasts seven days, cannot be configured and begins after Time Travel retention ends. Snowflake performs recovery through support on a best-effort basis after other recovery options have been tried. The process may take hours or days. The customer has stopped being able to query the history while the provider may still be able to recover it.

That is a commercially important handover. The history continues to consume storage after its ordinary usefulness to an analyst has ended. Recovery through Fail-safe also uses billable serverless compute; retaining the data and asking the provider to retrieve it are separate activities.

The historical-storage schedule sets out the basic choice:

Table type Time Travel Fail-safe afterwards
Permanent, Standard Edition Zero or one day Seven days
Permanent, Enterprise Edition and higher Zero through 90 days Seven days
Transient Zero or one day None
Temporary Zero or one day, ending at drop or session end None

For a permanent table, choosing zero Time Travel removes the ordinary historical-query window. The seven-day Fail-safe stage remains. A long-running Time Travel query can delay movement into Fail-safe until it completes, and background processing handles the transitions. The retention schedule sets the sequence; the bytes still have to move through it.

A smaller setting can move the bill rather than end it

Snowflake's Time Travel documentation gives a particularly clear example. Reduce a table's retention from ten days to one. History aged two through ten days moves into Fail-safe, while the most recent day remains available through Time Travel. The older history has changed recovery category and continues along the storage lifecycle.

Timing the setting change matters too. Suppose a table inherited 90 days from its schema and was then dropped. Lowering the schema's retention to one day afterwards leaves the dropped table's 90-day period intact. Snowflake documents restoring that object before changing its own retention. A new schema policy governs the active estate; the old deletion carries its earlier terms.

The effective policy may also include an account-level minimum. Engineering's review of a zero setting needs the inherited and minimum rules beside it. Otherwise a savings forecast can use a period the object does not actually have.

This makes table design a purchasing decision made before the cleanup ticket. The choice determines which recovery rights survive a future deletion, and for how long storage remains part of that choice.

Zero-copy has descendants

Cloning adds another reason for old bytes to stay. Snowflake's storage considerations describe clones initially sharing existing micro-partitions. Changes later create new partitions with their own ownership and protection. A useful development snapshot can keep references to data whose original table has gone.

The effect can outlive both ordinary history stages. In the TABLE_STORAGE_METRICS reference, retained-for-clone storage includes deleted bytes still referenced by clones. The same counter also includes data retained by WORM backups. A cleanup confined to the original table name can leave those dependencies in place.

The view retains a dropped table's row at least while its storage is billed. The row may remain after the charges end, with all four main byte counters at zero. Those counters distinguish active data, Time Travel, Fail-safe and storage retained for clones or relevant backups. They establish the remaining storage balance; row visibility alone does not.

Recreating a table with the same name can leave several versions, each with its own storage history. Matching the table identities to their counters shows which version still owns billable bytes. Account Usage metrics can lag by up to 90 minutes, so the comparison also needs time for the view to update. Pricing a particular account's tail requires its compressed retained bytes, effective policy and applicable storage rate.

A cheaper table buys a shorter rescue route

Transient tables remove Fail-safe and allow at most one day of Time Travel. Their active storage remains chargeable while the table exists. The one-day limit concerns the additional historical protection; a transient table left alive for weeks still occupies storage for weeks.

That can suit reproducible working data. The economic cost of rebuilding it becomes the other side of the saving. Once its Time Travel history expires, Snowflake cannot recover a transient table through Fail-safe. For a dataset expensive to reconstruct, paying for protection can be the less costly operating choice.

Temporary tables introduce a session boundary instead. Their history ends at drop or session end, and disconnecting does not itself terminate the session. Closing a client window can consequently leave the customer's assumed cleanup unfinished.

Snowflake gives customers several real ways to choose this bargain. Each operates on a different part of storage's life. A deletion project earns its saving when the payable bytes leave—not when the command receives a polite acknowledgment.