Storage lifecycle policies¶

A storage lifecycle policy is a schema-level object that automatically manages the data lifecycle for standard Snowflake tables. Use these policies to archive or expire specific table rows based on conditions that you define, such as data age or other criteria. Snowflake automatically executes these policies daily using shared compute resources.

How storage lifecycle policies work¶

Overview of the storage lifecycle policy workflow

To get started with storage lifecycle policies, use the following steps:

Create a policy with an expression that identifies rows to archive or expire.
Attach the policy to one or more tables.

After you attach a storage lifecycle policy to a table, Snowflake waits approximately 24 hours before running the policy for the first time. Following this initial delay, Snowflake automatically runs the policy daily using shared compute resources to identify and process rows that meet your defined conditions.

When the policy runs, it checks each row against your expression and either archives data to COOL or COLD storage, or expires it (deletes it permanently). You can retrieve archived data by using the CREATE TABLE … FROM ARCHIVE OF command before expiration occurs. Snowflake waits until the specified archive period elapses before expiring the data from archive storage.

Overview of the storage lifecycle policy archive-to-expiration flow.

Key capabilities¶

Storage lifecycle policies provide the following benefits for managing your Snowflake data.

Reduced storage costs: Storage lifecycle policies help optimize costs by automatically moving older data to more cost-effective archival tiers. For data that needs to be retained long-term but accessed infrequently, archival storage can significantly reduce storage costs compared to standard storage tiers.
Regulatory compliance: Automatically meet compliance requirements by configuring policies to archive or expire data according to regulatory standards. You can archive data for a specific time before expiration, or expire it directly without archiving. This ensures that your data management follows your organization’s governance standards.
Simple data management: Storage lifecycle policies eliminate manual data management tasks by automatically executing archival and expiration rules. For more information, see Monitoring storage lifecycle policies.
Flexible data retrieval: Retrieve archived data with precision by creating a new table that contains only the rows you need. Use a simple command with a WHERE clause to specify exactly which archived data to restore.

Archive storage tiers¶

Snowflake supports archiving data in the following storage tiers:

Archive tier	Description
COOL	Offers fast retrieval time, so data is readily available. The minimum archival period is 90 days.
COLD	Offers greater cost savings than the COOL tier (four times less expensive). The minimum archival period is 180 days. Compared to the COOL tier, COLD has a longer data retrieval time (up to 48 hours). Data retrieval operations from the COLD storage tier support a maximum of 1 million files per restore operation.

Choosing an archive tier¶

When selecting an archive tier, consider the following:

Archiving costs: The one-time cost to archive data is the same for both tiers.
Storage costs: COLD tier storage is less expensive than COOL tier storage.
Retrieval costs: COLD tier data retrieval is less expensive than COOL tier retrieval.
Retrieval time: The COOL storage tier offers instant data retrieval, whereas COLD tier retrieval can take up to 48 hours.

For detailed pricing information, see tables 3(e) and 4(f) in the Snowflake Service Consumption Table.

For more information about archiving data, see Create a storage lifecycle policy and archive storage considerations.

Considerations¶

Consider the following when you work with storage lifecycle policies.

Cloud provider support¶

Expiration policies: Supported for accounts hosted on all cloud providers (AWS, Azure, and Google Cloud).
Archival policies: Currently available only for accounts hosted on AWS.

Supported tables and features¶

Supported tables: Storage lifecycle policies are supported for standard Snowflake tables. In order to evaluate and apply storage lifecycle policy expressions, Snowflake internally and temporarily bypasses any governance policies on a table.
Replication:
- Snowflake replicates storage lifecycle policies and their associations with tables to target accounts, but doesn’t run the policies.
- After failover to a target account, Snowflake pauses storage lifecycle policy execution in the original primary account. After failback to the original primary account, Snowflake resumes policy execution.
- Snowflake never automatically runs secondary storage lifecycle policies on secondary tables, even after failover. However, you can use secondary policies in a target account by attaching them to new tables. For those new tables, Snowflake runs the policies.
Cloning: Snowflake doesn’t automatically apply storage lifecycle policies to cloned tables. If you apply a storage lifecycle policy to a table in a clone group, Snowflake archives rows only from that specific table. The policy doesn’t affect clones. This creates copies of the data in both the standard and archive storage tiers, and you pay for storage in each tier. For cost information, see Billing for storage lifecycle policies.
Unsupported features

Storage lifecycle policies aren’t supported for the following:
- All object types other than regular Snowflake tables and dynamic tables.
- Write Once Read Many (WORM) snapshots, which are immutable snapshots that can’t be modified after creation.
- Tables shared through Snowflake data sharing (both provider and consumer tables).
- Native Apps.
- User-defined functions (UDFs) with external access and external functions.
- Python, Java, or Scala UDFs.

Policy behavior and execution¶

Storage lifecycle policies use performance guidelines that are similar to guidelines for row-level access policies, and operate automatically with the following characteristics:

When you attach a storage lifecycle policy to a table, Snowflake waits approximately 24 hours before running it for the first time.
Snowflake runs storage lifecycle policies every day by using shared compute resources. For information about cost for storage lifecycle policies, see Billing for storage lifecycle policies.
To prevent excessively long archive or expiration runs, Snowflake processes large data operations incrementally in smaller chunks A large operation might not complete in one daily run and might instead complete across multiple daily runs.
When a storage lifecycle policy is running on a table, Snowflake locks UPDATE, DELETE, and MERGE operations. You can still perform INSERT and COPY operations during this time. For more information, see Resource locking.

Archival storage policies¶

For working with tables that have an archival storage lifecycle policy attached:

Accessing archived data: After Snowflake archives rows, you can’t query them directly. To access them, use the CREATE TABLE … FROM ARCHIVE OF command to create a new table with a copy of the archived data. For more information, see Retrieving archived data.
Security: You can use Tri-Secret Secure (TSS) to protect archived data with regular key rotation.
Rekeying: Snowflake doesn’t rekey archived data. If you suspect a key compromise, use the following workaround:
1. Retrieve the archived data to a new table with the CREATE TABLE … FROM ARCHIVE OF command.
2. Archive data in the new table when needed. Each table has its own encryption key, so the new table effectively uses a new key.
3. Drop the archive of the original table in which the keys were compromised.
Archive tier limitations:
- You can’t change the archive tier for a policy from COOL to COLD (or the other way around). Create a new policy instead (see Recreate a storage lifecycle policy).
- A table can only use one archive tier. You can’t attach a COLD policy to a table that already uses COOL archiving.
Removing policies: When you remove a policy from a table, the archived data remains in archive storage and can still be retrieved.
Dropping or truncating a table:
- Truncating a table doesn’t affect archived data for that table. You can still retrieve data from archive storage after truncating the table.
- When you use UNDROP TABLE to restore a table in an applicable Time Travel data retention period, Snowflake also restores any data in archive storage.
- When a table is within the Fail-safe period, the data in archive storage might be recoverable by using Fail-safe data recovery steps through Snowflake Support.
- Table data in archive storage that you delete before the ARCHIVE_FOR_DAYS period has elapsed is subject to storage cost. For more information, see Minimum storage duration charges.