Summary of New Features and Changes in Snowflake Released in July 2026 #SnowflakeDB
This page has been translated by machine translation. View original
This is a summary article of new features and changes released in Snowflake in July 2026.
※Note: This article does not cover all information, but only picks the items I felt were noteworthy. It is basically based on the information below, so if you want to check all of the latest information, please refer to the URLs below.
July 30, 2026: Adaptive refresh mode for dynamic tables is generally available
The Adaptive refresh mode for dynamic tables (REFRESH_MODE = ADAPTIVE), which had been in public preview since May 2026, is now generally available.
How it works
It normally operates with incremental refresh, but when an internal heuristic determines that the volume of upstream changes is large and incremental refresh would be significantly more expensive than a full refresh, it automatically reinitializes the dynamic table. After reinitialization, it returns to normal incremental refresh.
For workloads where base tables usually receive small changes but occasionally undergo bulk loads (such as INSERT OVERWRITE), the refresh strategy can be switched automatically without manual intervention. The official documentation recommends ADAPTIVE as the preferred refresh mode for incremental workloads.
For details, please refer to the following.
July 29, 2026: Data Quality Monitoring Dashboard is in public preview
The Data Quality Monitoring Dashboard, which lets you check the data quality status of the entire account in one place on Snowsight, is now available as a public preview.
Main features
- Summary display of the percentage of healthy tables and monitoring coverage
- List of open data quality incidents, including volume anomalies, freshness anomalies, and data quality Expectation failures
- AI-assisted root cause investigation using Cortex Code
- Schema-level metrics review and management of the scope for automatic freshness and volume anomaly detection
Note that Enterprise Edition or higher is required to use this feature.
For details, please refer to the following.
July 27, 2026: AI_EXTRACT / AI_PARSE_DOCUMENT now support encrypted stages and network-restricted accounts
The supported scope of AI_EXTRACT and AI_PARSE_DOCUMENT has been expanded (preview).
- Documents on stages that use client-side encryption can now be processed (server-side encryption was already supported)
- Both functions can now be used even in accounts that restrict public access to stages via PrivateLink or network policies
This update lowers the barrier to adopting document AI in environments with strict security requirements.
For details, please refer to the following.
July 27, 2026: Custom incremental dynamic tables are generally available
The CUSTOM_INCREMENTAL refresh mode, which had been in public preview since May 2026, is now generally available. Users can write the logic for applying data changes to a dynamic table (MERGE or INSERT), and Snowflake executes it at each refresh.
For transformation patterns that cannot be made incremental with the standard refresh modes, you can precisely control how changes are applied while retaining the declarative management and scheduling infrastructure of dynamic tables.
For details, please refer to the following.
July 27, 2026: agent_type column added to the QUERY_HISTORY view
An agent_type column has been added to the QUERY_HISTORY views in Account Usage / Organization Usage and to the QUERY_HISTORY table function in Information Schema. It identifies the type of agent that directly invoked (originated) the query, making it easier to audit and analyze the cost of queries issued via AI agents.
agent_type values
| Value | Meaning |
|---|---|
CORTEX_AGENT |
Query by a persistent named Cortex Agent |
CORTEX_LITE_AGENT |
Query by a stateless agent via the REST API / CoCo client |
EXTERNAL_AGENT |
Query by a third-party agent using the SERVICE_AGENT user type or a custom OAuth integration |
| NULL | Non-agent query |
It will be rolled out gradually to all accounts over about one week starting July 27, 2026.
For details, please refer to the following.
Quick verification results (environment: AWS_AP_NORTHEAST_1)
First, I confirmed that AGENT_TYPE (TEXT type) has been added to QUERY_HISTORY in Account Usage.
SELECT column_name, data_type
FROM SNOWFLAKE.INFORMATION_SCHEMA.COLUMNS
WHERE table_schema = 'ACCOUNT_USAGE'
AND table_name = 'QUERY_HISTORY'
AND column_name ILIKE '%AGENT%';
| COLUMN_NAME | DATA_TYPE |
|---|---|
| AGENT_TYPE | TEXT |
When I aggregated the last 7 days in Account Usage, queries were separated by type as follows. Queries executed from CoCo (Cortex Code) are recorded as CORTEX_LITE_AGENT, as described in the documentation.
The following two points struck me as practically important from this verification.
- It can also be referenced via Information Schema table functions.
agent_typeis also returned by functions such asQUERY_HISTORY_BY_USER(), so you can check it right after running a query without waiting for the Account Usage latency (up to 45 minutes). This is handy for checking behavior and debugging during development. - Combined with
role_name, you can write an audit query as is. By filtering withagent_type IS NOT NULL, you can list which users ran agent-originated queries with which roles and warehouses. It can be used immediately as a base query for cost allocation and access auditing of agent-originated queries.
SELECT start_time, user_name, role_name, agent_type,
warehouse_name, execution_status, LEFT(query_text, 120) AS query_text_head
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE agent_type IS NOT NULL
AND start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
ORDER BY start_time DESC;
Note that no CORTEX_AGENT / EXTERNAL_AGENT queries occurred in the account I tested, so those values are unverified.
July 24, 2026: Skill / Plugin sharing for CoCo is in public preview
A feature that lets you share, search, and install Cortex Code (CoCo) skills and plugins within the same Snowflake account is now available as a public preview.
Main features
- Publish skills / plugins as Cortex Extension objects and reference them with
snow://URIs - Access control (RBAC) and catalog discoverability can be controlled independently
- Supports certification by ACCOUNTADMIN, access control, and viewing usage telemetry for the last 28 days
This mechanism lets skills built by individuals circulate as team assets, and even express organizational endorsement (Certified badge).
For details, please refer to the following.
July 23, 2026: dbt Projects on Snowflake supports environment variables and private Git packages
dbt Projects on Snowflake now supports environment variable management via the env.yml configuration file and fetching packages from private Git repositories.
Main features
- Define multiple named environments in
env.yml. Supports plain text values, values computed by SQL, and Snowflake-managed secrets - Because
env.ymlis resolved in the session's execution context before dbt starts, per-developer configuration separation usingCURRENT_USER()orCURRENT_ROLE()is possible - Supports environment selection via
DEFAULT_ENVIRONMENT/ENVIRONMENTand runtime overrides viaENV_VARS - Supports
dbt depsauthentication to private Git repositories using Snowflake secrets, network rules, and external access integrations
It is available in Workspaces, deployed dbt project objects, and CoCo Desktop. If you use Snowflake CLI flags, CLI 3.21 or later is required.
For details, please refer to the following.
July 23, 2026: SERVICE_AGENT user type is generally available
A new user type, SERVICE_AGENT, which lets automated AI agents interact with Snowflake under their own identity, is now generally available.
Main features
- In sessions of this user type,
IS_AGENT_ACTIVATEDautomatically returns TRUE, so it can be combined with policy controls such as "strengthen masking only when an agent is used" - Supports Workload Identity Federation, including SPIFFE/SPIRE
- Can be created and managed with SQL or the SCIM API
This update lets you treat the "agent" as a principal distinct from human users and service users, as a first-class citizen of identity management. Combined with the agent_type column (QUERY_HISTORY) released the same day, you can design identification and auditing of agent-originated access consistently.
For details, please refer to the following.
July 23, 2026: SHOW CORTEX BASE MODELS is generally available
The SHOW CORTEX BASE MODELS command, which lists the Cortex base models available in your account via SQL, is now generally available.
You can check each model's lifecycle status, availability by region, and deprecation and end-of-support dates, which is useful for checks before adopting or migrating models. The output is filtered based on model RBAC grants, so it is also notable that you can determine "which models can actually be used with the current role."
For details, please refer to the following.
Quick verification results (environment: AWS_AP_NORTHEAST_1)
Just running SHOW CORTEX BASE MODELS; returned 95 rows, and I could check name / model_type / lifecycle_status / available_regions / legacy_date / eol_date. Aggregated by lifecycle status, the breakdown was as follows.
| lifecycle_status | model_cnt |
|---|---|
| GA | 44 |
| (NULL) | 28 |
| EOL | 14 |
| PUPR | 4 |
| PRPR | 4 |
| INTERNAL | 1 |
July 22, 2026: External OAuth and OAuth scope settings for MCP servers are generally available
The feature that lets you integrate Snowflake's MCP server with your organization's existing IdP is now generally available.
Added parameters
| Parameter | Description |
|---|---|
OAUTH_AUTHORIZATION_SERVER |
Specifies the External OAuth security integration to use as the authorization server |
OAUTH_SCOPES_SUPPORTED |
Specifies the OAuth scopes to expose at the Protected Resource Metadata endpoint |
This allows MCP clients such as Claude, Cursor, and ChatGPT to authenticate with the corporate IdP instead of Snowflake OAuth. Note that if the specified security integration is dropped or disabled, Protected Resource Metadata returns an empty authorization_servers, and there is no automatic fallback to Snowflake OAuth.
For details, please refer to the following.
July 22, 2026: Multiple dynamic tables can now be refreshed with a single ALTER DYNAMIC TABLE ... REFRESH
A single ALTER DYNAMIC TABLE ... REFRESH statement can now refresh multiple dynamic tables specified as a comma-separated list in one go.
Main features
- Merges the upstream dependencies of all specified tables and updates them consistently with a single data timestamp
- Refreshes of upstream tables shared by multiple tables are executed exactly once
When manually refreshing from an external orchestrator with SCHEDULER = DISABLE, ensuring data consistency between tables was a challenge, but this update makes it easier to update multiple tables in a consistent state.
For details, please refer to the following.
July 21, 2026: Tag-based data protection policies are in public preview
The ability to assign four types of data protection policies—aggregation policies, row access policies, projection policies, and join policies—to tags is now available as a public preview.
Because policies are automatically applied to objects with the tag, you can roll out attribute-based (ABAC) data protection at scale without manually managing policy assignment to individual tables and columns. Tag-based application was already possible for masking policies, and now the scope has expanded to these four types of policies.
For details, please refer to the following.
July 20, 2026: OIDC federated authentication is in public preview
The ability to configure federated SSO using an OpenID Connect (OIDC)-compliant IdP with CREATE SECURITY INTEGRATION is now available as a public preview.
Main features
- In addition to custom OIDC-compliant IdPs, Google / Microsoft can be configured as managed providers
- Supports restricting login methods via authentication policies
- It is also possible to enforce MFA on the Snowflake side after external authentication
Note that identifier-first login is required for multiple OIDC integrations, or for using OIDC together with SAML2 (if disabled, only one of SAML2 or OIDC can be enabled). When using Microsoft, Entra ID user consent and configuration to issue the email claim in the registered app are required.
For details, please refer to the following.
July 20, 2026: DML on Frozen Regions of dynamic tables is generally available
The ability to directly modify rows in the frozen region (Frozen Region) of a dynamic table using INSERT / UPDATE / MERGE / DELETE DML statements is now generally available.
Dynamic tables normally maintain query results declaratively, so direct DML is not possible, but now DML modifications are possible only for the frozen region defined by FROZEN WHERE (finalized data excluded from refresh). Use cases such as row deletion for GDPR compliance or individual corrections to historical data can be performed without triggering recomputation of the active region.
For details, please refer to the following.
July 20, 2026: Maintaining incremental refresh for dynamic tables with pass-through policies is generally available
The cases in which a dynamic table can maintain incremental refresh even when masking policies or row access policies are set on the base table have been expanded.
Previously, only policies using allowlisted functions such as CURRENT_ROLE() or IS_ROLE_IN_SESSION() were compatible with incremental refresh, but now even for any policy, incremental refresh can be maintained as long as the policy is pass-through for the refresh role (the refresh role can access all rows and columns without restriction).
When building dynamic table pipelines on top of source tables with governance policies applied, it becomes easier to avoid the cost increase caused by falling back to full refresh.
For details, please refer to the following.
July 16, 2026: Support for VOLATILE scalar UDFs in incremental refresh of dynamic tables is generally available
VOLATILE scalar UDFs created in Python / Java / Scala / JavaScript / SQL are now supported in incremental refresh of dynamic tables (INCREMENTAL, AUTO, and ADAPTIVE modes).
Previously, queries containing VOLATILE UDFs were not eligible for incremental refresh, but with this update it is easier to operate dynamic table pipelines that leverage existing UDF assets with incremental processing. Note that in incremental refresh, VOLATILE UDFs are allowed only in the SELECT clause.
For details, please refer to the following.
July 15, 2026: Named key pair management for users is now available
Public keys for key pair authentication can now be managed in SQL as "named key pairs."
Main features
- Registration, modification, rotation, and deletion are possible with
ALTER USER ... ADD KEY PAIR/MODIFY KEY PAIR/ROTATE KEY PAIR/REMOVE KEY PAIR - A list can be viewed with
SHOW USER KEY PAIRS - Each key pair has a unique name, and role restrictions and expiration dates can be set
This is an improved version of the previous management via the RSA_PUBLIC_KEY / RSA_PUBLIC_KEY_2 user properties (up to 2 keys), and the legacy method continues to be supported. The practical benefit is that key rotation operations are now first-class SQL commands.
For details, please refer to the following.
July 14, 2026: CREATE OR ALTER is generally available for 24 object types
CREATE OR ALTER, which creates an object if it does not exist and alters it to match the statement's definition if it does, is now generally available for 24 object types, including tables, views, and schemas.
Because it is idempotent—safe to run the same script any number of times—it is especially useful for declarative deployment workflows that manage object definitions in Git and apply them repeatedly, and for CI/CD pipelines.
For details, please refer to the following.
Quick verification results (environment: AWS_AP_NORTHEAST_1)
First I created a table and loaded data, then re-ran the same CREATE OR ALTER TABLE with only the definition changed.
-- v1: the first run behaves as CREATE
CREATE OR ALTER TABLE COA_DEMO (
ID NUMBER(10,0) NOT NULL,
NAME VARCHAR(50),
CREATED_AT TIMESTAMP_NTZ DEFAULT CURRENT_TIMESTAMP()
) COMMENT = 'v1: 初回作成';
INSERT INTO COA_DEMO (ID, NAME) VALUES (1, 'Alice'), (2, 'Bob');
-- v2: the second run behaves as ALTER (widen NAME / add columns / drop CREATED_AT / add CLUSTER BY)
CREATE OR ALTER TABLE COA_DEMO (
ID NUMBER(10,0) NOT NULL,
NAME VARCHAR(100),
EMAIL VARCHAR(200) COMMENT '追加した列',
IS_ACTIVE BOOLEAN DEFAULT TRUE
) CLUSTER BY (ID)
COMMENT = 'v2: NAME拡張 / EMAIL・IS_ACTIVE追加 / CREATED_AT削除';
The data after running v2 is as follows; the existing 2 rows were retained and only the column definitions were applied as a diff.
| ID | NAME | IS_ACTIVE | |
|---|---|---|---|
| 1 | Alice | NULL | TRUE |
| 2 | Bob | NULL | TRUE |
In SHOW TABLES as well, cluster_by = LINEAR(ID) and comment were updated to the v2 content, and created_on remained as of the initial creation (= the table was not recreated).
The following four points struck me as practically important from this verification.
-
Columns not written in the definition are dropped. Because I did not write
CREATED_ATin v2, that column was dropped.CREATE OR ALTERis a statement that declares the "desired final state," so it cannot be used to write only a partial diff. If you want to keep an existing column, you must always include it in the definition. -
A column added with
DEFAULTis also reflected in existing rows. When I addedIS_ACTIVE BOOLEAN DEFAULT TRUE,TRUEwas also populated in the existing 2 rows. -
Incompatible type changes fail, and a warning that "partial updates may have been applied" appears. When I changed
IDfromNUMBER(10,0)toVARCHAR(10)and ran it, I got the following error.CREATE OR ALTER execution failed. Partial updates may have been applied. ... Error message: SQL compilation error: cannot change column ID from type NUMBER(10,0) to VARCHAR(10)
As the error message says, CREATE OR ALTER TABLE does not guarantee full atomicity, and some changes may have been applied upon failure. In production, I recommend not applying changes that include incompatible type changes or column drops directly, but instead checking the impact in a test environment beforehand and preparing a procedure to recover via re-execution or an explicit ALTER TABLE in case of failure.
July 13, 2026: Cloning of Dynamic Iceberg tables is generally available
Cloning of Dynamic Iceberg tables is now generally available.
Main features
- Can be cloned as a new Dynamic Iceberg table or as a Snowflake-managed Iceberg table (static snapshot)
- When cloning a database or schema, Dynamic Iceberg tables, which were previously skipped implicitly, are now included in the clone
If you use database cloning for environment replication or backup purposes, the objects included in the clone result will change, so be sure to check the impact on your operating procedures.
For details, please refer to the following.
July 13, 2026: Backup Instance Types for Snowpark Container Services are in public preview
A feature that automatically falls back to a backup instance family when the primary instance family of a compute pool cannot be secured due to insufficient capacity is now available as a public preview.
Main features
- Define a prioritized list of backup candidates with the
BACKUP_INSTANCE_FAMILIESparameter - Instead of returning an insufficient capacity error (ICE), candidates are tried in order for provisioning
SHOW NODES IN COMPUTE POOLlets you check which instance family each node was actually launched with
Note that each node is billed at the rate of the instance type actually provisioned.
For details, please refer to the following.
July 10, 2026: Online Feature Store is in public preview
Low-latency online feature serving built on Snowflake Postgres is now available as a public preview. It can provide the latest features to real-time ML applications such as fraud detection, recommendations, and personalization.
Main features
- Supports batch / stream / real-time Feature Views
- Event ingestion via REST API and integration with real-time model inference
- Centralization of features for both training and serving through Feature Groups
- Declarative workflow via the
snow featureCLI - Monitoring in Snowsight (offline refresh, stream ingestion, and online serving metrics)
For details, please refer to the following.
July 9–15, 2026: Per-user quotas are in preview
In weekly release 10.24, Per-user quotas, which let you enforce per-user credit limits, are now available as a preview.
Main features
- Create a
SNOWFLAKE.CORE.QUOTAobject and scope target users by tag - Per-user limits (credits) can be set monthly (UTC calendar month) and daily. Monthly and daily limits are evaluated independently, and both can be set
- Target domains are WAREHOUSE / AI FUNCTION / SNOWFLAKE INTELLIGENCE / CORTEX AGENT / CORTEX CODE
- For AI domains, new requests from the relevant user can be automatically blocked when the limit is reached (blocking is not supported for the WAREHOUSE domain)
- Supports threshold notifications and custom actions that execute arbitrary stored procedures
Whereas the traditional Budget provided monitoring and notifications at the account or object level, the big difference is that this goes as far as "stopping a specific user's runaway costs."
For details, please refer to the following.
July 9–15, 2026: Semantic View Materializations are in public preview
In weekly release 10.24, materializations for semantic views are now available as a public preview.
By precomputing selected dimensions and metrics of a semantic view, queries read from the materialized results instead of scanning base tables at query time, improving performance. You can add multiple materializations with different subsets of dimensions and metrics.
Note that materializations take effect for queries that go through the semantic view as Semantic SQL, such as with the SEMANTIC_VIEW syntax. If Cortex Analyst, Cortex Agents, or the like query tables directly with physical SQL without going through the semantic view, they do not benefit from materializations.
For details, please refer to the following.
July 3, 2026: Resource Budgets for Cortex Search are now available
The ability to control the credit consumption of Cortex Search services with resource budgets is now available. You can set a monthly spending limit and, when the limit is exceeded, execute automatic actions such as revoking access or suspending the service.
Cortex Search continuously consumes credits for index maintenance and serving, so this is also effective for preventing unexpected costs from services left running in test environments.
For details, please refer to the following.
July 2, 2026: Metadata-based sensitive data classification recommendations are in public preview
A recommendation feature that identifies databases likely to contain sensitive data based on metadata is now available as a public preview.
A recommendation banner is displayed on the database details page in Snowsight, from which you can enable classification directly. Classification results can be reviewed in "Data Security" in Trust Center. This feature helps with the initial decision of which database to start classification with.
For details, please refer to the following.
July 1, 2026: Workload Identity Federation for accessing external services from Snowflake workloads is generally available
Outbound Workload Identity Federation, in which Snowflake acts as an OIDC provider when authenticating to external services, is now generally available.
Usage flow
- Create a secret of type
WORKLOAD_IDENTITY_FEDERATION - Share the issuer URL and subject identifier with the external service to establish a trust relationship
- Obtain a short-lived ID token with the
SYSTEM$ISSUE_WORKLOAD_IDENTITY_FEDERATION_TOKENfunction and use it to authenticate to the external service
There is no longer a need to hold long-lived credentials such as API keys on the Snowflake side for integrating with external services. Together with WIF for "from external to Snowflake," bidirectional secretless integration is now in place.
For details, please refer to the following.
Behavior Change Log
Preview of the 2026_06 bundle is published ※Disabled by default
The Preview of the 2026_06 bundle was published on July 22, 2026. According to the official documentation, it will be introduced as disabled by default in release 10.26 (scheduled for July 24–28, 2026), then enabled by default in the August 2026 release, and later move to Generally Enabled in a subsequent release (18 items in total).
The changes with major impact include the following.
- INTERVAL literals now recognize plural unit qualifiers (may affect how existing SQL is interpreted)
- Global enablement of Cortex Cross-Region Inference within the same cloud and same region scope
- Migration of dbt Projects on Snowflake to a single mutable live version
- Access role becomes mandatory for using packages from the Anaconda shared repository
- QAS (Query Acceleration Service) is enabled by default on warehouses with a scale factor of 8
2026_05 bundle ※Disabled by default
This bundle was already introduced as disabled by default in release 10.21 in June 2026 (4 items in total). If you want to check the behavior in advance, you can manually enable the bundle and test.
In particular, the change that "Snowflake-managed Apache Iceberg tables are replicated by default in replication / failover groups" has a large impact on storage costs and DR configurations, so I recommend testing beforehand.
2026_04 bundle is enabled by default
In 10.21 (June 12–18, 2026), the 2026_04 bundle was enabled by default.
The move to Generally Enabled (enabled for all accounts) is planned for a subsequent release after June 2026 (the schedule is subject to change).
Deprecation of CORTEX_MODELS_ALLOWLIST and enforcement of embedding model RBAC ※Pending
This change unifies Cortex model access control under model RBAC. The account parameter CORTEX_MODELS_ALLOWLIST is deprecated, and model RBAC will also apply to embedding models (AI_EMBED, Cortex Search), which were previously exempt from RBAC enforcement.
Before the change: When calling Cortex, model RBAC was checked first, and if the role did not have access to the relevant model object in SNOWFLAKE.MODELS, it fell back to CORTEX_MODELS_ALLOWLIST, a two-tier approach. RBAC was not enforced for embedding models.
After the change: Model access is determined only by model RBAC. CORTEX_MODELS_ALLOWLIST is no longer referenced in authorization decisions, and the only value that can be set is 'None'.
A phased rollout is planned.
| Timing | Details |
|---|---|
| August 5, 2026 | CORTEX_MODELS_ALLOWLIST can no longer be changed to a new value (only a change to 'None' is allowed). For accounts set to 'All' (the default for new accounts), the CORTEX-MODEL-ROLE-ALL application role is automatically granted through SNOWFLAKE.PUBLIC |
| August 17 – September 4, 2026 | A one-time migration that maps allowlist settings to model RBAC application roles is performed for existing accounts (including embedding models) |
| Around September 8, 2026 | Removal of allowlist-based access control and enforcement of model RBAC for embedding models is scheduled to become available through the 2026_07 bundle. It is scheduled to start as the bundle's default opt-out period |
| Around October 13, 2026 | The 2026_07 bundle is scheduled to move to default opt-in |
| November 18, 2026 | Rollout is scheduled to complete. CORTEX_MODELS_ALLOWLIST will be fully deprecated |
※The dates above are subject to change. Please check the official Behavior Change Log for the latest schedule.
Latest information on the Modern Data Stack in general
Latest information on the Modern Data Stack in general, including Snowflake, is also regularly summarized and posted on the blog! Please be sure to check these out as well.