Snowflake Bundle 2026_06: What Changes, and How to Test It Before It Flips

Last updated: August 2026

Behavior change bundles are the mechanism by which Snowflake alters SQL semantics, warehouse behaviour and package access on accounts that are already running. They are the only part of the release process that can change what an existing query returns, and the window in which you can opt out is measured in weeks.

Bundle 2026_06 arrived in the 10.26 release, dated 24 to 31 July 2026, as Disabled by Default. Snowflake's documentation says it is planned to become Enabled by Default in an August 2026 release, and Generally Enabled after that. Once a bundle is generally enabled you cannot turn it off, so the testing window is now.

This is a test plan rather than a summary. For each high-impact change there is something specific to run against a clone or a non-production account, so that the flip is a scheduled event rather than a Monday morning surprise.

How the bundle lifecycle actually works

A bundle moves through three states, and your options narrow at each one.

The useful consequence is that Disabled by Default is the only phase where testing costs you nothing. Once the bundle is enabled by default, disabling it puts your account on a path that diverges from everyone else's, and the divergence ends anyway at the generally enabled date.

-- Status of a specific bundle on this account.
SELECT SYSTEM$BEHAVIOR_CHANGE_BUNDLE_STATUS('2026_06');

-- Enable it for testing. Run this on a clone or a
-- non-production account, never first on production.
SELECT SYSTEM$ENABLE_BEHAVIOR_CHANGE_BUNDLE('2026_06');

-- And to put it back.
SELECT SYSTEM$DISABLE_BEHAVIOR_CHANGE_BUNDLE('2026_06');

Two related bundles matter for context. Bundle 2026_05 moved to Enabled by Default in the same 10.26 release, and bundle 2026_04 reached Generally Enabled there, meaning its opt-out is already gone. If you have been disabling bundles to defer work, 10.26 is where some of that deferral expired.

High impact: the INTERVAL literal plural qualifier

Snowflake rates this one high impact, and it is the change most likely to alter a result quietly rather than raise an error. The plural form of an interval qualifier is now recognised as the interval unit.

Interval literals are common in incremental models, retention filters and rolling window definitions, which are exactly the places where a silently different boundary produces a wrong number rather than a failed job. The test is cheap, so run it across your actual literals rather than reasoning about which ones are affected.

-- Step 1: locate the literals. QUERY_HISTORY is a better source
-- than your repository, because it catches BI tools and ad hoc jobs.
SELECT DISTINCT
    query_text,
    user_name,
    COUNT(*) OVER (PARTITION BY query_hash) AS times_run
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -90, CURRENT_TIMESTAMP())
  AND query_text ILIKE '%INTERVAL%'
  AND execution_status = 'SUCCESS'
ORDER BY times_run DESC
LIMIT 200;

-- Step 2: on a clone with the bundle enabled, assert that each
-- literal still resolves to the boundary you expect. Run the same
-- block with the bundle disabled and compare the output.
SELECT
    '90 day'    AS literal, DATEADD(day, -90, '2026-08-26'::date) AS expected,
    '2026-08-26'::date - INTERVAL '90 day'  AS actual
UNION ALL
SELECT
    '90 days',  DATEADD(day, -90, '2026-08-26'::date),
    '2026-08-26'::date - INTERVAL '90 days'
UNION ALL
SELECT
    '3 month',  DATEADD(month, -3, '2026-08-26'::date),
    '2026-08-26'::date - INTERVAL '3 month'
UNION ALL
SELECT
    '3 months', DATEADD(month, -3, '2026-08-26'::date),
    '2026-08-26'::date - INTERVAL '3 months';

Run that block twice, once with the bundle disabled and once enabled, and diff the two result sets. Any row where actual moves between the two runs is a literal you need to make explicit before the flip.

High impact: the Anaconda shared repository now needs an access role

Package usage from the Anaconda shared repository now requires an access role. Anything that resolves Python packages at UDF or stored procedure creation time is in scope, which in most accounts means a long tail of Snowpark objects created by people who have since moved teams.

The failure mode here is a creation-time or execution-time error rather than a wrong answer, so it is louder than the interval change. It is also broader, because the objects affected are spread across schemas and owners.

-- Every Python UDF and procedure, with the packages it declares.
-- Start here, then confirm the role grants cover each owner.
SELECT
    function_schema,
    function_name,
    function_owner,
    function_language,
    packages
FROM snowflake.account_usage.functions
WHERE deleted IS NULL
  AND function_language = 'PYTHON'
  AND packages IS NOT NULL
ORDER BY function_schema, function_name;

SELECT
    procedure_schema,
    procedure_name,
    procedure_owner,
    procedure_language
FROM snowflake.account_usage.procedures
WHERE deleted IS NULL
  AND procedure_language = 'PYTHON'
ORDER BY procedure_schema, procedure_name;

Once you have the list, the test is to enable the bundle on a clone and execute one object per distinct owner rather than one object in total. Grants are per role, so a single passing test proves only that one role is configured.

High impact: cross-region inference enabled globally, and dbt Projects

Two more changes carry a high impact rating, and both are narrower in who they affect but sharper in consequence.

• Cross-region inference enabled globally, same cloud and same region. This changes where an inference request may be served from. If you have a data residency commitment written into a client contract or a regulatory obligation about processing location, this is a change to review with whoever owns that commitment, not only with the data team.
• dbt Projects on Snowflake move to a single mutable live version. Anything built on the assumption that multiple live versions coexist needs revisiting. If your deployment process relied on having a previous version addressable while the new one was validated, that assumption no longer holds.

The residency one deserves particular attention because it is the only change in the bundle whose consequence is contractual rather than technical. A query that runs correctly can still breach a commitment about where processing happens.

Medium impact: the ones that quietly change cost and output shape

The medium-impact set is where cost surprises live. Two are worth singling out.

• Query Acceleration Service enabled by default on warehouses of scale factor 8 and above. QAS credits are billed. A warehouse that was not using acceleration and now is will show a different cost profile without anyone changing a setting.
• SYS_CONTEXT returns typed values rather than generic ones. Anything that compared the result as a string, or relied on implicit casting, can behave differently. This is a small change with a wide blast radius, because SYS_CONTEXT tends to appear inside access policies.

The rest of the medium set covers SHOW GRANTS output consistency, DROP CASCADE onto virtual columns, changes to serverless alert reporting, Streamlit defaulting to the container runtime, external stage clones inheriting directory-table settings, direct shares becoming resharable within a consumer organisation, transient tables no longer being supported by Backups, and a reduced initial wait on storage lifecycle policies. Read the bundle page for the full list before you test, because the membership of a bundle can change while it is still disabled by default.

-- Capture the baseline with the bundle disabled, then repeat
-- with it enabled and compare credits for the same workload.
SELECT
    warehouse_name,
    DATE_TRUNC('day', start_time)         AS day,
    SUM(credits_used_compute)             AS compute_credits,
    SUM(credits_used_cloud_services)      AS cloud_services_credits
FROM snowflake.account_usage.warehouse_metering_history
WHERE start_time >= DATEADD(day, -14, CURRENT_TIMESTAMP())
GROUP BY 1, 2
ORDER BY warehouse_name, day;

-- Acceleration specifically, so the delta is attributable.
SELECT
    warehouse_name,
    SUM(credits_used) AS qas_credits,
    COUNT(*)          AS accelerated_queries
FROM snowflake.account_usage.query_acceleration_history
WHERE start_time >= DATEADD(day, -14, CURRENT_TIMESTAMP())
GROUP BY warehouse_name
ORDER BY qas_credits DESC;

What bundle 2026_05 already changed

Bundle 2026_05 was introduced in the 10.21 release, dated 12 to 18 June 2026, and moved to Enabled by Default in 10.26. Two members are worth checking even if you have not been tracking bundles, because they are already on unless you actively disabled them.

• Managed Apache Iceberg tables are replicated by default in replication and failover groups. This has a storage cost consequence in the target region, and a governance consequence if your replication target sits in a different jurisdiction from the source.
• Adding a NOT NULL column to an Iceberg v3 table requires a non-null default. Migration scripts written against the previous behaviour will fail at the point of the alter.

The replication change is the one to check first. Replicating Iceberg tables you did not intend to replicate produces a bill in a region you were not watching.

A test plan you can run in an afternoon

The sequence below assumes you have a clone or a non-production account you can enable the bundle on. If you have neither, creating one is the first task, because testing this on production is not a reasonable risk to take with a bundle that changes SQL semantics.

• Confirm current state with SYSTEM$BEHAVIOR_CHANGE_BUNDLE_STATUS('2026_06') on both production and the test account, so you know your starting point on each.
• On the test account only, capture the baseline: the interval literal assertions, the Python object inventory, and fourteen days of warehouse credits.
• Enable the bundle on the test account with SYSTEM$ENABLE_BEHAVIOR_CHANGE_BUNDLE('2026_06').
• Re-run the interval assertions and diff. Any moved boundary becomes a code change with an owner.
• Execute one Python UDF or procedure per distinct owner, not one in total.
• Run your heaviest recurring workload and compare credits, paying attention to warehouses at scale factor 8 and above.
• Check any access policy that references SYS_CONTEXT, since typed return values can change a comparison.
• Review the cross-region inference change with whoever owns your data residency commitments.
• Write down what you found and what you changed. The next bundle arrives in roughly a month, and the list of what you tested is what makes that one cheaper.

If the tests come back clean, do nothing and let the flip happen on Snowflake's schedule. That is the outcome you want, and it is worth an afternoon to know it in advance rather than to discover it from a reconciliation.