Snowflake’s 2026_06 Feature Change: Transient Tables Will Be Excluded from Backups

Snowflake’s upcoming 2026_06 Behavior Change Bundle includes a feature change that every organization using Snowflake Backups should be aware of: 

Transient tables including transient dynamic tables will no longer be supported by Snowflake Backups. 

I understand Snowflake’s reasoning. Transient tables are intended for transitory or reproducible data that does not require the same recovery protections as permanent tables. However, this change could have serious consequences for organizations that currently include transient tables in long-term or immutable backup strategies. 

The goal of this article is not to criticize the change. It is to make sure Snowflake customers are aware of it, understand the impact, and are prepared before it takes effect. Before the change, transient tables could be backed up individually or included in a schema- or database-level backup. After the change: 

• Creating a backup set directly against a transient table will fail with an error.
•  Existing table-level backup sets targeting transient tables will fail when attempting to add another backup. 
• Most concerning, a schema  or database level backup will still succeed but Snowflake will silently exclude all transient tables. 

Those excluded tables will not be available during a restore because they were never captured. Existing backups that already contain transient tables are unaffected and can still be restored. 

What is a transient table? 

A transient table behaves much like a permanent Snowflake table: it persists across sessions, remains available until explicitly dropped, and can be accessed by other authorized users. 

The key difference is data protection. 

Transient tables: 

• Have a maximum Time Travel retention period of one day. 
• Do not receive Snowflake’s seven-day Fail-safe protection. 
• Typically cost less to maintain because they do not incur Fail-safe storage costs. 
• Are best suited for staging data, intermediate transformations, ETL work tables, caches, and other data that can be independently reproduced. 

That last point is critical: transient tables should generally contain data that can be recreated without relying on Snowflake recovery.   

“Transient” and “must be backed up” are not mutually exclusive. 

It is tempting to assume that if a table was created as transient, its data cannot have a business, legal, or regulatory retention requirement. 

In the real world, that is not always true. 

A table may have originally been made transient to reduce Fail-safe storage costs. Years later, it may contain data needed for an audit, litigation, regulatory recordkeeping, historical analysis, or cyber-recovery. Business requirements change, applications evolve, and tables often live much longer than their original designers expected. The decision to avoid Fail-safe is not necessarily the same as the decision to exclude data from an immutable, long-term backup. 

Organizations should therefore rethink their use of transient tables. If there is any reasonable possibility that the data will need to be backed up, restored, audited, or retained for several years, a permanent table may be the safer design. 

The conversion is not painless 

Unfortunately, there is no simple command such as: 
ALTER TABLE my_table SET PERMANENT 

Snowflake does not allow the transient property to be changed after a table is created. Converting a transient table to a permanent table requires creating a new permanent table, copying the data, preserving grants and metadata, validating dependent objects, and then renaming or replacing the original table. 

At enterprise scale, this can become a significant migration effort. 

There is also a real cost tradeoff. Permanent tables receive a seven-day Fail-safe period, and the historical data maintained during that period incurs additional storage charges. Organizations that adopted transient tables to control storage costs must balance those new Fail-safe costs against their backup and retention requirements. 

Why this feature change deserves immediate attention 

Many large Snowflake environments have backup scopes containing tens of thousands of transient tables. 

Imagine discovering several years from now during an audit, investigation, legal request, or regulatory inquiry that required historical data is unavailable because those tables stopped being included in backups. 

• The backup jobs continued to report success. 
• No database or schema level backup failed. 
• No warning clearly identified the missing tables. 
• The data simply was not captured. 

That would be a catastrophe and it is exactly the type of risk that can arise when a seemingly small feature change is missed. 

Make sure you are ready 

Before the 2026_06 bundle becomes enabled by default: 

1. Inventory all transient and transient dynamic tables within existing backup scopes.
2. Identify tables subject to business, legal, regulatory, audit, or cyber-recovery requirements.
3. Confirm that supposedly reproducible data can actually be regenerated within an acceptable timeframe.
4. Convert tables requiring long-term backups to permanent tables.
5. Estimate the resulting Fail-safe storage costs before migrating at scale.
6. Enable and test the behavior change bundle in a non-production account.
7. Add monitoring that compares expected backup objects with the objects actually captured. 
   

Again, I understand why Snowflake is making this change. Transient tables were designed for data that does not need permanent-table recovery protections. 

Just make sure your organization is aware of the change and ready for it. 
Table type is no longer only a storage-cost decision. It is also part of your backup, recovery, and compliance architecture. 

Snowflake documentation: 2026_06 backup behavior change | Transient tables | Backups and immutable storage 

Talk to CloudHive 

Reviewing your Snowflake backup strategy or assessing how the 2026_06 feature change could affect your environment?

CloudHive works with organisations across Snowflake architecture, data protection and platform governance to help identify risks and prepare for changes before they reach production. 

If you’d like to discuss your backup scopes, transient table strategy or a related topic you would like us to cover in a future article, get in touch.