Understanding Snowflake Behavior Change Releases

Welcome to 2024, year of Snowflake release version 8.x and the first Behavior Change Release (BCR) bundle of the year, 2024_01. As you may have noticed, behavior change bundle 2024_01 was released last week in Snowflake version 8.2 with nineteen changes. (By the way, the numbering of the BCR bundle is the Nᵗʰ bundle of the year and does not correspond to a month.)

Progress is impossible without change. To provide the best experience and value to our customers, Snowflake is continually improving and enhancing our service offerings. As part of these ongoing efforts, Snowflake must sometimes make changes to products or features that may affect existing functionality. The Snowflake behavior change release process lets users test a bundled set of feature changes that may affect existing functionality of their workloads.

How are Snowflake behavior change features identified?

The various Engineering and Product teams at Snowflake sync regularly to discuss and procure feedback on functionality being developed. During these meetings, we always consider how each feature — be it a bug fix, enhancement, or deprecation — will affect our customers’ usage of our product. If there is a possibility that the feature under development can affect the continuity of existing customer workloads, the feature owner references a set of strict guidelines to determine if it qualifies for our rigorous behavior change release process.

Not every feature is considered a behavior change as it would be unwieldy for our customers to manage given the hundreds of net new enhancements, behind-the-scenes performance improvements, and minor bug fixes that go out with each Product release.

Some examples of behavior change qualification guidelines:

• Changes to status codes, select error message texts, or object names
• Allowing previously disallowed or unsupported functionality
• Disallowing previously allowed or inconsistent functionality
• Removal/renaming of existing columns or introduction of new columns
• Introduction of new functions that conflict with UDF or UDTFs
• Changes to access control privileges

Please note that these are only a sample of recent guidelines introduced or revised in the behavior change qualification process and are subject to change over time.

As a PM on the BCR committee, I have introduced and approved dozens of behavior changes and understand the time and effort involved in understanding them. We listen to our customers and adjust our guidelines based on your feedback to ensure that our behavior change releases are not too noisy while balancing correctness and continuity of usage.

What happens to features that qualify as behavior changes?

Features that qualify (as well as some features that potentially qualify) as behavior changes are individually reviewed by a BCR committee comprised of representatives from our Engineering, Product Management, and Support Engineering teams. Each feature is scrutinized to understand behavior before and after implementation, usage metrics are reviewed and analyzed to understand scope, and ideas are exchanged to minimize any potential impact on our customers.

A qualified feature must be unanimously approved by the committee before it can be included as part of a behavior change bundle in a future release under the protection of an internal parameter feature flag. Documentation and support playbooks are created for internal and external guidance of these changes. Qualified features that are rejected must incorporate the feedback provided before reconsideration for committee review.

What are the different types of changes that are included in Snowflake Platform releases?

The majority of features are included in Snowflake Platform releases and are documented in the What’s New section of our Snowflake documentation. These are typically features that transition to general availability, internal performance improvements, or minor bug fixes.

Behavior change releases come in two different flavors:

1. Bundled behavior changes
2. Unbundled behavior changes

Bundled behavior changes are controllable by an account admin to disable or enable. All detailed changes inside a BCR are controlled by the bundle. You cannot specify individual behaviors inside the bundle. A behavior change bundle allows for sufficient time to test and validate the impact to workloads before they are fully released. Advance notice of the change is given and communications are sent to customer contacts and their Snowflake account teams.

Unbundled behavior changes cannot be controlled by an account administrator to disable or enable. These type of changes are typically rare and usually involve changes to behavior that have no current customer impact or are urgent changes due to a infrastructure dependency or security fixes. Some advance notice may be given before they are released into a release version but is not guaranteed as these are included in the normal release process.

How to get notified about behavior change bundles?

The best way to get notified is to ensure your Snowflake contacts are correctly populated. We recommend putting a distribution list for your team to receive behavior notifications and ideally all other notifications too. This ensures notifications are sent to the correct place as often times the individual teams using the Snowflake account are different than the organization administrator who created the account.

If you received a email regarding a behavior change then this change applies to your account. It is recommended to read these behavior change emails and understand how it may or may not impact your workloads. For additional help, Snowflake support may have additional telemetry to share on how you may be affected or why you received the notice.

Once you understand the change, it is important to be proactive and plan your timeline for delaying or adopting the new behavior.

How much time is there for this behavior change?

For the most part, Snowflake has a regular weekly release cadence except for long holidays and scheduled major events. Each month (except for December), Snowflake selects one of the weekly full releases to introduce the behavior change bundle. There are at least 4 weeks (4 versions) between each BCR release.

Once a new change bundle is introduced, account administrators can enable or disable the bundle for their accounts for at least eight weeks before the behavior change release bundle is generally enabled for all accounts and no longer controllable. There are 3 transition phases for each behavior change but only during the first 2 periods are when you can opt-in/opt-out of the behavior change for your account.

1. Testing Period — default disabled but you can enable/disable the bundle
2. Opt-out Period — default enabled but you can enable/disable the bundle
3. Generally Enabled — released as permanently enabled and no longer controllable

As seen above, there will always be two introduced behavior change bundles at any given point in time. Currently the 2023_08 and 2024_01 behavior change bundles are available for control.
The 2024_01 bundle was recently introduced, so it is in the initial Testing Period, which mean it is default disabled for everyone.
The previous 2023_08 bundle transitioned to it Opt-out period, which means it is default enabled for everyone.

However the default state transition only applies if you DO NOT act and only rely on the system defaults. Once you opt-out or opt-in during any period, your explicit enabled/disabled state will remain and will not transition during the Testing Period to Opt-out Period.

We recommend being proactive and choosing a explicit state to be in. You can enable or disable the behavior change bundle at any time when it is actively available. This way you do not rely on the system defaults and control your own timeline of when the behavior change bundle should be enabled or disabled for your account. This ensure you have the full minimum 8 weeks to test and validate the changes in the bundle before it becomes generally enabled and fully released.

Using the above examples, the 2023_08 change bundle will transition, around February 19, 2024, to the Generally Enabled state and will be no longer controllable by the account administrator. At the same time, the 2024_02 change bundle will be newly introduced to the Testing Period as default disabled and the 2024_01 change bundle will transition to the Opt-out period as default enabled. Unless you had already explicitly disabled the 2024_01 bundle, at which point you will be disabled until it is Generally Enabled coinciding with the introduction of the 2024_03 change bundle in late March and 2024_01 is released as permanently enabled.

Once a bundle is Generally Enabled, it is not possible to delay the entire bundle of changes any further. However if there is a reason why the minimum 8 week period is not sufficient to adopt one specific change in the change bundle before it is generally enabled, you may be able to request for joint solution with Snowflake. Support and the Product team will work with you to understand the issue further and provide potential solutions for a mutually acceptable timeline. Behavior change timelines are time-boxed such that the capabilities on your account do not deviate too far away from the default Snowflake environment. Just note that these “extension” review requests should only be used for the most concerning changes and should not be used as a general tool. If you have questions or need to request a BCR review due to timeline concerns, you can open a case with our support team.

How to control the behavior change bundles?

To see what behavior changes are currently available, you can refer to our behavior change log documentation page. You can also run the following command on Snowflake to get the two available bundle names and their states.

// show available behavior change bundles that can be controlled
select system$show_active_behavior_change_bundles();

-- [{"name":"2023_08","isDefault":true,"isEnabled":true},{"name":"2024_01","isDefault":false,"isEnabled":false}]

Administrators can use the output of this function to proactively plan and schedule when to enable or disable specific bundles in an account using the BCR-management system functions. I recommend you should take action as soon as possible to control your own timelines for the behavior change on your account.

As a reminder, this bundle control is for all the changes within a BCR and not for individual selection. The preferred approach to handling BCRs is to disable the behavior change bundle on your production accounts as soon as it is available in the Testing Period. On your accounts designated for canary development or QA (quality assurance), you enable the behavior change bundle to test the changes without impacting your production accounts. You can even automate this to always opt-in to new behavior changes as soon as they are available by following this article’s example. Once you have validated the changes on your canary account, you can then choose when to enable the production account.

// Enable a behavior change bundle explicitly and override the default
select SYSTEM$ENABLE_BEHAVIOR_CHANGE_BUNDLE('2024_01');

// Disable a behavior change bundle explicitly and override the default
select SYSTEM$DISABLE_BEHAVIOR_CHANGE_BUNDLE('2024_01');

After the minimum 8 week period since introduction, the behavior change bundle will be generally enabled and no longer controllable by the above SYSTEM$DISABLE or SYSTEM$ENABLE commands. It is now released as the new standard Snowflake behavior for everyone. So eventually you will get the behavior, it’s best to test it early.

TL;DR just give me recommendations on BCRs

1. Ensure your account has a distribution list signed up for Behavior Change Notifications
2. Read the behavior change notifications emails and documented details
3. Always ENABLE or DISABLE a behavior change early and ensure adequate preparation for your own timelines
4. Test the behavior change bundle early on a development or QA account that mirrors your production account
5. Reach out to your account team or open a case with Snowflake support if you have questions or to provide feedback around behavior changes