Snowflake Releases

Snowflake is committed to providing a seamless, always up-to-date experience for our users while also delivering ever-increasing value through rapid development and continual innovation.

To meet this commitment, we deploy new releases each week. This allows us to regularly deliver service improvements in the form of new features, enhancements, and fixes. The deployments happen transparently in the background; users experience no downtime or disruption of service, and are always assured of running on the most-recent release with access to the latest features.

This topic describes the process we follow for weekly releases, including the option to request 24-hour early access for Enterprise Edition (and higher) accounts to enable additional release testing (if desired).

In this Topic:

Release Types

Each week, Snowflake deploys two planned/scheduled releases:

Full release

A full release may include any of the following:

  • New features

  • Feature enhancements or updates

  • Fixes

In addition, a full release includes the following documentation deliverables (as appropriate):

Full releases may be deployed on any day of the week, except Friday.

Patch release

A patch release includes fixes only. Note that the patch release for a given week may be canceled if the full release for the week is sufficiently delayed or prolonged.

If needed, additional patch releases are deployed to address any issues that are encountered during or after the release process.

Behavior change release

Every month, Snowflake deploys one behavior change release. Behavior change releases contain changes to existing behaviors that may impact customers.

Behavior change releases take place over two months: during the first month, or test period, the behavior change release is disabled by default, but you can enable it in your account; during the second month, or opt-out period, the behavior change is enabled by default, but you can disable it in your account.

Snowflake does not override these settings during the release: if you disable a release during the testing period, we do not enable it at the beginning of the opt-out period. At the end of the opt-out period, Snowflake enables the behavior changes in all accounts. However, you can still request an extension to disable specific behavior changes from the release by contacting Snowflake Support.

Pre-release Testing/Validation

At Snowflake, release quality is a top priority. Before each release is deployed, it goes through a full suite of validation tests that include:

  • Regular build testing.

  • Continuous workload and performance testing.

In addition, before any customer accounts are moved to a release, the following validation is performed:

  • Full round of regression testing in internal accounts across all supported cloud platforms.

  • Simulating execution of select impacted customer workloads (e.g. queries on customer data), with a focus on workloads that are most likely impacted by changes in the release.

Staged Release Process

Once a full release has been deployed, Snowflake does not move all accounts to the release at the same time. Accounts are moved to the release using a three-stage approach over two (or more) days. Accounts are moved to the full release in the following order, based on their Snowflake Edition:

Day 1

Stage 1 (early access) for Standard accounts and designated Enterprise (or higher) accounts.

Day 1 or 2

Stage 2 (regular access) for Standard accounts.

Day 2

Stage 3 (final) for Enterprise (or higher) accounts.

The minimum amount of elapsed time between the early access and final stages is 24 hours. This staged approach enables Snowflake to monitor activity as accounts are moved and respond to any issues that may occur. It also enables designating Enterprise accounts for early access testing (see next section in this topic).

Note

This staged approach only applies to full releases. For patch releases, all accounts are moved on the same day.

In addition, if issues are discovered while moving accounts to a full release or patch release, the release may be halted or rolled back. In most cases, the follow-up to a halted/rolled-back release is deployed within 24-48 hours.

Early Access to Full Releases

If you have multiple Enterprise Edition (or higher) accounts, you can designate one or more of these accounts to take advantage of the 24-hour period between the early access and final stages for full releases. This can be particularly useful if you maintain separate accounts for development/testing and production.

To designate an account for early access, please contact Snowflake Support.

Once you have designated one or more accounts for early access, you can implement a testing framework similar to the following:

  1. Use CURRENT_VERSION (or a UDF that returns similar results) to verify when your early access account(s) are on the full release.

  2. Use your early access account(s) to test your production workloads against the full release.

  3. If any issues are encountered, notify Snowflake Support, who can work with you to prevent the issues from disrupting your other accounts.

Tip

Early access is not required or recommended for all organizations with Enterprise Edition accounts; Snowflake’s rigorous release testing and monitoring during deployments is usually sufficient to prevent most issues. Early access is intended primarily for organizations that desire added certainty that their production accounts will not be affected by full releases.