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 12-hour early access for Enterprise Edition and Business Critical Edition accounts, or 24-hour early access for Virtual Private Snowflake (VPS) accounts to enable additional release testing (if desired).
Release Types (Weekly)¶
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
Behavior changes (see next section in this topic)
In addition, a full release includes updated Snowflake release notes documentation per weekly cycle. See Snowflake weekly, Snowsight, and feature release notes.
Full releases may be deployed on any day of the week, except we typically do not plan full releases on Friday to mitigate against issues that may be encountered during off-hours.
- Patch release:
A patch release includes fixes only. Note that the scheduled/planned patch release for a given week may be canceled if the full release for the week is sufficiently delayed or prolonged.
Additionally, patch releases are deployed (as needed) during or after the completion of the full release to address any issues that are encountered.
Behavior Changes (Monthly)¶
Each month (except for November and December), Snowflake selects one of the weekly full releases for the month to introduce behavior changes. The weekly release selected for the behavior changes may vary, but is typically the 3rd or 4th release for the month.
A behavior change is defined as any change to existing behavior that returns different results from before and may impact customer code or workloads. Behavior changes are provided in bundles that utilize the following naming convention:
YYYY_NN
Where YYYY
is the year and NN
is the ordinal number of the release within the year. For example, 2022_06
would be the 6th behavior
change bundle introduced in 2022.
For more details, see Behavior change management.
Bundle Lifecycle¶
The behavior change bundle lifecycle consists of the following two periods:
- Testing period (1st month):
The bundle is introduced “Disabled by Default”. During this period, you can choose to enable the bundle in one or more accounts. Typically, you would choose accounts designated for development or QA (quality assurance) so that you can test the changes without impacting your production accounts.
- Opt-out period (2nd month):
The bundle moves from “Disabled by Default” to “Enabled by Default”. During this period, you can choose to disable the bundle in your accounts. This allows you to postpone the changes in the bundle, typically for production accounts, while making any necessary adjustments to mitigate the impact of the changes.
During these two periods, Snowflake does not override the setting for a given bundle. For example, if you disable a bundle 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 the bundle across all accounts, at which time the bundle is considered “Generally Enabled”. From this time onwards, you cannot enable or disable the bundle. However, you can still request to temporarily disable individual behavior changes in the bundle by contacting Snowflake Support.
Behavior Change Documentation¶
A release that contains behavior change bundles includes the following documentation (in addition to the Release Notes for the release):
A listing of upcoming and recently implemented bundled changes. See Behavior change log.
A description of each behavior change. Behavior changes are listed on the landing page for each bundle.
A listing of upcoming and recently implemented unbundled changes. See Unbundled Behavior Changes.
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 multiple days. Accounts are moved to the full release in the following order, based on their Snowflake Edition:
- Day 1:
Stage 1 (early access) for 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.
Typically, the minimum amount of time between the early access and final stages is 12 to 24 hours depending on your Snowflake Edition, but it may be shorter or longer. 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 the 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 completed 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 as early access to take advantage of the 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 your Snowflake account representative.
Once you have designated an account for early access, you can implement a testing framework similar to the following:
Use CURRENT_VERSION (or a UDF that returns similar results) to verify when your early access account is on the full release.
Use your early access accounts to test your production workloads against the full release.
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.