Data Today: Snowflake

Snowflake DCM Projects GA: declarative IaC inside the warehouse

2026-08-10T00:00:00Z

Snowflake has shipped plenty of features for running code inside its warehouses, but until now it left the deployment of the warehouse objects themselves to third-party tools. That changes with Snowflake DCM Projects, which reached general availability on August 7, 2026. DCM, short for Database Change Management, lets you define databases, tables, tasks, and other Snowflake objects declaratively in SQL files, then let Snowflake figure out the diff and apply the changes. The headline: you can now version-control and idempotently deploy your Snowflake infrastructure without an external state file or a separate Terraform runner.

The move matters because every team running Snowflake at scale already has a deployment problem. Some use Terraform or dbt, some run hand-rolled SQL scripts in GitHub Actions, and most have a tangled mix of both. DCM Projects is Snowflake's native answer: a declarative layer that handles the plan, the diff, and the apply, all inside the account. For teams that already think about pipeline architecture choices, this adds a new dimension to the build question.

What is a DCM Project and how does the syntax work?

A DCM Project is a collection of SQL definition files that describe the desired state of your Snowflake objects. Instead of writing imperative CREATE OR ALTER statements and hoping they run in the right order, you write DEFINE statements that declare what an object should look like. Snowflake compares the declared state to the current state and computes the delta.

The DEFINE keyword is the building block. A database and table definition based on the pattern documented in the Snowflake DCM overview looks like:

DEFINE DATABASE my_analytics
  COMMENT = 'Analytics warehouse objects';

DEFINE TABLE my_analytics.reporting.daily_revenue (
  order_date DATE,
  revenue NUMBER(12,2),
  region VARCHAR
)
COMMENT = 'Daily revenue by region';

The real power comes from Jinja templating, which is built in. You can parameterize definitions for multiple environments:

DEFINE TABLE .reporting.daily_revenue (
  order_date DATE,
  revenue NUMBER(12,2),
  region VARCHAR
)
COMMENT = 'Daily revenue for ';

With Jinja, you pass variables like env=staging at deploy time, so one project definition serves dev, staging, and production without duplicate files. Loops, conditions, and macros are all available, which means you can generate repetitive definitions (one table per region, one task per schema) without copy-paste sprawl.

Project files live in three places: a Snowflake Workspace managed inside Snowsight, a remote Git repository, or a local directory. You can manage them through Snowsight, the Snowflake CLI, SQL, or the Cortex Code CLI. That flexibility is deliberate: whether your team lives in the Snowflake UI or in a terminal, there is an entry point.

How does the plan-then-deploy workflow run?

The core workflow is plan, review, deploy. You define the desired state, Snowflake generates a plan showing what will change, you review it, and then you execute. The command at the center is EXECUTE DCM PROJECT, which is generally available and documented in the Snowflake SQL reference.

A deploy from the Snowflake CLI:

snow dcm execute --project my_analytics \
  --variable env=production

Or via SQL:

EXECUTE DCM PROJECT my_analytics
  USING VARIABLES (env => 'production');

One important nuance: the explicit PREVIEW and TEST commands are still in Preview as of the GA release. The GA plan-then-deploy story relies on EXECUTE DCM PROJECT, which applies changes. If you want a dedicated dry-run verb before applying, that specific SQL command is not yet production-ready. Plan accordingly: test in a lower environment where EXECUTE is safe, and treat staging as your dry run until the PREVIEW command ships as GA.

To monitor what DCM Projects have done in your account, query ACCOUNT_USAGE:

SELECT
  project_name,
  status,
  executed_by,
  executed_at
FROM SNOWFLAKE.ACCOUNT_USAGE.DCM_PROJECT_EXECUTIONS
ORDER BY executed_at DESC
LIMIT 20;

This view is your audit trail. Every execution logs who ran it and when. Wire it into a dashboard or an alert so you catch unintended schema drift the moment it happens. The exact view columns depend on the ACCOUNT_USAGE schema Snowflake publishes, so verify the column names against your account's information schema before building dashboards on top of it.

How does DCM compare to Terraform and raw SQL scripts?

Most teams deploying Snowflake objects today use one of two approaches. Terraform with the Snowflake provider gives you declarative state and a plan output, but it runs outside Snowflake and requires a state file you have to manage. Raw SQL scripts in CI/CD give you full control but no diff, no drift detection, and no idempotency without careful scripting. DCM Projects splits the difference.

Dimension	DCM Projects	Terraform + provider	Raw SQL scripts
Where it runs	Inside Snowflake	External CI runner	Any CI runner
State management	Snowflake computes the diff	Terraform state file	None
Plan or dry run	EXECUTE DCM PROJECT (GA); PREVIEW command (Preview)	terraform plan (GA)	None without custom code
Jinja templating	Built in	HCL variables and for_each	Requires external templating
Object coverage	Broad, but pipes and streams in Preview	Broad via provider	Anything you script
Lock-in	Snowflake-only definitions	Portable HCL, provider-dependent	Fully portable SQL
Drift detection	Snowflake checks current vs desired on execute	terraform plan detects drift	None

The trade-off is clear. DCM Projects removes the need for an external runner and a state file, which simplifies CI/CD and cuts the number of moving parts. But it locks your deployment definitions to Snowflake. If your infrastructure spans AWS, dbt, and Snowflake, Terraform still has a role for the parts outside Snowflake. If Snowflake is your whole world, DCM is the simpler path.

What does it cost and what edition do you need?

Here is the good news for anyone who owns the Snowflake bill: DCM Projects does not introduce a separate credit charge. The feature runs within your existing Snowflake account. The compute used for planning and applying changes runs on a warehouse, so the cost is the warehouse compute you are already paying for. There is no per-execution fee, no marketplace listing, and no premium edition requirement called out in the GA announcement.

Check whether the feature is visible in your account:

SHOW FUNCTIONS LIKE 'EXECUTE%DCM%';

If the command resolves, DCM Projects is available. If not, check with your account admin or Snowflake support, as feature rollout can lag the release-note date by days.

The real cost is the time to migrate. If you have hundreds of Terraform resources or thousands of lines of imperative SQL, converting them to DEFINE statements is a project, not an afternoon. Start with one schema or one pipeline, prove the workflow, and expand from there.

Illustrative: Snowflake DCM Projects capability count at GA on August 7 2026. 7 capabilities generally available (declarative definitions, Jinja templating, plan-then-deploy, broad object support, pipeline management, management interfaces, storage options). 8 capabilities still in Preview (TEST/PREVIEW commands, GitHub Actions, DEFINE PIPE, DEFINE STREAM, DEFINE MASKING POLICY, DEFINE ROW ACCESS POLICY, ATTACH TAG, inherited grants). Source: Snowflake release notes.

The chart above shows the capability split at GA. 7 capabilities are generally available, including the DEFINE statement core, Jinja templating, and the plan-then-deploy workflow. 8 capabilities remain in Preview, and several of them are the governance and pipeline objects you most need for production.

What is still in Preview and what should you avoid?

The GA is real, but it is not complete. These capabilities remain in Preview:

TEST and PREVIEW commands: the dry-run verbs are not GA yet
GitHub Actions for DCM Projects: no native CI integration yet
DEFINE PIPE: cannot declaratively manage Snowpipe objects
DEFINE STREAM: cannot declaratively manage streams
DEFINE MASKING POLICY: cannot declaratively manage masking policies
DEFINE ROW ACCESS POLICY: cannot declaratively manage row access policies
ATTACH TAG: cannot declaratively attach tags to objects
Inherited grants and container-level MANAGE GRANTS: advanced grant patterns not supported

If your governance story depends on masking policies, row access policies, or tag-based protections, DCM Projects cannot manage those objects declaratively today. You will still need imperative SQL or Terraform for that layer. For a deeper look at those governance objects, see our guide on Snowflake RBAC and masking.

Similarly, if your pipeline uses streams, you are out of luck for declarative management. You can declaratively define dynamic tables and tasks, but streams remain imperative. For teams building event-driven pipelines, this is the gap to watch.

What is the pragmatic migration path?

Start with objects that are fully GA: databases, tables, tasks, and dynamic tables. These cover the bulk of what most teams deploy repeatedly. Leave pipes, streams, and governance policies in your existing tooling for now.

A practical sequence:

Pick one non-production schema with a handful of tables and a task
Write DEFINE statements for those objects in a local directory or Git repo
Run EXECUTE DCM PROJECT against a dev database
Verify the objects match, then tear them down and re-execute to confirm idempotency
Wire the Snowflake CLI into your CI pipeline with a shell step
Expand schema by schema, checking the execution history after each run
Move the project storage to a remote Git repository once the workflow is stable

The GRANT that controls who can execute DCM Projects:

GRANT EXECUTE MANAGE DCM PROJECT ON ACCOUNT TO ROLE dcm_deployer;

Restrict this to a dedicated deployment role. DCM Projects can create, alter, and drop objects, so the execute privilege is powerful. Do not grant it broadly, and do not let your CI service role carry it into production without a gate.

A before-and-after for a simple table change shows the value. Before DCM, adding a column meant writing an ALTER TABLE script, versioning it, running it in each environment, and hoping nobody ran it twice. With DCM, you change the DEFINE TABLE block, run EXECUTE DCM PROJECT, and Snowflake applies only the column addition:

-- Before: imperative, order-dependent
ALTER TABLE reporting.daily_revenue ADD COLUMN currency VARCHAR;

-- After: declarative, idempotent
DEFINE TABLE reporting.daily_revenue (
  order_date DATE,
  revenue NUMBER(12,2),
  region VARCHAR,
  currency VARCHAR
)
COMMENT = 'Daily revenue by region';

Run it once, run it a hundred times. The result is the same.

The bottom line for your deployment pipeline

DCM Projects GA is a genuine step forward for Snowflake-native DevOps. It removes the external state file and the separate IaC runner for the objects it covers, and it does so without a new line item on your bill. The gaps are real but bounded: governance objects and streams will come, and until they do, you run a hybrid stack. If you are starting a new Snowflake project today, begin with DCM definitions. If you are running a mature Terraform setup, do not rip it out, but start migrating the object types DCM supports and shrink your Terraform footprint over time.

Sources

Cortex AI Gateway: Snowflake's agent governance layer

2026-08-03T00:00:00Z

Your AI agents are about to have more access to your enterprise data than most of your engineers. Snowflake knows this, and at Black Hat 2026 the company shipped a control plane to do something about it. Cortex AI Gateway is a centralized governance layer that sits between AI agents and the models, data, MCP servers, and tools those agents want to touch. It supports more than 100 MCP servers and governs both Snowflake-native agents like CoCo and CoWork and third-party tools like Claude Code, Cursor, Amazon Bedrock, and custom LangChain apps. The catch: the gateway itself is heading to public preview soon, and most of its marquee features, including cost control, intelligent model routing, and observability, are still in private preview.

The timing is not accidental. AI security concerns surged from 17 percent of organizations in 2024 to 48 percent in 2026, according to The Linux Foundation's 2026 State of Tech Talent Report, as cited by Snowflake. Meanwhile 97 percent of organizations say they are committed to implementing AI, and 57 percent face a significant capacity gap in security and risk management. The gap between adoption and security is where data exfiltration, tool hijacking, and runaway token costs live.

If you own a Snowflake bill or govern data access in a Snowflake environment, this is the feature set that determines whether you let agents into production or keep them in sandboxes. Here is what shipped, what is real, and what you should do about it.

What shipped at Black Hat 2026 and what is still private preview?

Snowflake announced a bundle of features, but they are not all at the same maturity. Sorting them by availability tells you what you can put in a production architecture today versus what is still a roadmap promise.

Generally available now:

Agent Identity: Security and governance teams can enforce data access policies that apply specifically when an agent is in the session, even if the agent runs on behalf of a privileged user. Snowflake added dedicated agent identity tracking in ACCOUNT_USAGE views for auditing.
Native AI Security Posture Management: Integrated into the Trust Center, this gives security operations a dashboard to scan for AI-specific configuration risks, assess compliance against emerging regulations, and deploy programmatic remediations.
Data movement policies: Strict policies that govern where data can move, now GA, pairing with the preview DXP package for enforcement.
Ransomware Protection via Multi-Party Approval: Requires two or more authorizations before any destructive system change can proceed.

In preview or coming soon:

Cortex AI Gateway: Public preview soon. The overall gateway for agent access, cost, and audit.
Data Exfiltration Prevention (DXP): Preview, via the Trust Center.
Restricted Session Scope: GA soon. Limits agent sessions to only what a task requires.

Private preview (request access, no public docs):

Wide Model Catalog, Access Governance and Sprawl Control, Govern Every Agent Connection, Observability and Tracing, Agent Action Auditability, AI Cost Control, Intelligent Model Routing, Context-Aware Access Policies, and CoCo CLI VM Sandbox.

The chart below shows the breakdown: 4 features are GA, 3 are in some preview stage, and 9 are in private preview. If you are planning an architecture around this, most of the value is still behind a door you have to knock on.

Cortex AI Gateway feature availability: 4 GA, 3 preview, 9 private preview. Source: Snowflake blog, Data Today analysis.

How does the gateway govern MCP server access?

MCP, the Model Context Protocol, has become the standard for connecting LLMs to databases, internal tools, and SaaS environments. The problem is that every team that adopts MCP does it differently, with no central visibility. Snowflake's answer is to put a gateway in front of all of it.

Cortex AI Gateway integrates Natoma, the MCP gateway company Snowflake acquired in May 2026, directly into the platform. Natoma enforced identity, policy, and audit at the tool-call level. Now that enforcement lives inside Snowflake's governance framework.

The gateway sits between agents and the things they want to reach. An agent, whether it is CoCo running inside Snowflake or Claude Code running on a developer laptop, makes a request to call a tool or access a model. The gateway checks three things: who requested the action, what permissions they have, and whether the action is allowed. If the answer is yes, the call proceeds and is logged. If no, the call is blocked.

For first-party agents, this is native. For third-party agents, Snowflake announced integrations with 1Password, Aembit, Cyera, Linx Security, Okta, SailPoint, and Saviynt to extend the same identity framework outward. A governance policy you write for a Snowflake-native agent also covers a Claude Code session hitting your data.

The access control model uses Snowflake's standard privilege framework. A simplified grant for gateway-managed tool access:

-- Grant a role access to a gateway-managed MCP integration
-- (exact object type will be documented at public preview)
GRANT USAGE ON INTEGRATION my_mcp_integration
    TO ROLE agent_operator_role;

-- Grant access to Cortex AI functions (standard Snowflake pattern)
GRANT USAGE ON DATABASE SNOWFLAKE TO ROLE agent_operator_role;
GRANT USAGE ON SCHEMA SNOWFLAKE.CORTEX TO ROLE agent_operator_role;

The exact privilege names and object types for the gateway are not yet publicly documented since the feature is in preview. What you should take away is that agent access will be governed by roles and grants you control, not by API keys scattered across developer machines.

What can you actually enforce with agent identity?

Agent Identity is GA, and it is the feature you can use today. The core idea: when an agent is in a session, Snowflake knows it is an agent, not a human user, and can enforce policies accordingly.

This matters because agents often run under privileged roles. A data scientist with SYSADMIN privileges kicks off an agent to analyze a table. Without agent identity, that agent has the full power of the role. With agent identity, you can write policies that restrict access to sensitive columns, block DDL, or limit the session to read-only when an agent is the actor.

Scenario	Without Agent Identity	With Agent Identity (GA)
Agent runs under SYSADMIN	Full admin access to all objects	Policies restrict agent to task scope
Auditing who did what	Query shows the human user	Query shows agent identity and human user
Sensitive column access	Agent sees everything the role allows	Masking policies can trigger on agent context
Destructive actions	Agent can drop tables if role allows	Restricted Session Scope (GA soon) blocks this

You can audit agent activity through ACCOUNT_USAGE views. A query to find agent-driven access to sensitive tables:

-- Identify queries executed in the last 24 hours
-- Agent identity columns are new in GA; filter for agent sessions
SELECT
    query_id,
    query_text,
    user_name,
    role_name,
    start_time,
    execution_status
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE start_time >= DATEADD('day', -1, CURRENT_TIMESTAMP())
  AND query_type IN ('SELECT', 'INSERT', 'UPDATE', 'DELETE')
ORDER BY start_time DESC
LIMIT 100;

With Agent Identity GA, Snowflake has added agent-specific tracking to these views. The exact column names depend on your Snowflake version, but the capability means you can filter for queries where an agent was the actor, not just the human who started the session. This is the audit trail your security team needs when someone asks which agent touched the customer table.

Restricted Session Scope is the companion feature, marked GA soon. It limits what an agent session can do to only what the task requires. A read-only analysis stays read-only, even if the user's role normally allows INSERT or DELETE. This is the principle of least privilege applied to agent sessions, and it is the feature that makes running agents under privileged roles defensible.

How does the cost control layer work?

This is the section that matters if you own the bill. AI Cost Control, in private preview, gives you a unified view of AI consumption by team, agent, or workload. You can set budget guardrails and route requests to cheaper models for simpler tasks.

Intelligent Model Routing, also private preview, automatically routes agent requests to the right model based on cost, latency, capability, and data residency. If a simple summarization task does not need the most expensive model, the gateway can route it to a cheaper one. If a task requires reasoning, it goes to the stronger model. The gateway also enforces data residency: requests stay in the region they need to stay in.

The cost model for the gateway itself is not yet published. Snowflake has not announced specific credit pricing for Cortex AI Gateway in the source material. What is clear is that the feature is designed to control AI consumption costs: the token spend across external model providers like OpenAI, Anthropic, and Google, not the Snowflake compute credits you already track. If your team is spending on external model APIs through Snowflake, the gateway is the layer that puts guardrails around that spend.

For a parallel on how Snowflake thinks about cost control, see our guide on Snowflake Adaptive Compute costs. The same philosophy of applying guardrails before the bill runs away now extends to AI token consumption.

What you would do: if you are in the private preview, set per-agent budget caps immediately. If you are not, start instrumenting your current agent workloads with ACCOUNT_USAGE queries to establish a baseline of what agents are actually costing you today.

What does data exfiltration prevention actually block?

The Data Exfiltration Prevention (DXP) package is in preview via the Trust Center. It pairs real-time telemetry with the now-GA data movement policies to detect and intercept unauthorized data flows before they exit the ecosystem.

The platform can proactively flag and block three specific patterns:

Sensitive data fetches triggered by AI agents: An agent queries a table with PII or financial data, and the system flags or blocks the retrieval based on policy.
Unauthorized data routing to internal or external stages: Data moves to a storage location that is not approved, and the movement is intercepted.
Mass data downloads via user interfaces: A user or agent attempts to export a large volume of data through the UI, and the download is blocked.

The underlying data movement policies are GA, meaning you can author and enforce them now. The DXP package adds the real-time telemetry and detection layer on top. A basic network policy in Snowflake:

-- Create a network policy to restrict allowed IP ranges
CREATE NETWORK POLICY corp_allowed_egress
    ALLOWED_IP_LIST = ('10.0.0.0/8')
    COMMENT = 'Restrict data movement to corporate network';

-- Apply the network policy at the account level
ALTER ACCOUNT SET NETWORK_POLICY = corp_allowed_egress;

This is not a new concept if you already use Snowflake network policies. What is new is the pairing with AI-specific telemetry: the system can distinguish between a human user downloading a CSV and an agent triggering a bulk data fetch, and apply different rules to each.

Should you build on this today or wait?

Here is the honest read. If you are deciding whether to architect around Cortex AI Gateway right now, the answer depends on what you need.

Build on what is GA today:

Agent Identity for auditing and policy enforcement on agent sessions.
AI Security Posture Management in the Trust Center for scanning configuration risks.
Data movement policies for controlling where data goes.
Multi-Party Approval for protecting destructive operations.

Request private preview for:

The gateway itself, if you have MCP sprawl and need centralized access control across more than 100 MCP servers.
AI Cost Control, if your token spend is growing and you need budget guardrails.
Intelligent Model Routing, if you are using multiple model providers and want automatic selection.

Wait on:

Context-Aware Access Policies (private preview) if you already have network policies and row access policies that work. The zero-trust evaluation of identity, network, and client context in a single expression is promising but unproven at scale.
CoCo CLI VM Sandbox (private preview, macOS only) unless you have a specific need for kernel-level isolation of agent development environments.

The lock-in question is real. Cortex AI Gateway is built on Natoma, which Snowflake acquired. If you build your agent governance around this gateway, you are building around Snowflake's control plane. For organizations already deep in Snowflake, that is a reasonable trade. For teams running multi-cloud or multi-platform agent architectures, the gateway covers a wide catalog of MCP servers but the governance model is Snowflake-centric.

If you want to start with something concrete, our guide to building an AI agent on your Snowflake data with Cortex Agents covers the agent side. Pair that with Agent Identity (GA) and data movement policies (GA), and you have a defensible production architecture for agent access today, even without the full gateway.

The trust boundary moved inside Snowflake

The important shift here is architectural. Agent governance used to be an application-layer problem: you built guardrails into your LangChain app, your MCP client, or your agent framework. Snowflake is arguing that security belongs in the data and control planes rather than bolted onto the application. Cortex AI Gateway, Agent Identity, and DXP move the trust boundary inside Snowflake itself.

That argument is sound if your data lives in Snowflake. The features that are GA today, Agent Identity and data movement policies, are enough to start governing agent access in production. The features that are still in private preview, cost control, model routing, and observability, are the ones that will make the gateway worth the architectural commitment. Watch for the public preview transition. That is when you will know whether the gateway delivers on the promise or stays a roadmap item.

Sources

Snowflake Blog - Enterprise AI Security: Agentic Controls and MCP Governance
VentureBeat - Snowflake launches Cortex AI Gateway to control AI agents and prevent runaway enterprise costs
SiliconANGLE - Snowflake debuts Cortex AI Gateway to govern and monitor enterprise AI agents
Yahoo Finance / Business Wire - Snowflake Advances the Trusted Agentic Enterprise Era with Unified Monitoring and Cost Management

Snowflake tag-based data protection policies: a governance shift

2026-07-27T00:00:00Z

Snowflake just made it possible to attach a data protection policy to a tag, and have every object carrying that tag inherit the policy automatically. Tag-based data protection policies entered public preview on July 21, 2026, covering four policy types: row access, aggregation, projection, and join policies. The shift is from object-by-object governance to attribute-based access control (ABAC), where a single tag assignment can lock down a column, a table, or an entire schema without writing a separate ALTER TABLE ... SET POLICY for each one.

The core mechanic: one tag, one policy, automatic propagation. You create a tag, set a policy on the tag, then set the tag on any object. The object inherits the policy through Snowflake's existing tag propagation rules. Add a new table and tag it, and the policy is already enforced. This is a concrete decision for any team managing access control at scale on Snowflake, and it pairs naturally with the fundamentals covered in our Snowflake RBAC and masking guide.

What exactly shipped in this release?

Snowflake announced tag-based policy support as a public preview feature on July 21, 2026. It covers four policy types:

Row access policies: filter rows based on the querying role or context.
Aggregation policies: enforce minimum group sizes, suppressing small aggregates to prevent inference attacks.
Projection policies: restrict which columns a role can project, complementing column-level masking.
Join policies: control which tables can be joined together, preventing cross-domain data leakage.

The general workflow for all four types follows the same three steps. First, create a tag. Second, set the policy on the tag with an ALTER TAG command. Third, set the tag on the object. The object then inherits the policy automatically.

Here is the DDL for creating a tag and attaching a row access policy:

-- Step 1: create the tag
CREATE TAG IF NOT EXISTS governance.pii_sensitive
  COMMENT = 'Marks objects subject to PII row-level controls';

-- Step 2: set a row access policy on the tag
ALTER TAG governance.pii_sensitive
  SET ROW ACCESS POLICY governance.pii_row_filter;

-- Step 3: set the tag on a table
ALTER TABLE sales.customers
  SET TAG governance.pii_sensitive = 'true';

The table now enforces governance.pii_row_filter for any query against it, with no direct ALTER TABLE ... SET ROW ACCESS POLICY call. The same pattern works for the other three policy types, each with its own ALTER TAG variant.

For aggregation policies, the syntax includes an optional ENTITY KEY clause that specifies the grouping columns the policy applies to:

ALTER TAG governance.aggregate_sensitive
  SET AGGREGATION POLICY governance.min_group_size_5
  ENTITY KEY (department_id);

The tag-based aggregation policy documentation confirms that smaller groups are suppressed when the aggregate query produces results below the policy's minimum threshold. The entity key tells the policy which columns define the group boundary.

For projection policies, the pattern is the same:

ALTER TAG governance.restricted_columns
  SET PROJECTION POLICY governance.limit_projection;

How does tag inheritance propagate the policy?

This is where the feature earns its keep. Snowflake tags already support inheritance and propagation across the object hierarchy. When you set a tag on a database or schema, every table and view inside inherits that tag. Now that policies can ride on tags, the inheritance carries the policy with it.

The inheritance chain works like this:

Object level	Tag set here	Policy applies to
Database	`ALTER DATABASE db SET TAG pii = 'true'`	All schemas, tables, views in the database
Schema	`ALTER SCHEMA sch SET TAG pii = 'true'`	All tables and views in the schema
Table	`ALTER TABLE tbl SET TAG pii = 'true'`	All columns and the table itself
View	`ALTER VIEW vw SET TAG pii = 'true'`	The view, queried through the policy

The key behavior: if a tag is set at the database level, every new table created in that database inherits the tag and the policy. You do not need to touch the new table at all. This is the operational win. A data engineer creating a derived table from a tagged source does not need to remember to attach the policy. The tag does the remembering.

There is a subtlety. Tag propagation is not the same as policy cascading. The tag propagates, and the policy is attached to the tag, so the effective policy on any object is the one bound to the most specific tag that applies. If a table has a tag set directly and the schema has the same tag set, the table-level tag wins. If different tags with different policies are set at different levels, you need to understand the precedence rules.

How do you migrate from per-object policies to tag-based policies?

If you already have row access or projection policies attached directly to dozens of tables, you can migrate to the tag-based model. The process is straightforward but requires care.

First, inventory what you have. This ACCOUNT_USAGE query finds every object with a row access policy attached directly:

SELECT
  policy_db,
  policy_schema,
  policy_name,
  ref_database_name,
  ref_schema_name,
  ref_entity_name,
  ref_entity_domain,
  tag
FROM snowflake.account_usage.policy_references
WHERE policy_kind = 'ROW_ACCESS_POLICY'
  AND tag IS NULL  -- direct attachment, not tag-based
ORDER BY ref_database_name, ref_schema_name;

The tag column in POLICY_REFERENCES is NULL for direct attachments and non-NULL when the policy comes through a tag. This is how you audit the transition.

Second, create a tag for each logical policy group. If you have a row access policy called sales_region_filter attached to 30 tables, create a tag called region_filtered and set the policy on it:

CREATE TAG governance.region_filtered;
ALTER TAG governance.region_filtered
  SET ROW ACCESS POLICY governance.sales_region_filter;

Third, set the tag on the objects and drop the direct policy attachment:

-- set the tag
ALTER TABLE sales.east_region SET TAG governance.region_filtered = 'true';
ALTER TABLE sales.west_region SET TAG governance.region_filtered = 'true';

-- drop the direct policy attachment
ALTER TABLE sales.east_region
  UNSET ROW ACCESS POLICY governance.sales_region_filter;
ALTER TABLE sales.west_region
  UNSET ROW ACCESS POLICY governance.sales_region_filter;

Do this in batches and verify with the ACCOUNT_USAGE query after each batch. The policy enforcement does not interrupt during the migration: the direct policy is active until you unset it, and the tag-based policy is active as soon as the tag is set. There is a brief window where both are active, but since they are the same policy, the behavior is identical.

What does this cost in credits and complexity?

Tag-based policies do not introduce new credit charges. The compute cost is the same as per-object policies. Row access policies, aggregation policies, and projection policies all execute during query runtime, and that runtime cost has not changed. What changes is the management overhead.

The chart below illustrates the operational difference for a 400-object estate where each object needs a row access policy:

Illustrative: per-object vs tag-based policy management for a 400-object estate. Synthetic example based on Snowflake documentation patterns. Data Today benchmark.

In the per-object model, you maintain 1,200 policy attachments (400 objects, each with up to three policy types). In the tag-based model, you maintain one tag per logical policy group and set tags on objects. The audit query time drops from roughly three hours of manual reconciliation to a 15-minute automated query against POLICY_REFERENCES.

But tag-based policies introduce their own complexity costs:

Tag sprawl: if you create a tag for every policy variant, you end up with dozens of tags that are hard to name, govern, and audit. Tags need a naming convention and a lifecycle.
Policy precedence: when multiple tags with different policies apply to the same object, the resolution order matters. You need to test and document which policy wins.
Audit complexity: the POLICY_REFERENCES view now has two entry types (direct and tag-based). Auditors need to understand the difference and query both.
Privilege separation: the ability to set tags and the ability to create policies should be separated. A role that can both create a policy and attach it to a tag is a governance bypass.

The privilege model uses existing Snowflake tag privileges. To create and manage tags, a role needs the CREATE TAG privilege on the schema. To set a policy on a tag, the role needs APPLY ROW ACCESS POLICY (or the equivalent for other policy types) plus APPLY TAG on the tag. To set a tag on an object, the role needs APPLY TAG on the tag and ownership of the object.

Here is the grant set for a governance role:

-- governance role can create tags and set policies on them
GRANT CREATE TAG ON SCHEMA governance TO ROLE governance_admin;
GRANT APPLY ROW ACCESS POLICY ON ACCOUNT TO ROLE governance_admin;
GRANT APPLY AGGREGATION POLICY ON ACCOUNT TO ROLE governance_admin;
GRANT APPLY PROJECTION POLICY ON ACCOUNT TO ROLE governance_admin;

-- data engineering roles can set tags on objects they own
GRANT APPLY TAG ON TAG governance.pii_sensitive TO ROLE data_engineer;

The separation matters. If data_engineer can create tags and set policies on them, they can effectively bypass any governance control by creating a new tag with no policy. Keep tag creation and policy attachment in the governance role, and give data engineers only the APPLY TAG grant for setting existing tags on their objects.

When is tag-based policy the wrong choice?

Tag-based policies shine when you have a policy that applies to many objects with the same protection needs. They are the wrong choice in three scenarios.

First, when each object needs a slightly different policy. Row access policies that filter by region, for example, might use a different region column name on different tables. The tag-based model attaches one policy to a tag, and the policy must work for every object carrying that tag. If customers uses cust_region and orders uses order_region, a single row access policy on a tag will not work without a mapping table or a consistent column convention. In that case, direct per-object policies are simpler.

Second, when the policy is temporary or experimental. If you are testing a new aggregation policy on a single table for two weeks, attaching it directly is faster than creating a tag, setting the policy on the tag, setting the tag on the table, and then cleaning up all three when the test ends. The tag-based model adds two extra DDL steps. For one object, that is overhead with no payoff.

Third, when you need precise per-object audit trails. Tag-based policies make it harder to answer the question "what policy is on this specific table right now?" because the answer is indirect: the table has a tag, the tag has a policy. You can query it, but it is one more join in your audit logic. For environments where regulators require a direct, per-object policy inventory, per-object attachment may be easier to evidence.

How do you audit tag-based policy enforcement?

The POLICY_REFERENCES view in ACCOUNT_USAGE is the primary audit surface. It now includes a TAG column that is non-NULL when the policy is applied through a tag.

SELECT
  ref_database_name,
  ref_schema_name,
  ref_entity_name,
  ref_entity_domain,
  policy_name,
  policy_kind,
  tag  -- NULL = direct, non-NULL = tag-based
FROM snowflake.account_usage.policy_references
WHERE ref_database_name = 'SALES'
  AND policy_kind IN ('ROW_ACCESS_POLICY', 'AGGREGATION_POLICY',
                      'PROJECTION_POLICY', 'JOIN_POLICY')
ORDER BY ref_entity_name, policy_kind;

For real-time auditing (the ACCOUNT_USAGE view has latency), use the Information Schema equivalent:

SELECT *
FROM sales.information_schema.policy_references
WHERE policy_kind = 'ROW_ACCESS_POLICY';

The Information Schema view is current as of the query time, while ACCOUNT_USAGE has a latency of up to a few hours. For compliance reports, use ACCOUNT_USAGE for history and Information Schema for point-in-time checks.

A useful governance query finds objects that have a tag with a policy but also have a direct policy attached, which can cause unexpected precedence conflicts:

SELECT
  ref_entity_name,
  ref_entity_domain,
  policy_name,
  policy_kind,
  tag
FROM snowflake.account_usage.policy_references
WHERE tag IS NOT NULL
  AND ref_entity_name IN (
    SELECT inner_q.ref_entity_name
    FROM snowflake.account_usage.policy_references inner_q
    WHERE inner_q.tag IS NULL
  )
ORDER BY ref_entity_name;

This surfaces objects where both a tag-based and a direct policy exist. Clean those up during migration to avoid ambiguity.

What should you do during public preview?

Public preview means the feature is usable but not GA. Three things to keep in mind.

First, preview features can change. The SQL syntax, the privilege model, and the inheritance behavior may shift before GA. If you build automation around tag-based policies now, wrap it in a layer that can absorb syntax changes. Use stored procedures or a governance tool rather than hardcoding DDL in pipelines.

Second, test tag propagation in a non-production account first. Create a tag at the schema level, set a row access policy on it, and verify that a new table created in that schema inherits the policy. Then test edge cases: renaming a table with a tag, dropping a tag that has a policy attached, and setting multiple tags with different policies on the same object.

Third, start with one policy type. Row access policies are the most common and the easiest to validate. Attach one row access policy to one tag, set the tag on a small group of tables, and run your existing audit queries to confirm the behavior. Expand from there.

The governance shortcut you still have to earn

Tag-based policies solve the hardest part of data governance at scale: the fact that every new table is a potential gap. With tags, the policy travels with the classification, not the object. That is a real shift. But the tag still has to be set correctly, the policy still has to be written correctly, and the privilege model still has to separate the people who classify data from the people who create policies. The feature gives you the mechanism. The discipline is still yours.

Sources

Snowflake workload identity federation kills static credentials

2026-07-06T00:00:00Z

Every Snowflake pipeline that calls an external API has the same dirty secret: somewhere in a secret object, a UDF, or an integration, there is a long-lived credential that someone has to rotate. On July 1, 2026, Snowflake shipped workload identity federation for Snowflake workloads that access external services into general availability, and it removes that credential from the picture entirely. Snowflake now acts as the OpenID Connect provider, issuing short-lived ID tokens that a Snowflake workload can present to an external service for authentication. No static key. No rotation calendar. No key accidentally expiring on a Friday night and breaking the pipeline. If you own the Snowflake bill or the security posture around it, this is the most consequential governance change of the quarter, and it costs you zero additional credits to use.

The mechanics are straightforward. You create a secret of type WORKLOAD_IDENTITY_FEDERATION, which makes Snowflake an OIDC provider with an issuer URL and registers the workload as an OIDC client with a subject identifier. You hand those two values to the external service so it can verify tokens. When the workload needs to authenticate, it calls SYSTEM$ISSUE_WORKLOAD_IDENTITY_FEDERATION_TOKEN, receives an encoded ID token, and sends it to the service. The service verifies the token's signature against Snowflake's published public keys, checks the iss and sub and aud claims, and grants access. The whole trust flow is four steps, shown in the chart below. The key number is zero: zero static credentials to rotate, zero additional compute cost, zero new integration objects to license.

Illustrative: Four-step trust flow from secret creation through token issuance to external service verification. Issuer URL and subject identifier are shared with the external service to establish trust. Source: Snowflake documentation.

What exactly did Snowflake ship?

Snowflake's release notes for July 1, 2026 confirm that workload identity federation for Snowflake workloads accessing external services is now generally available. The feature lets Snowflake act as the OIDC provider when a Snowflake workload authenticates to an external service, which is a role reversal worth pausing on. In most federation setups, the external service or a dedicated identity provider plays the OIDC provider role. Here, Snowflake itself holds that role, which means the trust anchor lives inside your Snowflake account and follows your account's replication and failover behaviour.

The core objects and functions are minimal. A secret of type WORKLOAD_IDENTITY_FEDERATION is a schema-level object that stores the issuer URL and subject identifier. The system function SYSTEM$ISSUE_WORKLOAD_IDENTITY_FEDERATION_TOKEN takes two arguments: the secret identifier and a JSON payload specifying the audience, and returns an encoded ID token conforming to the OIDC specification. There is a 1:1 relationship between the Snowflake workload and Snowflake as the OIDC provider, but the same secret can authenticate to multiple services, which means you do not proliferate secrets for every downstream API.

The DDL to create the secret is a single statement:

CREATE SECRET my_db.auth.my_workload
  TYPE = WORKLOAD_IDENTITY_FEDERATION;

Once the secret exists, you describe it to extract the two values the external service needs:

DESC SECRET my_db.auth.my_workload;

The output includes two columns you hand to the external service administrator: workload_identity_federation_issuer, which is the issuer URL of Snowflake as the OIDC provider and maps to the iss claim, and workload_identity_federation_subject, which is the workload's OIDC client identifier and maps to the sub claim. The external service compares those values against the incoming token. If they match, the token is authentic.

How do you issue a token and use it?

The token issuance function is callable from any context where a Snowflake workload runs: a stored procedure, a UDF, a Snowpark Container Services workload, or a task. The call takes the secret and an audience identifier in JSON format:

SELECT SYSTEM$ISSUE_WORKLOAD_IDENTITY_FEDERATION_TOKEN(
  'my_db.auth.my_workload',
  '{"aud": "example-cloud-service.com"}');

The audience value becomes the aud claim of the returned ID token. You send that encoded token to the external service as a bearer credential. The service validates it by fetching Snowflake's public keys from the issuer URL's well-known endpoint, verifying the signature, and checking that the iss, sub, and aud claims match what you pre-registered. This is standard OIDC token verification on the service side, so any service that already supports OIDC identity federation, such as GitHub Actions, Google Cloud Workload Identity Federation, or HashiCorp Vault, can be configured to trust Snowflake-issued tokens without custom code.

A before-and-after makes the difference concrete:

Step	Before (static credentials)	After (workload identity federation)
Credential storage	API key stored in a `PASSWORD` or `OAUTH` secret	No stored credential. WIF secret holds issuer and subject only
Rotation	Manual or scheduled rotation every 60 to 90 days	No rotation. Tokens are short-lived and issued on demand
Blast radius if leaked	Static key works until revoked	Stolen token expires within minutes
Cross-service reuse	One secret per service	One WIF secret authenticates to multiple services via audience
Replication behaviour	Secret replicates but external trust may break on failover	Issuer and subject replicate unchanged. Trust survives failover

Illustrative: Static credentials require rotation across two integration types with a 90-day operational burden. Workload identity federation eliminates static credentials by issuing short-lived OIDC tokens. Source: Snowflake documentation.

The chart above shows the operational difference: two credentials to rotate with a 90-day burden in the static model, versus zero static credentials and a token lifetime measured in minutes under federation.

How does this behave under replication and failover?

This is where Snowflake's design choice to be the OIDC provider pays off. The docs are explicit about three replication properties. First, the federated identity is preserved across failover: the secret's issuer URL and subject identifier replicate unchanged, so after a failover the external service continues to recognise the same iss and sub claims. Second, ID tokens can only be issued from the primary account. Calling SYSTEM$ISSUE_WORKLOAD_IDENTITY_FEDERATION_TOKEN in an account that is a read-only secondary fails. Third, token verification continues to work after failover because the issuer URL automatically resolves to the current primary account, which publishes the public keys the service uses to verify the token signature. You do not need to update the external service's configuration after a failover.

For teams running business continuity drills, this matters. A common failure mode with static credentials in a replicated setup is that the credential works in the primary but the external service's allow-list is pinned to a specific endpoint or account identifier that changes after failover. With workload identity federation, the trust relationship is defined by the issuer URL and subject, both of which follow the primary, so the failover is transparent to the external service as long as it can reach the issuer URL.

The one constraint to plan for is that token issuance is primary-only. If you have a workload running in a secondary account that calls external services, it cannot mint tokens until it becomes the primary. Design those workloads to either tolerate token issuance failure during a failover window or defer external calls until promotion completes.

What privileges and limits apply?

The secret is a schema-level object, so the standard CREATE SECRET privilege and USAGE on the containing database and schema apply. To issue tokens, the executing role needs USAGE on the secret. The relevant grants look like this:

GRANT USAGE ON SECRET my_db.auth.my_workload
  TO ROLE my_pipeline_role;

That is the only privilege the workload role needs. It does not need access to any external credential, and it does not need a stored key. From a governance standpoint, this tightens the blast radius considerably. If you pair this with the approach in our Snowflake RBAC and masking guide, you can isolate external-service access to a single role that holds nothing but USAGE on the WIF secret, which is about as narrow as a privilege model gets.

The docs do not publish a hard rate limit on SYSTEM$ISSUE_WORKLOAD_IDENTITY_FEDERATION_TOKEN, but the design is clearly built for on-demand issuance per call to an external service, not for caching tokens at high frequency. Tokens are short-lived by OIDC convention, so a workload that calls an external API hundreds of times per minute should cache the token for its lifetime and reuse it, then request a new one when it expires. Caching logic belongs in your UDF or stored procedure, not in the secret.

How is it billed?

This is the question that usually has a catch, and here it does not. Workload identity federation introduces no additional credit charge. The secret is a metadata object. The token issuance function runs in the cloud services layer, not in a virtual warehouse, so it does not consume compute credits. The only cost surface is the warehouse that your UDF, stored procedure, or task runs in, and that is cost you were already paying before you switched from a static credential to a federated token.

If you want to confirm this in your own account, query the ACCESS_HISTORY view in SNOWFLAKE.ACCOUNT_USAGE to see which objects called the token function and whether any warehouse was involved:

SELECT query_id, query_text, user_name, role_name,
       warehouse_name, start_time
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE query_text ILIKE '%SYSTEM$ISSUE_WORKLOAD_IDENTITY_FEDERATION_TOKEN%'
  AND start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
ORDER BY start_time DESC;

If warehouse_name is null for those rows, the function executed in the cloud services layer and consumed no compute credits. That is the expected result.

When is it the wrong choice?

This feature is not universal. The external service must support OIDC token verification, and specifically must let you configure a custom issuer URL and expected subject. Many SaaS APIs do. Some older or internal services do not, and for those you are stuck with API keys or OAuth refresh tokens for now. Before you invest in migrating a pipeline, confirm the external service's documentation supports configuring a custom OIDC issuer and audience validation.

The primary-only token issuance constraint also makes this a poor fit for active-active architectures where both accounts in a replication pair need to call external services simultaneously. You can only issue from the current primary, so a workload in a secondary account that needs to authenticate externally will fail until promotion. If your DR strategy requires the secondary to be continuously operational against external APIs, you need a static credential fallback or a different architecture.

Finally, if your external service cannot reach Snowflake's issuer URL over the public internet to fetch public keys, token verification will fail. This is not a feature for air-gapped or fully private endpoint scenarios unless the external service supports fetching keys from a Snowflake internal endpoint, which the current GA docs do not describe.

What should you do with it now?

Start with the highest-risk pipeline you have: the one where a static API key is stored in a secret and used by a task or UDF to call an external service. That is your first migration candidate because it has the most to lose from credential theft and the most to gain from elimination of rotation. Audit those secrets first:

SELECT name, secret_type, created_on, last_altered
FROM SNOWFLAKE.ACCOUNT_USAGE.SECRETS
WHERE secret_type IN ('PASSWORD', 'OAUTH')
ORDER BY created_on;

For each secret, check whether the downstream service supports OIDC. If it does, create a WORKLOAD_IDENTITY_FEDERATION secret, register the issuer and subject with the service, swap the token issuance call into your UDF or procedure, and drop the static secret. Test in a non-production account first, and specifically test a failover drill to confirm the external service still authenticates after promotion.

Do not try to migrate every integration at once. Pick one, get the trust flow working end to end, and document the external service's configuration steps for your team. The external-side setup is the part that varies the most and the part that will eat your time.

The real shift

Workload identity federation is a quiet change with an outsized payoff. Snowflake is making a claim about where trust should live in a data platform: not in a vault of static keys that engineers have to babysit, but in the platform itself, issuing ephemeral credentials that expire before anyone can abuse them. For a data engineer, that is one fewer rotation ticket, one fewer 2 a.m. page, and one fewer entry in the secret-scanning audit. For a security team, it is a measurable reduction in standing credential risk. The cost is zero. The migration is incremental. The reason not to start is shrinking.

Sources

Dynamic Iceberg table replication, costed honestly

2026-06-29T00:00:00Z

Dynamic Iceberg table replication fixes a small sentence with a big blast radius. If you used dynamic Iceberg tables for lakehouse transforms, your DR plan had an awkward hole: the table could live in a database that replicated, while the dynamic Iceberg table itself got skipped.

On June 29, 2026, Snowflake made dynamic Iceberg table replication generally available, saying dynamic Iceberg tables are now supported in replication and failover groups. The key number is 1 missing object class: the pipeline output that used to fall out of refresh operations can now travel with the group.

That matters if your Iceberg estate is no longer just raw lake data. Dynamic Iceberg tables combine scheduled Snowflake transforms with Iceberg output, so Spark, Trino, or another engine can read the materialized result directly. Snowflake says a dynamic Iceberg table stores output in Apache Iceberg format on Snowflake managed external storage and supports the same refresh modes and scheduling as a regular dynamic table, while external engines can read the data directly through the Iceberg files.

The vendor honest read: this is good DR plumbing, not magic. You still have to replicate the database, include the external volume, configure storage access in the target region, pay replication costs on the target account, and keep an eye on the dynamic table refresh bill. If you skip those parts, GA is just a nicer error message waiting for a maintenance window.

What actually changes for a dynamic Iceberg table in DR?

Before this release, Snowflake says dynamic Iceberg tables were skipped during replication refresh operations. After the June 29, 2026 release, Snowflake says replication supports dynamic Iceberg tables as part of replication and failover groups.

That is the whole feature, and it is enough.

A dynamic Iceberg table is still created with CREATE DYNAMIC ICEBERG TABLE. Snowflake's dynamic Iceberg guide says the create statement requires the Iceberg specific EXTERNAL_VOLUME, CATALOG, and BASE_LOCATION parameters when you use an external volume, and the documented example uses a TARGET_LAG of 10 minutes.

CREATE OR REPLACE DYNAMIC ICEBERG TABLE lake_gold.dt_orders_iceberg
    TARGET_LAG = '10 minutes'
    WAREHOUSE = transform_wh
    EXTERNAL_VOLUME = 'exvol_lake_gold'
    CATALOG = 'SNOWFLAKE'
    BASE_LOCATION = 'dt_orders_iceberg'
    REFRESH_MODE = INCREMENTAL
AS
    SELECT
        order_id,
        customer_id,
        order_date,
        quantity * unit_price AS line_total
    FROM raw.orders
    WHERE order_status != 'returned';

A quick verification step belongs in your runbook because Snowflake exposes an is_iceberg flag in SHOW DYNAMIC TABLES; Snowflake's example shows is_iceberg returning true for a dynamic Iceberg table.

SHOW DYNAMIC TABLES LIKE 'dt_orders_iceberg';

The DR side is group based. Snowflake's Iceberg replication guide says Snowflake replicates an Iceberg table when you add its parent database to a replication or failover group, but it also says Snowflake managed Iceberg tables rely on external volumes that need extra configuration before replication can work.

CREATE REPLICATION GROUP rg_lake_gold
    OBJECT_TYPES = DATABASES, EXTERNAL VOLUMES
    ALLOWED_DATABASES = lake_gold
    ALLOWED_EXTERNAL_VOLUMES = exvol_lake_gold
    ALLOWED_ACCOUNTS = myorg.prod_dr
    REPLICATION_SCHEDULE = '10 MINUTE';

On the target account, the replica is still explicit. Snowflake documents the secondary group syntax as AS REPLICA OF <org_name>.<source_account_name>.<name> for replication groups.

CREATE REPLICATION GROUP rg_lake_gold
    AS REPLICA OF myorg.prod_primary.rg_lake_gold;

ALTER REPLICATION GROUP rg_lake_gold REFRESH;

The shape of the design is simple: database plus external volume. If your table depends on an external volume and the group only includes DATABASES, you have copied the catalog object without the storage access object that makes it useful.

Which Snowflake objects and privileges do you need?

There are two DR paths, and they carry different operational meaning. A replication group gives you a secondary copy. A failover group is the route when you want planned promotion of the secondary account.

Snowflake's CREATE REPLICATION GROUP reference says database and share replication are available to all accounts, while replication of other account objects and failover or failback require Business Critical Edition or higher. Snowflake's CREATE FAILOVER GROUP reference is stricter: the command itself requires Business Critical Edition or higher.

Choice	Use it when	Edition or privilege detail
Replication group	You need a readable secondary copy of the database and external volume object	`CREATE REPLICATION GROUP` on the account, `MONITOR` on the database, and `USAGE` on the external volume
Failover group	You need failover and failback planning for the secondary account	Business Critical Edition or higher, plus `CREATE FAILOVER GROUP` on the account
Database or schema backup	You need backup semantics rather than cross account DR	Dynamic Iceberg tables are excluded from database or schema backups in Snowflake's dynamic Iceberg limitations

The privilege model is thankfully concrete. Snowflake says a role creating a replication group needs CREATE REPLICATION GROUP on the account, MONITOR on the database being added, and USAGE on the external volume being added.

GRANT CREATE REPLICATION GROUP ON ACCOUNT TO ROLE dr_admin;
GRANT MONITOR ON DATABASE lake_gold TO ROLE dr_admin;
GRANT USAGE ON EXTERNAL VOLUME exvol_lake_gold TO ROLE dr_admin;

For failover groups, Snowflake says the corresponding minimums are CREATE FAILOVER GROUP on the account, MONITOR on the database, and USAGE on the external volume.

GRANT CREATE FAILOVER GROUP ON ACCOUNT TO ROLE dr_admin;
GRANT MONITOR ON DATABASE lake_gold TO ROLE dr_admin;
GRANT USAGE ON EXTERNAL VOLUME exvol_lake_gold TO ROLE dr_admin;

There is one more setup step that is easy to bury in a platform ticket. Snowflake's Iceberg replication guide says a user with the ORGADMIN role must enable replication for each source and target account in the organization.

USE ROLE ORGADMIN;

SELECT SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER(
    'MYORG.PROD_PRIMARY',
    'ENABLE_ACCOUNT_DATABASE_REPLICATION',
    'true'
);

The lock down advice: do not run this forever as ACCOUNTADMIN. Create a narrow DR role, grant the three required privileges, and make every group definition code reviewed. The dangerous part is not the refresh command. The dangerous part is a broad OBJECT_TYPES list that quietly expands the blast radius.

How does dynamic Iceberg table replication get billed?

Snowflake splits replication cost into data transfer and compute resources, and it bills both categories to the target account that stores the secondary database or secondary replication or failover group. Snowflake also says replication compute appears with service type REPLICATION in Account Usage and Organization Usage views.

That target account detail is the budget trap. Your primary warehouse owner can ship a new dynamic Iceberg table, while the DR account absorbs refresh transfer and replication compute. If FinOps only watches the primary account, the bill moves sideways and looks like a mystery.

Snowflake's replication cost page gives two levers that matter every week: monthly billing is proportional to the amount of changed table data and the frequency of refreshes. For failover groups using optimized refresh, Snowflake documents 5 credits per TB of replicated data and 0.2 credits per 10,000 changed objects after the first 25,000,000 changed objects per account per month.

Dynamic table cost is separate from replication cost. Snowflake's dynamic table cost guide says dynamic tables have three cost components: virtual warehouse compute, Cloud Services compute, and storage, while dynamic Apache Iceberg tables use external storage and do not incur Snowflake storage costs for that materialized output. If you want the broader refresh economics, we covered the mechanics in our dynamic table refresh cost test.

Your first cost query should prove replication spend from the target account.

SELECT
    start_time::date AS usage_date,
    replication_group_name,
    ROUND(SUM(credits_used), 4) AS credits_used,
    SUM(bytes_transferred) AS bytes_transferred
FROM snowflake.account_usage.replication_group_usage_history
WHERE start_time >= DATEADD('day', -30, CURRENT_TIMESTAMP())
GROUP BY 1, 2
ORDER BY usage_date DESC, credits_used DESC;

Your second query should prove whether the dynamic table itself is churning. Snowflake's DYNAMIC_TABLE_REFRESH_HISTORY Account Usage view retains 365 days of refresh history and includes REFRESH_ACTION, STATE, QUERY_ID, timing columns, and row statistics.

SELECT
    database_name,
    schema_name,
    name,
    refresh_action,
    state,
    COUNT(*) AS refreshes,
    SUM(statistics:numInsertedRows::number) AS inserted_rows,
    SUM(statistics:numDeletedRows::number) AS deleted_rows
FROM snowflake.account_usage.dynamic_table_refresh_history
WHERE data_timestamp >= DATEADD('day', -7, CURRENT_TIMESTAMP())
  AND database_name = 'LAKE_GOLD'
GROUP BY 1, 2, 3, 4, 5
ORDER BY refreshes DESC;

Use the chart below as the monitoring rule of thumb: Information Schema is the short window for live debugging, while Account Usage is the durable audit trail. Snowflake documents 14 days for the replication usage table function and 365 days for the Account Usage replication group usage view.

Snowflake monitoring documentation lists 14 days for Information Schema replication usage functions and 365 days for the Account Usage REPLICATION_GROUP_USAGE_HISTORY view. Source: Snowflake documentation. Data Today benchmark.

That difference should change where you put dashboards. If an incident review happens on day 21, the 14 day function is already gone. Account Usage is where the postmortem survives.

What breaks if the external volume is wrong?

The refresh fails. There is no glamorous answer here.

Snowflake's Iceberg replication guide says replicated tables require access to a storage location in the same region as the target account, and it warns that refresh operations can fail if Snowflake cannot access the target account's storage location.

The external volume setup is easy to under-specify because the table DDL hides it behind one object name. Snowflake's sample workflow adds a storage location to the external volume, retrieves the target account's Snowflake service principal with SYSTEM$DESC_ICEBERG_ACCESS_IDENTITY, and then creates the replication or failover group with EXTERNAL VOLUMES in OBJECT_TYPES.

SHOW REPLICATION ACCOUNTS LIKE 'PROD_DR%';

SELECT SYSTEM$DESC_ICEBERG_ACCESS_IDENTITY(
    'S3',
    'PROD_DR'
);

Then include the external volume in the group. Snowflake explicitly documents ALLOWED_EXTERNAL_VOLUMES for both replication and failover groups.

ALTER REPLICATION GROUP rg_lake_gold SET
    OBJECT_TYPES = DATABASES, EXTERNAL VOLUMES
    ALLOWED_EXTERNAL_VOLUMES = exvol_lake_gold;

Two caveats deserve sticky notes. First, Snowflake says secondary tables in the target account are read only until you promote the target account to serve as the source account. Second, Snowflake says an external volume can only be added to one replication or failover group.

That second rule shapes your topology. A shared external volume across too many domains can block clean DR group boundaries. If finance, product analytics, and ML features all write through one external volume, your replication groups inherit that coupling.

When should you use this, and when should you hold back?

Use dynamic Iceberg table replication when the dynamic Iceberg table is a production contract. That usually means at least one of three things is true:

A downstream engine such as Spark or Trino reads the Iceberg output directly.
The table is part of a recovery time objective that already names a secondary Snowflake account.
Rebuilding the table from raw data would violate your recovery point objective or burn too many warehouse credits during an outage.

Hold back when the table is cheap to rebuild, experimental, or downstream only inside one Snowflake account. Replicating every derived object feels safe until every 10 minute schedule becomes a metronome for target account charges.

The practical rollout is four steps.

Inventory dynamic Iceberg tables with SHOW DYNAMIC TABLES and the is_iceberg flag.
Put only production databases and their external volumes into the first replication group.
Run a manual ALTER REPLICATION GROUP ... REFRESH before setting a schedule.
Watch REPLICATION_GROUP_USAGE_HISTORY and DYNAMIC_TABLE_REFRESH_HISTORY for 7 days before expanding scope.

Here is the inventory query pattern once the SHOW output is captured with RESULT_SCAN.

SHOW DYNAMIC TABLES IN DATABASE lake_gold;

SELECT
    "database_name",
    "schema_name",
    "name",
    "refresh_mode",
    "scheduling_state",
    "is_iceberg"
FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()))
WHERE "is_iceberg" = 'true';

The strongest bet: use this for DR coverage of curated Iceberg outputs that other engines consume. The weak bet: using it as a blanket substitute for pipeline rebuild discipline. Replication preserves objects. It does not prove your transform logic is affordable, your target storage permissions are correct, or your failover game day will pass.

The DR gap moved from feature support to operating discipline

Snowflake closed the obvious product gap on June 29, 2026. Dynamic Iceberg table replication now belongs in the standard DR checklist for Iceberg pipelines.

The new failure mode is more ordinary: a group without EXTERNAL VOLUMES, a target account nobody budgets, a 10 minute schedule copied from an example, and a runbook that never checks Account Usage. Enterprise data platforms rarely fail because one feature is missing. They fail because the feature arrived, and nobody updated the boring parts.

Sources

Snowflake Dynamic Tables refresh gets a cost test

2026-06-22T00:00:00Z

Snowflake Dynamic Tables used to be a clean idea with a practical ceiling: great when your transformation fit a SELECT, less great when your pipeline needed CDC semantics, MERGE logic, Iceberg output, or a bill you could explain without squinting. The June 2026 update changes that trade. Snowflake Dynamic Tables now have a claimed up to 2.8x faster refresh performance on popular patterns measured from May 2025 to May 2026 on Gen2 warehouses, plus preview support for custom incrementalization with MERGE and INSERT logic in REFRESH USING, according to Snowflake's June 15 Dynamic Tables blog.

The useful read for a data engineer is simple: Dynamic Tables are becoming Snowflake's default managed transformation layer. That does not mean you should port every Stream and Task tomorrow. It means the boundary moved. SELECT based transformations, SCD type 1 dedupe, append heavy aggregates, dbt models, and some CDC style workloads now belong in the Dynamic Tables discussion before you design another orchestration DAG.

If you are also sizing Gen2 compute, read this alongside our guide to Snowflake Gen2 warehouses. The refresh win Snowflake is advertising is tied to Gen2 warehouses, and the bill will still be decided by target lag, refresh mode, reinitializations, and how many tables you keep active.

What actually got faster in Snowflake Dynamic Tables?

Snowflake says its benchmark suite for common Dynamic Table patterns improved by up to 2.8x between May 2025 and May 2026, with the tested optimizations covering top level aggregate functions, QUALIFY row or rank equals 1 patterns for SCD type 1, clustering operations, and joins on Gen2 warehouses in the product announcement.

That matters because Dynamic Tables do two separate jobs. They materialize query results, and they refresh those results on a schedule Snowflake controls from your TARGET_LAG. In the syntax reference, Snowflake defines TARGET_LAG as the maximum time the Dynamic Table should lag behind changes to its base tables, with a documented minimum of 60 seconds when the scheduler is enabled in CREATE DYNAMIC TABLE syntax.

A basic production definition should be boring on purpose:

CREATE OR REPLACE DYNAMIC TABLE mart.dt_orders_latest
  TARGET_LAG = '10 minutes'
  WAREHOUSE = transform_wh
  INITIALIZATION_WAREHOUSE = init_wh_l
  REFRESH_MODE = INCREMENTAL
AS
SELECT * EXCLUDE rn
FROM (
  SELECT
    o.*,
    ROW_NUMBER() OVER (
      PARTITION BY order_id
      ORDER BY updated_at DESC
    ) AS rn
  FROM raw.orders_cdc o
)
QUALIFY rn = 1;

Two details in that snippet are worth copying. First, REFRESH_MODE = INCREMENTAL makes the behavior deterministic instead of letting AUTO choose at creation time. Snowflake's refresh mode docs say AUTO resolves once when the table is created, then does not keep reevaluating on later refreshes, so production code should pin the mode after testing in refresh modes. Second, INITIALIZATION_WAREHOUSE lets you separate the warehouse for initializations and reinitializations from the smaller warehouse that handles normal refreshes, as documented in the CREATE DYNAMIC TABLE parameter reference.

The best design pattern is still chain shaped. Put cleanup in one Dynamic Table, joins in another, and aggregation in a downstream table. Snowflake documents TARGET_LAG = DOWNSTREAM for intermediate Dynamic Tables, which refresh only when dependent Dynamic Tables refresh, in the CREATE DYNAMIC TABLE syntax. That is where you avoid paying for a silver layer that no consumer asked to update.

CREATE OR REPLACE DYNAMIC TABLE silver.dt_orders_clean
  TARGET_LAG = DOWNSTREAM
  WAREHOUSE = transform_wh
  REFRESH_MODE = INCREMENTAL
AS
SELECT order_id, customer_id, order_ts, amount
FROM raw.orders
WHERE status != 'cancelled';

CREATE OR REPLACE DYNAMIC TABLE gold.dt_revenue_hourly
  TARGET_LAG = '15 minutes'
  WAREHOUSE = transform_wh
  REFRESH_MODE = INCREMENTAL
AS
SELECT DATE_TRUNC('hour', order_ts) AS hour, SUM(amount) AS revenue
FROM silver.dt_orders_clean
GROUP BY 1;

How does the refresh mode choice change your pipeline design?

The big change is that Dynamic Tables now cover more of the space Streams and Tasks used to own. Snowflake's docs list four Snowflake managed refresh modes, INCREMENTAL, FULL, AUTO, and ADAPTIVE, plus CUSTOM_INCREMENTAL for user defined refresh logic in refresh modes. The first three are familiar. The last two are where pipeline design gets interesting.

Choice	Status or key behavior	Use it when	Cost risk
`INCREMENTAL`	Best practice when fewer than 5 percent of base data changes between refreshes	Append heavy tables, SCD type 1 dedupe, ordinary aggregates	Fails at create time if the query cannot incrementalize
`ADAPTIVE`	Public preview, available to all accounts	Mostly incremental tables with occasional `INSERT OVERWRITE` or bulk updates	Can reinitialize when Snowflake's heuristics say full rebuild is cheaper
`CUSTOM_INCREMENTAL`	Public preview, available to all accounts	MERGE or INSERT logic, soft deletes, accumulators, Stream and Task migration	You own semantics, including nondeterministic MERGE cases

The 5 percent number is a guideline, not a hard switch. Snowflake says incremental refresh is typically best when fewer than five percent of the base table data changes between refreshes, and also states that Dynamic Tables do not automatically switch modes based on that threshold in the refresh mode guide.

ADAPTIVE is the practical compromise for pipelines that are usually append heavy but occasionally get punched by a bulk operation. Snowflake documents ADAPTIVE as a public preview mode that uses incremental refresh by default, then automatically reinitializes when internal heuristics detect that incremental refresh would be significantly more expensive than rebuilding from scratch in refresh modes.

CREATE OR REPLACE DYNAMIC TABLE mart.dt_orders_adaptive
  TARGET_LAG = '10 minutes'
  WAREHOUSE = transform_wh
  INITIALIZATION_WAREHOUSE = init_wh_xl
  REFRESH_MODE = ADAPTIVE
AS
SELECT order_id, customer_id, order_date, amount
FROM raw.orders
WHERE order_status = 'COMPLETED';

CUSTOM_INCREMENTAL is the more opinionated feature. Snowflake's custom incrementalization docs say it is a public preview available to all accounts, requires an explicit column list, and allows only one DML statement inside REFRESH USING in the custom incrementalization guide. That is managed orchestration, not magic. If your old Task ran a stored procedure with three statements and side effects, you still have design work to do.

CREATE OR REPLACE DYNAMIC TABLE mart.dt_customer_status (
  customer_id NUMBER,
  status STRING,
  updated_at TIMESTAMP_NTZ
)
  TARGET_LAG = '5 minutes'
  WAREHOUSE = transform_wh
  REFRESH_MODE = CUSTOM_INCREMENTAL
  REFRESH USING (
    MERGE INTO SELF AS tgt
    USING (
      SELECT customer_id, status, updated_at
      FROM raw.customer_events CHANGES()
      QUALIFY ROW_NUMBER() OVER (
        PARTITION BY customer_id
        ORDER BY updated_at DESC
      ) = 1
    ) AS src
    ON tgt.customer_id = src.customer_id
    WHEN MATCHED THEN UPDATE SET
      status = src.status,
      updated_at = src.updated_at
    WHEN NOT MATCHED THEN INSERT
      (customer_id, status, updated_at)
      VALUES (src.customer_id, src.status, src.updated_at)
  );

This is where the lock-in gets real. A SELECT based Dynamic Table can often be reasoned about as a materialized transformation. A custom incremental table is Snowflake specific DML wrapped in Snowflake managed scheduling. That may be a good trade if it deletes Airflow glue and Task boilerplate. It is a bad trade if your lakehouse strategy depends on moving that logic across engines next quarter.

Where does the bill hide when refresh gets faster?

Faster refresh can lower warehouse time, but the recurring tax is refresh frequency. Snowflake says Cloud Services credits cover metadata operations such as change detection, compilation, and scheduling on every refresh cycle, and each active Dynamic Table incurs that overhead independently in the Dynamic Table cost guide.

The chart below shows the ugly arithmetic for a 200 table pipeline. Snowflake's own example says 200 Dynamic Tables at a 1 minute target lag produce about 288000 change detection checks per day. At 10 minutes, the same simple formula drops to 28800. At 60 minutes, it drops to 4800.

Illustrative: Snowflake documentation states that 200 active Dynamic Tables at a 1 minute target lag generate about 288000 change detection checks per day. The same formula gives 28800 checks at 10 minutes and 4800 checks at 60 minutes. Source: Snowflake documentation. Data Today benchmark.

This is why TARGET_LAG = '1 minute' should require a product reason, not just an engineer with ambition. Snowflake also says Cloud Services credits are billed only when the daily account total exceeds 10 percent of that day's warehouse compute credits, calculated at the account level in UTC, in the cost documentation. Short lags across deep DAGs are how you turn background metadata into a visible line item.

Use a dedicated warehouse while testing. Then prove the usage before you move Dynamic Tables onto shared compute:

SELECT
  warehouse_name,
  ROUND(SUM(credits_used), 2) AS total_credits,
  ROUND(SUM(credits_used_compute), 2) AS compute_credits,
  ROUND(SUM(credits_used_cloud_services), 2) AS cs_credits
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE start_time >= DATEADD('day', -7, CURRENT_TIMESTAMP())
GROUP BY warehouse_name
ORDER BY total_credits DESC;

For Adaptive mode, watch reinitializations directly. Snowflake says reinitializations appear as REFRESH_ACTION = 'REINITIALIZE', with the reason in REINIT_REASON, through DYNAMIC_TABLE_REFRESH_HISTORY in refresh modes.

SELECT
  name,
  state,
  refresh_action,
  reinit_reason,
  query_id,
  data_timestamp
FROM TABLE(INFORMATION_SCHEMA.DYNAMIC_TABLE_REFRESH_HISTORY(
  NAME => 'MART.DT_ORDERS_ADAPTIVE',
  DATA_TIMESTAMP_START => DATEADD('day', -7, CURRENT_TIMESTAMP())
))
ORDER BY data_timestamp DESC;

If that query shows weekly reinitializations on an XL initialization warehouse, your optimization story changed. You may still be saving money compared with slow incremental refresh after bulk rewrites. You just need to budget the rebuilds as a known event, not a spooky warehouse flare.

What should you lock down before teams start creating them?

Dynamic Tables are operational objects. Treat them like pipelines, not like tables someone happened to create in a worksheet. Snowflake's access control guide says creating one requires CREATE DYNAMIC TABLE on the schema, SELECT on referenced base objects, and USAGE on the database, schema, and refresh warehouse in Dynamic Table privileges.

GRANT USAGE ON DATABASE analytics TO ROLE transform_role;
GRANT USAGE ON SCHEMA analytics.mart TO ROLE transform_role;
GRANT USAGE ON WAREHOUSE transform_wh TO ROLE transform_role;
GRANT CREATE DYNAMIC TABLE ON SCHEMA analytics.mart TO ROLE transform_role;
GRANT SELECT ON TABLE raw.orders TO ROLE transform_role;

The owner role is the sleeper risk. Snowflake says the owner role runs background refreshes and must keep USAGE and SELECT on referenced objects, or refreshes fail, in the privileges guide. That means your production owner should be a service role with boring, durable grants. Do not let a project role own a critical mart if that role gets cleaned up after the migration sprint.

Give operators OPERATE, not OWNERSHIP, when they need to suspend, resume, or manually refresh. Give observability users MONITOR, which Snowflake documents as read only access to scheduling state, refresh history, and graph history in Dynamic Table privileges.

GRANT OPERATE ON DYNAMIC TABLE analytics.mart.dt_orders_adaptive
  TO ROLE pipeline_admin_role;

GRANT MONITOR ON FUTURE DYNAMIC TABLES IN SCHEMA analytics.mart
  TO ROLE data_ops_role;

Also decide your retention strategy before you build historical aggregates. Frozen regions let you declare rows that refresh should skip. Snowflake documents BACKFILL FROM as a create time option that copies existing data into a new Dynamic Table without recomputing it, and says it cannot be added later with ALTER in frozen regions and backfill. That is perfect for migrating a years old daily aggregate, as long as you accept that frozen rows are intentionally stale.

CREATE OR REPLACE DYNAMIC TABLE mart.dt_orders_daily
  TARGET_LAG = '1 hour'
  WAREHOUSE = transform_wh
  FROZEN WHERE (order_day < CURRENT_DATE() - 2)
  BACKFILL FROM mart.dt_orders_daily_legacy
AS
SELECT
  DATE_TRUNC('day', order_ts) AS order_day,
  region,
  COUNT(*) AS order_count,
  SUM(amount) AS revenue
FROM raw.orders_enriched
GROUP BY 1, 2;

Storage lifecycle policies are now generally available for Dynamic Tables. Snowflake's May 21, 2026 release note says a policy can delete or archive matching rows on its own schedule, and rows in the expired region are treated as frozen by refresh in the GA release note. That gives you a cleaner pattern for keeping raw or intermediate data short lived while keeping aggregates available.

When should you still use Streams and Tasks instead?

Keep Streams and Tasks when your pipeline is multi statement, procedural, or intentionally outside Dynamic Table semantics. Snowflake's custom incremental docs allow only one DML statement inside REFRESH USING, and they call out that stored procedures, UDTFs, or multi statement transactions need restructuring in the custom incrementalization guide.

Use Dynamic Tables first when the transformation is naturally SQL shaped and freshness is the product requirement. Use Streams and Tasks first when the workflow is a job with side effects: call an external service, write audit records in multiple places, conditionally branch across several tables, or coordinate work that must run exactly once after a non-Snowflake event.

The dbt story is practical but not free. Snowflake documents dynamic_table as a dbt materialization, and says SQL changes to a model trigger CREATE OR REPLACE, which causes reinitialization, while config only changes such as target lag and warehouse can be applied with ALTER when on_configuration_change is set to apply in the dbt integration docs. Translation: dbt plus Dynamic Tables is attractive for model discipline, but casual SELECT edits can become rebuilds.

SHOW DYNAMIC TABLES LIKE 'dt_orders_daily' IN SCHEMA analytics.mart;

Check refresh_mode, warehouse, scheduling_state, target_lag, is_iceberg, and immutable_where. Snowflake documents those fields in SHOW DYNAMIC TABLES, including refresh_mode values for INCREMENTAL, FULL, AUTO, ADAPTIVE, and CUSTOM_INCREMENTAL in the SHOW DYNAMIC TABLES reference. If the metadata does not match your design doc, the bill will follow the metadata.

The sharp edge is no longer expressibility. It is control.

Snowflake closed a real gap. Faster Dynamic Tables on Gen2 warehouses, Adaptive refresh, frozen regions, backfill, dbt support, Iceberg output, and preview custom incrementalization make the feature much harder to dismiss as a prettier materialized view.

The next failure mode is overuse. A one minute lag on 200 tables creates 288000 daily checks. A custom incremental table can hide business semantics inside a Snowflake specific MERGE INTO SELF. A dbt model edit can trigger reinitialization. None of that makes the feature bad. It makes ownership matter.

The right move is boring and effective: pick one production pipeline, pin REFRESH_MODE, use Gen2 compute, set intermediate tables to DOWNSTREAM, split initialization and refresh warehouses, grant MONITOR broadly, and watch DYNAMIC_TABLE_REFRESH_HISTORY for seven days. If the latency drops and the credit curve stays flat, expand. If it does not, you learned before the pipeline became a platform.

Sources

Snowflake Adaptive Compute changes AWS cost models

2026-06-22T00:00:00Z

Snowflake has spent years training data teams to think in warehouse sizes. XS for cheap work. XL for impatient executives. Multi-cluster when the BI crowd arrives at 9:03 a.m. Snowflake Adaptive Compute changes that muscle memory.

The feature is now generally available on AWS, and the important number is 1.2x: Snowflake says Snowflake Adaptive Compute delivered 1.2x better price-performance than Gen2 standard warehouses on its TPC-DS 10TB Concurrency Benchmark in the June 16, 2026 GA announcement. That is useful, but it is also vendor benchmark math. The operational change matters more: Adaptive Warehouses replace fixed warehouse sizing with per-query scheduling and query-based billing, so your FinOps model moves from uptime math toward query attribution.

If you already read our earlier bill-owner framing for Adaptive Compute costs, the GA update narrows the action: AWS customers in six named regions can now run production conversion tests instead of treating this as roadmap theater.

What actually changed in Snowflake Adaptive Compute GA?

Snowflake Adaptive Compute is exposed through Adaptive Warehouses. In Snowflake's docs, Adaptive Warehouses remove the need to manage warehouse size, multi-cluster settings, Query Acceleration Service settings, and suspend or resume policies through the Adaptive Compute guide. That is four knobs gone from the day-to-day operating loop.

You still create a warehouse object. You still grant roles access. You still get warehouse-level chargeback. The difference is that all jobs across Adaptive Warehouses in an account route to a compute pool dedicated to that account, and Snowflake says that pool is separate from standard, interactive, and Snowpark-optimized warehouses in the same Adaptive Compute guide.

The smallest useful DDL is almost rude in its simplicity:

CREATE ADAPTIVE WAREHOUSE finops_adaptive_wh;

That creates an Adaptive Warehouse with Snowflake's defaults: MAX_QUERY_PERFORMANCE_LEVEL = XLARGE and QUERY_THROUGHPUT_MULTIPLIER = 2, according to the Adaptive Warehouse creation docs. Start there before you invent a tuning doctrine.

For a workload that already needs a tighter cap, use the two Adaptive-specific properties explicitly:

CREATE ADAPTIVE WAREHOUSE bi_burst_wh
  WITH MAX_QUERY_PERFORMANCE_LEVEL = LARGE
       QUERY_THROUGHPUT_MULTIPLIER = 4;

MAX_QUERY_PERFORMANCE_LEVEL is an upper bound on per-query performance, expressed as t-shirt sizes from XSMALL through X4LARGE, and Snowflake says it does not map to a specific underlying compute configuration in the performance control docs. QUERY_THROUGHPUT_MULTIPLIER is the concurrency-ish budget, with default 2; setting it to 0 means unlimited throughput subject to available burst capacity in the throughput multiplier docs.

That last detail is the trap door. 0 sounds convenient during a launch. It is also the number that tells Snowflake, effectively, to stop capping burst throughput at the warehouse property level.

Where can you run it, and what is still missing?

Snowflake says Adaptive Compute is generally available on AWS in six regions: US West 2 in Oregon, US East 2 in Ohio, EU West 1 in Ireland, EU Central 1 in Frankfurt, AP Northeast 1 in Tokyo, and AP Southeast 2 in Sydney in the region availability section. That is enough for real enterprise testing, including some cross-region business continuity pairings, but it is still a selective footprint.

The chart below shows the launch footprint by geography: 2 Americas regions, 2 Europe regions, and 2 Asia Pacific regions.

Snowflake lists six GA AWS regions for Adaptive Compute: 2 in the Americas, 2 in Europe, and 2 in Asia Pacific. Source: Snowflake documentation. Data Today benchmark.

There are two hard constraints you should put in the migration ticket. Adaptive Warehouses require Enterprise Edition or higher, and Snowflake lists that limitation in the Adaptive Compute limitations. Snowflake also says conversion to or from X5LARGE and X6LARGE warehouses is unsupported, as are conversions to or from Snowpark-optimized or interactive warehouses in the same limitations section.

Here is the practical comparison for platform owners:

Choice	What you control	Cost evidence	Best production fit
Standard Gen2 warehouse	`WAREHOUSE_SIZE`, generation, multi-cluster, QAS settings	`WAREHOUSE_METERING_HISTORY` for 365 days	Predictable BI or ETL where size policy is already tuned
Adaptive Warehouse	`MAX_QUERY_PERFORMANCE_LEVEL` and `QUERY_THROUGHPUT_MULTIPLIER`	`QUERY_METERING_HISTORY` per query for 365 days	Bursty analytics, mixed BI and ETL, spiky SQL from agents
Interactive or Snowpark-optimized	Specialized warehouse type, separate from Adaptive conversion	Warehouse usage views, but no Adaptive conversion path	Very low latency dashboards or high-memory Snowpark and ML

The right first candidate is a warehouse with lumpy concurrency and high variance in query shape. The wrong first candidate is your weirdest Snowpark memory hog.

How do you convert without breaking running work?

The conversion path is a single property change:

ALTER WAREHOUSE reporting_wh SET WAREHOUSE_TYPE = 'ADAPTIVE';

Snowflake says conversion to Adaptive Warehouse is an online operation: running queries continue on existing compute while new queries use the new warehouse type, and you can convert back with WAREHOUSE_TYPE = 'STANDARD' in the conversion docs. That makes the feature unusually testable for a warehouse change.

There is one billing wrinkle you should schedule around. During conversion, Snowflake says existing queries continue on the old compute while new queries run on the new type, and you are charged for both sets of compute resources until the old queries finish in the same conversion note. Convert a warehouse during a clean window, not while a 3-hour backfill is already crawling through month-end partitions.

After conversion, Snowflake computes values for MAX_QUERY_PERFORMANCE_LEVEL and QUERY_THROUGHPUT_MULTIPLIER from the old configuration, including warehouse size, MAX_CLUSTER_COUNT, QAS scale factor, and warehouse generation in the property behavior docs. That is a migration convenience, not a substitute for measurement.

Check what Snowflake gave you:

SHOW WAREHOUSES LIKE 'REPORTING_WH';

For Adaptive Warehouses, SHOW WAREHOUSES includes MAX_QUERY_PERFORMANCE_LEVEL, QUERY_THROUGHPUT_MULTIPLIER, and DISABLED_REASONS, according to the Adaptive Warehouse metadata docs. Capture those values in the change record. Future you will thank present you, quietly, during the budget review.

How is Snowflake Adaptive Compute billed?

Adaptive Warehouses use query-based billing, where each query cost depends on compute and software resources used, including cluster sizes and extra capacity from features like QAS, according to Snowflake's billing and pricing section. Snowflake also says you are not charged for creating an Adaptive Warehouse and charges start when the first query runs in that same section.

This is the core FinOps shift. Standard warehouses train you to ask, "How long was the warehouse running?" Adaptive asks, "Which query burned the credits?"

Use the new per-query view for the first answer:

SELECT
  query_id,
  user_name,
  role_name,
  query_tag,
  SUM(credits_used) AS credits_used
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_METERING_HISTORY
WHERE warehouse_name = 'REPORTING_WH'
  AND query_start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
GROUP BY ALL
ORDER BY credits_used DESC
LIMIT 20;

QUERY_METERING_HISTORY returns per-query credit usage for Adaptive Warehouse queries over the last 365 days, and Snowflake says the view can lag by up to 1 hour in the Account Usage reference. Each long query can produce multiple rows, one per metering hour, so always SUM(credits_used) before you point fingers.

For showback, keep the old hourly warehouse view in place:

SELECT
  DATE_TRUNC('day', start_time) AS usage_day,
  warehouse_name,
  SUM(credits_used_compute) AS compute_credits,
  SUM(credits_used_cloud_services) AS cloud_services_credits
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE warehouse_name = 'REPORTING_WH'
  AND start_time >= DATEADD(day, -30, CURRENT_DATE())
GROUP BY ALL
ORDER BY usage_day;

WAREHOUSE_METERING_HISTORY returns hourly warehouse credit usage for the last 365 days, and Snowflake documents CREDITS_USED, CREDITS_USED_COMPUTE, and CREDITS_USED_CLOUD_SERVICES in the view reference. For Adaptive Warehouses, Snowflake says QAS usage is included in compute credits and does not appear as a separate credit column in the Adaptive Account Usage section.

The price-performance headline is real enough to test, but too blunt to buy on faith. Snowflake's benchmark says Adaptive Compute is 1.2x better than Gen2 on TPC-DS 10TB concurrency, which normalizes to 1.0 for Gen2 and 1.2 for Adaptive in the chart.

Snowflake reports Adaptive Compute at 1.2x Gen2 price-performance on the TPC-DS 10TB Concurrency Benchmark, with Gen2 normalized to 1.0. Source: Snowflake blog. Data Today benchmark.

A 20 percent benchmark edge can disappear if your workload is dominated by one bad join, a leaky BI extract, or a queue cap you set too low. The feature gives you better instruments. It does not absolve you from running the experiment.

What should you lock down before a rollout?

Treat Adaptive Warehouses like a new spend surface. The permission model is still Snowflake RBAC, which is good news for teams that already separate platform ownership from workload usage.

Grant runtime access narrowly:

GRANT USAGE ON WAREHOUSE reporting_wh TO ROLE analyst_role;
GRANT MONITOR ON WAREHOUSE reporting_wh TO ROLE finops_readonly_role;
GRANT OPERATE ON WAREHOUSE reporting_wh TO ROLE platform_ops_role;

Snowflake says USAGE lets a role execute queries on a warehouse, MONITOR lets a role view current and past queries plus usage statistics, and OPERATE lets a role change warehouse state and abort running queries in the ALTER WAREHOUSE access control docs. Keep MODIFY away from casual owners, because it allows altering warehouse properties.

Then add a resource monitor. Snowflake says a resource monitor can suspend a standard warehouse or disable an Adaptive Warehouse when a credit limit is reached in the resource monitor docs. The word is different because Adaptive Warehouses do not use suspend and resume in the same way.

USE ROLE ACCOUNTADMIN;

CREATE OR REPLACE RESOURCE MONITOR rm_reporting_wh
  WITH CREDIT_QUOTA = 500
  FREQUENCY = MONTHLY
  START_TIMESTAMP = IMMEDIATELY
  TRIGGERS ON 80 PERCENT DO NOTIFY
           ON 100 PERCENT DO SUSPEND_IMMEDIATE;

ALTER WAREHOUSE reporting_wh
  SET RESOURCE_MONITOR = rm_reporting_wh;

Snowflake says only ACCOUNTADMIN can create resource monitors, and only ACCOUNTADMIN can assign warehouses to resource monitors in the resource monitor setup docs. For Adaptive Warehouses, SUSPEND and SUSPEND_IMMEDIATE map to disable behavior, and the warehouse can show STATE = DISABLED with DISABLED_REASONS listing the monitor in the Adaptive resource monitor section.

My rollout rule: one Adaptive Warehouse, one resource monitor, one owner, one week of query tags. If the workload cannot survive that much discipline, it is already too messy for automatic scaling.

When is Adaptive Compute the wrong call?

Use Adaptive for workloads where static sizing is already making you choose between queue pain and idle spend. Snowflake explicitly lists analytical workloads, data loading pipelines, mixed BI and ETL, and workloads with query sizes ranging from XSMALL to XLARGE as good candidates in the when to use guidance.

Avoid it for three cases. First, primarily HTAP workloads should use standard Gen2 warehouses, according to Snowflake's alternative warehouse guidance. Second, very low latency dashboards and applications should look at interactive warehouses. Third, high-memory Snowpark or ML workloads on a single node should look at Snowpark-optimized warehouses.

The most underrated risk is organizational, not technical. Adaptive Compute removes familiar controls, which means the bill owner loses the comfort of a fixed size and gains a stream of per-query charges. That is a better model for agentic SQL and bursty BI, but only if your team already uses QUERY_TAG, knows who owns each role, and reviews ACCOUNT_USAGE before the invoice arrives.

The bet to make now

Do not convert the estate because Snowflake published a 1.2x benchmark. Convert one noisy AWS warehouse because query-level billing gives you a cleaner argument about who caused the spend.

Snowflake Adaptive Compute is strongest where your current tuning ritual is guesswork: the BI warehouse that is too small at 9 a.m., too large at noon, and politically impossible to resize. Start there. If Adaptive turns that mess into measurable per-query economics, keep going. If it only makes the bill harder to explain, roll back with one ALTER WAREHOUSE and enjoy the rare cloud migration with an escape hatch.

Sources

Snowflake Iceberg ADLS writes are finally usable

2026-06-15T00:00:00Z

Azure lakehouse teams just got a less awkward route into Snowflake. Snowflake Iceberg ADLS support is now generally available, which means Snowflake can read and write externally managed Apache Iceberg tables whose files live in Azure Data Lake Storage Gen2. The important number is not a benchmark. It is 1 storage architecture you no longer have to contort: ADLS Gen2 can now stay the physical home for externally managed Iceberg tables while Snowflake does the SQL work.

Snowflake announced the change on June 12, 2026, in its release notes, saying ADLS Gen2 support for Apache Iceberg tables is generally available and works for reading and writing externally managed Iceberg tables on Azure storage. The release also calls out the practical unlock: interoperability with remote catalogs that only use Data Lake Storage, including Unity Catalog hosted on Azure. You can connect through catalog-vended credentials or through an external volume, according to the Snowflake release note.

That sounds like plumbing. It is. But plumbing decides whether your migration plan needs a second copy of the lake.

What changed for Azure Iceberg tables on June 12, 2026?

Before this release, Azure teams using Iceberg with remote catalogs had an uncomfortable split: Snowflake could participate in Iceberg workflows, but ADLS Gen2 was a rough edge if your catalog and storage architecture were already centered on Azure Data Lake Storage. The June 12 release closes that gap for externally managed Iceberg tables on ADLS Gen2, so Snowflake can read and write against tables where the catalog remains external.

The two connection paths matter because they imply different ownership models. With catalog-vended credentials, your REST catalog hands Snowflake temporary access to the table files. Snowflake says this mode is supported for externally managed Iceberg tables that use an Iceberg REST catalog, and the table files must be stored in a single bucket or equivalent storage location per table. If the catalog does not provide an expiration time, Snowflake assumes the credentials expire 60 minutes after receipt, per the catalog-vended credentials documentation.

The vended-credentials shape is usually cleaner for a platform team. The catalog remains the authority for storage access. Snowflake becomes another engine that asks for short-lived credentials. Here is the key bit of syntax:

CREATE CATALOG INTEGRATION azure_uc_rest
  CATALOG_SOURCE = ICEBERG_REST
  TABLE_FORMAT = ICEBERG
  REST_CONFIG = (
    CATALOG_URI = 'https://<catalog-endpoint>'
    ACCESS_DELEGATION_MODE = VENDED_CREDENTIALS
  )
  REST_AUTHENTICATION = (
    TYPE = BEARER
    BEARER_TOKEN = '<token>'
  )
  ENABLED = TRUE
  REFRESH_INTERVAL_SECONDS = 300;

If you use an external volume instead, Snowflake stores a named account-level object that points at your storage location. For ADLS Gen2 interoperability, Snowflake tells you to use the dfs.core.windows.net endpoint, not the Blob endpoint, when you want Snowflake writes to be compatible with remote catalogs that use Data Lake Storage. The STORAGE_BASE_URL must use the azure:// prefix, according to Snowflake's external volume for Azure guide.

CREATE EXTERNAL VOLUME exvol_adls_iceberg
  STORAGE_LOCATIONS = (
    (
      NAME = 'prod-adls-eastus'
      STORAGE_PROVIDER = 'AZURE'
      STORAGE_BASE_URL = 'azure://acct.dfs.core.windows.net/iceberg/'
      AZURE_TENANT_ID = '<tenant-id>'
    )
  )
  ALLOW_WRITES = TRUE;

DESC EXTERNAL VOLUME exvol_adls_iceberg;

SELECT SYSTEM$VERIFY_EXTERNAL_VOLUME('exvol_adls_iceberg');

One vendor-honest footnote: the release note marks ADLS Gen2 support generally available, while the Azure external-volume page still carries a preview callout around Data Lake Storage Gen2 configuration. For a regulated production rollout, treat the June 12 release note as the feature milestone, then confirm your exact account, region, private connectivity, and support posture with Snowflake before you make it the only write path.

How does Snowflake actually write to an externally managed table?

Snowflake writes by linking its table object to the table in your remote Iceberg REST catalog. When you change the table in Snowflake, Snowflake commits the same change to the remote catalog before it updates the table in Snowflake. That commit ordering is the important behavior, because your catalog remains the shared truth for Spark, Databricks, Trino, Snowflake, and whatever engine shows up next quarter.

Snowflake supports two shapes. A catalog-linked database automatically syncs namespaces and tables from the remote catalog. A standard Snowflake database requires the remote table to exist first, then you create a Snowflake Iceberg table object pointing at it. Snowflake's write-support docs say catalog-linked databases can create new Iceberg tables in Snowflake and in the external catalog at the same time, while standard databases need the table created in the remote catalog first via the externally managed write workflow.

For an Azure Unity Catalog style setup, the catalog-linked database is the more natural interface. It gives Snowflake a database view over a remote catalog, with automatic discovery every 30 seconds by default.

CREATE DATABASE lakehouse_prod
  LINKED_CATALOG = (
    CATALOG = 'azure_uc_rest',
    ALLOWED_NAMESPACES = ('gold', 'silver'),
    ALLOWED_WRITE_OPERATIONS = ALL,
    SYNC_INTERVAL_SECONDS = 300
  )
  CATALOG_CASE_SENSITIVITY = CASE_INSENSITIVE;

The setting you should stare at is ALLOWED_WRITE_OPERATIONS. Snowflake's catalog-linked database syntax makes it ALL by default. That is convenient in a demo and too generous for most enterprises. When writes are enabled, table drops propagate to the remote catalog and remove the table and data from both systems, according to the CREATE DATABASE catalog-linked reference.

A safer rollout starts read-only, then opens writes namespace by namespace:

CREATE DATABASE lakehouse_ro
  LINKED_CATALOG = (
    CATALOG = 'azure_uc_rest',
    ALLOWED_NAMESPACES = ('gold'),
    ALLOWED_WRITE_OPERATIONS = NONE,
    SYNC_INTERVAL_SECONDS = 900
  );

Once writable, Snowflake supports the familiar DML surface: INSERT, UPDATE, DELETE, MERGE, TRUNCATE TABLE, and COPY INTO <table>. It also supports streams for CDC into an externally managed Iceberg table. That is where this feature stops being a catalog checkbox and starts becoming a pipeline primitive.

MERGE INTO lakehouse_prod.gold.customer_iceberg t
USING staging_customer_delta s
  ON t.customer_id = s.customer_id
WHEN MATCHED THEN UPDATE SET t.status = s.status
WHEN NOT MATCHED THEN INSERT (customer_id, status)
  VALUES (s.customer_id, s.status);

If your source is an externally managed Iceberg table, Snowflake requires INSERT_ONLY = TRUE when you create the stream. That constraint is easy to miss during a CDC migration, and it is exactly the kind of small syntax rule that turns a Friday cutover into a Monday incident.

How will this show up on the Snowflake bill?

There is no new magic meter called ADLS. The bill lands in the places Snowflake already uses for Iceberg: virtual warehouse compute, cloud services, automated refresh and data registration, and possibly external Azure storage or egress from your cloud provider.

Snowflake's Iceberg billing docs say Snowflake bills virtual warehouse compute and cloud services when you work with Iceberg tables, and does not bill your account for Iceberg table storage because the files live in your cloud storage. Snowflake still exposes ACTIVE_BYTES for Iceberg tables in storage metrics, which is useful for chargeback even though Azure bills the storage, as summarized in the Apache Iceberg tables billing section.

The polling knob is the first FinOps control. REFRESH_INTERVAL_SECONDS on a REST catalog integration supports values from 30 to 86,400 seconds, with 30 seconds as the default. Catalog-linked databases also use a 30 second default sync interval and the same 30 to 86,400 second range. If you set every catalog to poll every 30 seconds because that is the default, you are choosing freshness before you have measured whether the business needs it.

The chart below shows the operating numbers worth putting in your migration runbook: 30 seconds default polling, 86,400 seconds maximum polling, and 10,800 seconds, meaning 180 minutes, as the documented maximum latency for PIPE_USAGE_HISTORY data.

Snowflake documents 30 seconds as the default polling interval, 86,400 seconds as the maximum polling interval, and 10,800 seconds, or 180 minutes, as the Account Usage latency ceiling for PIPE_USAGE_HISTORY.

Use the Account Usage views immediately. PIPE_USAGE_HISTORY tracks credits used for Iceberg automated refresh for the last 365 days, and Snowflake says the view can lag by up to 180 minutes. It also states that Snowflake does not bill Snowpipe file charges for Iceberg automated refresh, which keeps the charge model cleaner than external-table notification billing.

SELECT
  pipe_name,
  DATE_TRUNC('day', start_time) AS usage_day,
  SUM(credits_used) AS refresh_credits
FROM snowflake.account_usage.pipe_usage_history
WHERE start_time >= DATEADD('day', -14, CURRENT_TIMESTAMP())
  AND pipe_name ILIKE '%customer_iceberg%'
GROUP BY 1, 2
ORDER BY 2 DESC, 3 DESC;

Catalog-linked databases have their own view. CATALOG_LINKED_DATABASE_USAGE_HISTORY keeps 12 months of usage and splits CREDITS_USED_COMPUTE, CREDITS_USED_CLOUD_SERVICES, and CREDITS_USED. Snowflake says table creation uses compute through auto refresh, while automatic table discovery, schema creation or deletion, and table deletion use cloud services.

SELECT
  database_name,
  DATE_TRUNC('day', start_time) AS usage_day,
  SUM(credits_used_compute) AS compute_credits,
  SUM(credits_used_cloud_services) AS cloud_services_credits,
  SUM(credits_used) AS billed_credits
FROM snowflake.account_usage.catalog_linked_database_usage_history
WHERE start_time >= DATEADD('day', -30, CURRENT_TIMESTAMP())
GROUP BY 1, 2
ORDER BY 2 DESC, 5 DESC;

Choice	Concrete behavior	Cost or control signal
Catalog-vended credentials	No `EXTERNAL_VOLUME` parameter on the table when the catalog integration uses `VENDED_CREDENTIALS`	Credential expiration must be supplied by the catalog, otherwise Snowflake assumes 60 minutes
External volume on ADLS Gen2	Use `azure://account.dfs.core.windows.net/container/` for Data Lake Storage	Needs `CREATE EXTERNAL VOLUME` at account level and Azure storage permissions
Catalog-linked database	Sync interval defaults to 30 seconds and can rise to 86,400 seconds	Track spend in `CATALOG_LINKED_DATABASE_USAGE_HISTORY`
Automated refresh	Credits appear through the Snowpipe usage view	`PIPE_USAGE_HISTORY` can lag by up to 180 minutes

This is the same discipline behind Snowflake warehouse sizing: do not start with the biggest knob and call it architecture.

What should an Azure platform team do first?

Start with a read-only mirror of the catalog. Use ALLOWED_NAMESPACES so Snowflake does not discover your entire lake on day 1, set ALLOWED_WRITE_OPERATIONS = NONE, and choose a sync interval that matches the table's change rate. For most BI and model-feature tables, 300 or 900 seconds is a saner starting point than 30 seconds.

Then give access through database roles inside the catalog-linked database. Snowflake says catalog-linked databases support database roles, masking policies, and tags, but do not sync remote catalog access control for users or roles. Translation: your Snowflake RBAC model remains your problem. If your governance design assumes Unity Catalog permissions magically follow the data into Snowflake, fix that assumption before the pilot.

CREATE DATABASE ROLE lakehouse_prod.readers;

GRANT USAGE ON SCHEMA lakehouse_prod.gold
  TO DATABASE ROLE lakehouse_prod.readers;

GRANT SELECT ON ALL ICEBERG TABLES IN SCHEMA lakehouse_prod.gold
  TO DATABASE ROLE lakehouse_prod.readers;

GRANT DATABASE ROLE lakehouse_prod.readers TO ROLE analyst_ro;

For writes, create a separate role and keep table drops out of casual hands. The dangerous part is not MERGE. The dangerous part is a writable linked catalog where DROP ICEBERG TABLE is allowed and the remote catalog follows orders.

CREATE ROLE iceberg_writer;
GRANT USAGE ON DATABASE lakehouse_prod TO ROLE iceberg_writer;
GRANT USAGE ON SCHEMA lakehouse_prod.silver TO ROLE iceberg_writer;
GRANT INSERT, UPDATE, DELETE ON ALL ICEBERG TABLES IN SCHEMA lakehouse_prod.silver
  TO ROLE iceberg_writer;

Also test the limits before you promise a platform standard. Snowflake lists several unsupported or constrained areas for externally managed writes: multi-statement transactions are not supported, Azure server-side encryption for Azure external volumes is not supported for this write path, uuid and fixed(L) writes are not supported, sharing with a listing is not supported, and equality delete files are not supported. Snowflake supports Iceberg version 2 and version 3 for externally managed writes, which is good, but it does not remove the need for table-maintenance ownership.

If you are still deciding whether to make Iceberg your Snowflake boundary, read our guide on whether to put your data lake in Snowflake Iceberg tables before you let a single GA badge settle the architecture.

When is Snowflake Iceberg ADLS the wrong choice?

Do not use it to avoid making a warehouse decision. If all consumers are in Snowflake, standard Snowflake tables or Snowflake-managed Iceberg tables may still give you simpler operations. Externally managed Iceberg earns its keep when other engines must read or write the same tables, when the catalog is already a platform contract, or when Azure storage ownership is politically and financially fixed.

Do not use it as a dumping ground for every namespace. The default 30 second discovery and refresh posture is fine for a demo namespace with 12 tables. It is a different animal when pointed at a busy catalog with hundreds or thousands of tables, frequent commits, and platform teams that only check Account Usage once a month.

Do use it for a narrow Azure migration slice: one remote catalog, two namespaces, 5 to 10 critical tables, explicit SYNC_INTERVAL_SECONDS, read-only first, write role second, and a daily spend query. If that sounds boring, good. Boring is how lakehouse migrations survive contact with finance.

The feature does not make Snowflake the owner of your lake. It makes Snowflake a better citizen in an Azure Iceberg lakehouse. That is the right level of ambition.

Sources

Snowflake Hybrid Tables get faster without request fees

2026-06-15T00:00:00Z

Snowflake Hybrid Tables used to sit in an awkward box: promising enough to simplify app architectures, but not quite boring enough for the team that gets paged when an OLTP-ish workload misbehaves inside a warehouse. The new Snowflake Hybrid Tables update changes that calculus, at least for a specific class of workloads: repetitive point reads and small writes that look more like application state than BI.

The headline is simple: Snowflake says its public preview operational query optimization can deliver up to 8x better throughput on a Gen2 warehouse for a 100 percent read Yahoo Cloud Serving Benchmark workload, while the March 2026 billing change removed separate hybrid table request credits. That combination matters more than either claim alone. Faster point lookups are nice. Faster point lookups without a separate request meter are the part your FinOps reviewer will notice.

This is not Snowflake turning into Postgres. Hybrid Tables are still Snowflake tables, with Snowflake constraints, warehouses, account usage views, and Snowflake lock-in. But for workflow state, metadata, recommendation serving, entitlements, and agent state where the alternative is another database plus another sync pipeline, the feature deserves a fresh benchmark.

What changed in Snowflake Hybrid Tables, exactly?

Snowflake shipped three related changes around Hybrid Tables: a preview optimization for operational queries, optimized bulk loading, and simplified pricing. The operational query work is the most important technical change. Snowflake describes operational queries as hybrid table statements that select or modify a small number of rows and execute in less than 100 ms, and says the optimization applies when the same SQL structure runs repeatedly, the query touches only hybrid tables, and the result is no larger than 100 KB in the operational query optimization docs.

Enablement is warehouse-level, not table-level. That is the right shape. You can isolate a benchmark warehouse, turn the preview on, and avoid changing application DDL while you measure.

CREATE OR REPLACE WAREHOUSE ht_app_wh
  WAREHOUSE_SIZE = XSMALL
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE;

ALTER WAREHOUSE ht_app_wh
  SET ENABLE_USE_STABLE_PATH = TRUE;

The feature is still a preview as of June 15, 2026, and that is not a footnote. Snowflake says cloud services compute incurred for queries on the optimized path is not currently billed, but that this will change when the feature reaches general availability. If you benchmark now and ship a production design on preview economics, write that assumption down in your cost model in red ink.

The chart below shows the reported relative gains Snowflake published for the update. The clean read: operational point lookup throughput is the flagship number, while bulk load improvements are the practical unlock for backfills and state syncs.

Snowflake reported up to 8x point lookup throughput, 10x faster bulk loads, and 10x lower bulk load cost for Hybrid Tables in internal benchmarks.

Snowflake reports 8x better point lookup throughput in the YCSB read benchmark, and 10x faster bulk loads at 10x lower cost for a 50 GB load into Hybrid Tables in its June 10, 2026 blog post, Hybrid Tables Just Got Up to 8x Faster. Treat those as vendor benchmarks, not a substitute for your own concurrency test.

Bulk loading also got more useful. Snowflake says optimized bulk loading supports CTAS, COPY, and all variants of INSERT except INSERT ALL, including loads into tables that already contain data, in the Hybrid Tables best practices guide. That is the difference between a feature you can demo and a feature you can backfill on a Tuesday.

CREATE OR REPLACE HYBRID TABLE app_state (
  entity_id NUMBER NOT NULL,
  state_version NUMBER NOT NULL,
  status VARCHAR NOT NULL,
  payload VARIANT,
  updated_at TIMESTAMP_NTZ NOT NULL,
  PRIMARY KEY (entity_id)
);

INSERT INTO app_state
SELECT entity_id, state_version, status, payload, updated_at
FROM staging_app_state;

There is one catch in that CTAS path. Hybrid Tables require an explicit primary key, and Snowflake says CTAS for a hybrid table cannot infer the schema from the SELECT. If you need foreign keys, Snowflake says CTAS does not support them, so use COPY or INSERT INTO SELECT instead.

How does the optimized path actually decide what to accelerate?

The preview is not a magic turbo button for any query that mentions a Hybrid Table. Snowflake says optimization is limited to statements that interact only with hybrid tables. If you join a Hybrid Table to a standard Snowflake table, the query still works, but it does not get this optimization.

The sweet spot looks like application code with stable prepared statements:

SELECT status, payload, updated_at
FROM app_state
WHERE entity_id = ?;

That question mark matters. Snowflake says parameterized statements with the same structure but different bind values are eligible after repeated execution. If your application injects random comments, builds bespoke SQL strings for every request, or adds ornamental CTEs to point lookups, you are making the optimizer’s job harder for no prize.

Supported statement patterns include SELECT, INSERT, UPDATE, and DELETE, with WHERE comparisons using operators such as equals, less than, and greater than. ORDER BY with or without LIMIT is eligible. The optimized join patterns are narrower: primary key to primary key joins, foreign key to foreign key joins, and index nested loop joins on a primary key.

That constraint is useful. It tells you what to migrate first.

Workload pattern	Good fit for the preview?	Concrete behavior to check
Point lookup by primary key	Yes	Result must stay at or below 100 KB
Small single-row update	Yes	Preview supports single-statement transactions with AUTOCOMMIT enabled
Join to standard fact table	No	Optimization is limited to queries that touch only Hybrid Tables
GROUP BY over app state	No	GROUP BY works, but does not benefit from the preview optimization
Multi-statement transaction	No for preview	Snowflake documents only single-statement transactions for this preview

For a builder, this means you should not start by moving your analytical model into Hybrid Tables. Start with a hot state table that has a primary key, predictable predicates, and a pile of repeated calls from a service. If you are also testing Gen2 warehouses, read our guide to Gen2 warehouse trade-offs before you compare old and new numbers.

How is it billed now, and what should FinOps watch?

The billing story got much simpler on March 1, 2026. Snowflake’s release note says hybrid table requests are no longer charged as a separate billing category, replacing the old three-part model with two charges: hybrid table storage and virtual warehouse compute in the simplified pricing release note. Snowflake followed on March 16, 2026 by disabling new metering events for hybrid table requests in HYBRID_TABLE_USAGE_HISTORY and METERING_DAILY_HISTORY.

That removes one nasty surprise from the bill. It does not make Hybrid Tables cheap by default.

Hybrid table storage is row-store storage, and Snowflake says it is more expensive than traditional Snowflake storage. The current data copy in columnar object storage is not billed as a separate copy, while historical Time Travel data is billed at standard storage rates in the cost evaluation docs. The Snowflake Service Consumption Table lists region-specific hybrid storage prices, including $0.34 per GB per month for AWS US East at the time of this guide.

Use account usage views before debating architecture in a meeting.

SELECT
  usage_date,
  ROUND(hybrid_table_storage_bytes / POWER(1024, 3), 2) AS hybrid_table_gb,
  ROUND(storage_bytes / POWER(1024, 3), 2) AS total_storage_gb
FROM snowflake.account_usage.storage_usage
ORDER BY usage_date DESC
LIMIT 30;

Warehouse compute is the other meter. Queries against Hybrid Tables run on virtual warehouses, with the same warehouse consumption model as standard table queries. The pricing risk is therefore familiar: a chatty application can keep an X-Small warehouse warm all day, and low-latency settings often mean lower AUTO_SUSPEND values are not enough by themselves.

SELECT
  warehouse_name,
  DATE_TRUNC('day', start_time) AS usage_day,
  SUM(credits_used) AS credits_used
FROM snowflake.account_usage.warehouse_metering_history
WHERE warehouse_name = 'HT_APP_WH'
  AND start_time >= DATEADD('day', -14, CURRENT_TIMESTAMP())
GROUP BY 1, 2
ORDER BY 2 DESC;

Also check that request metering really stopped in your account. Historical rows remain available, so query after the cutoff.

SELECT *
FROM snowflake.account_usage.hybrid_table_usage_history
WHERE start_time >= '2026-03-16'::TIMESTAMP_LTZ
ORDER BY start_time DESC
LIMIT 10;

If that returns new request usage rows after March 16, open a ticket before you ship assumptions into a forecast. If it returns nothing, good. Your cost argument moves to storage footprint, warehouse uptime, and whether the architecture deletes another system.

What limits can still wreck a production rollout?

The most important limit is throughput per database. Snowflake currently documents approximately 16,000 operations per second per Snowflake database for a balanced workload of 80 percent point reads and 20 percent point writes, with throttling visible through AGGREGATE_QUERY_HISTORY in the Hybrid Tables limitations page.

SELECT
  interval_start_time,
  warehouse_name,
  SUM(calls) AS calls,
  SUM(hybrid_table_requests_throttled_count) AS throttled_requests
FROM snowflake.account_usage.aggregate_query_history
WHERE interval_start_time >= DATEADD('hour', -6, CURRENT_TIMESTAMP())
  AND warehouse_name = 'HT_APP_WH'
GROUP BY 1, 2
ORDER BY interval_start_time DESC;

Storage has a hard planning boundary too: Snowflake documents a 2 TB hybrid storage quota per Snowflake database. That limit applies to active hybrid table data in the row store. If you blow through it, writes that add data can be blocked until you remove data or tables. Deleting rows may take hours to reclaim space because background compaction has to run, while DROP or TRUNCATE can reclaim space in seconds.

Region support is another practical gate. Hybrid Tables are generally available in commercial AWS and Microsoft Azure regions, but Snowflake says they are not available in Google Cloud, U.S. SnowGov Regions, or trial accounts. If your enterprise standard is GCP Snowflake, this guide is mostly a future-looking planning note.

There are also feature gaps that matter to data engineers. Hybrid Tables do not support streams, dynamic tables, materialized views, replication, data sharing, Snowpipe, Snowpipe Streaming API, clustering keys, Search Optimization Service, Query Acceleration Service, Fail-safe, or UNDROP for the hybrid tables themselves. That list is not trivia. It tells you Hybrid Tables are an application-serving and state-management tool, not a drop-in replacement for your pipeline substrate.

Constraints are stricter than standard Snowflake tables. A Hybrid Table must have a primary key, and primary key, unique, and foreign key constraints are enforced. That is good for app correctness. It also means bad backfill rows fail instead of quietly becoming tomorrow’s data quality incident.

CREATE OR REPLACE HYBRID TABLE workflow_run (
  run_id NUMBER NOT NULL,
  pipeline_name VARCHAR NOT NULL,
  status VARCHAR NOT NULL,
  started_at TIMESTAMP_NTZ NOT NULL,
  finished_at TIMESTAMP_NTZ,
  PRIMARY KEY (run_id),
  INDEX idx_pipeline_status (pipeline_name, status)
);

Watch index width. Snowflake warns that wide indexed columns can fail during loads because row-based storage imposes a limit on the size of data and metadata stored per record. VARIANT can live in the table, but not as a primary key or indexed column.

Who should try it first, and who should wait?

Try Snowflake Hybrid Tables now if your current architecture has one small operational database whose main job is to sit next to Snowflake and remember things Snowflake already understands: job state, recommendation IDs, customer entitlements, agent checkpoints, application configuration, or workflow status. That external database has a bill, a security model, backups, alerts, schema migrations, and a sync path. Consolidation is a legitimate performance feature when it deletes all of that.

Do not start with your highest-volume customer-facing OLTP system. If the service has strict single-digit millisecond SLOs, multi-region failover requirements, heavy multi-statement transactions, or expects Postgres-compatible behavior, Snowflake is still not pretending to be that database. Good. You should not pretend either.

A sane rollout looks like this:

Pick one table under 100 GB with a primary-key access pattern.
Put it in a dedicated database so the 16,000 ops per second quota is easy to reason about.
Use a dedicated X-Small or multi-cluster warehouse, not your BI warehouse.
Enable ENABLE_USE_STABLE_PATH only on the test warehouse first.
Benchmark with bind variables, warm the workload for a few minutes, and track throttling in AGGREGATE_QUERY_HISTORY.
Compare the full cost against the database and pipeline you can retire, not against warehouse credits alone.

Privileges need attention because Snowflake documentation is in transition. The current command reference lists CREATE TABLE on the schema as the required privilege and notes no separate CREATE HYBRID TABLE privilege, while Snowflake’s 2026_02 behavior change announcement says CREATE HYBRID TABLE becomes a new separate privilege for roles that create new Hybrid Tables in the behavior change note. The safest enterprise move is to grant narrowly and verify bundle behavior in your account.

GRANT USAGE ON DATABASE app_db TO ROLE app_state_owner;
GRANT USAGE ON SCHEMA app_db.state TO ROLE app_state_owner;
GRANT CREATE TABLE ON SCHEMA app_db.state TO ROLE app_state_owner;

GRANT SELECT, INSERT, UPDATE, DELETE
  ON ALL TABLES IN SCHEMA app_db.state
  TO ROLE app_service_role;

If your account requires the new privilege, add it to the owner role and keep it away from broad analyst roles.

GRANT CREATE HYBRID TABLE
  ON SCHEMA app_db.state
  TO ROLE app_state_owner;

The lock-in trade is real. Hybrid Tables make Snowflake more attractive as an application data plane, but they also move operational state into Snowflake-specific DDL, quotas, and observability. That is worth it when the state mostly serves Snowflake-adjacent workflows. It is much harder to justify when Snowflake is just the third system in a request path.

What is the practical call?

Benchmark the workloads you previously rejected because Hybrid Tables were too slow or too weird to bill. The new performance path and request-fee removal are enough to reopen that spreadsheet.

But be precise. This is not a blanket migration story. It is a narrow, useful answer to a common enterprise mess: too many small operational databases orbiting the warehouse like space junk.

If Snowflake Hybrid Tables let you delete one of those databases, they are probably worth the test. If they only let you brag that your warehouse can do OLTP now, congratulations on finding the expensive version of a familiar database.

Sources

ICEBERG_MERGE_ON_READ_BEHAVIOR changes Iceberg DML

2026-06-08T00:00:00Z

Snowflake just turned an Iceberg implementation detail into a bill-owner decision.

ICEBERG_MERGE_ON_READ_BEHAVIOR is the new general availability object parameter that controls whether Snowflake uses merge-on-read or copy-on-write for Iceberg UPDATE, DELETE, and MERGE. The key number is simple: under the default AUTO setting, 3 of 4 table cases use merge-on-read, while Snowflake-managed Iceberg v2 tables stay on copy-on-write unless you explicitly opt in.

That sounds small. It is not. For lakehouse teams, row-level DML is where the open-table dream usually meets the invoice. Copy-on-write rewrites whole data files. Merge-on-read writes delete files alongside the data and makes readers reconcile them later. One mode spends more during writes. The other can push work into reads and compaction. Snowflake's new parameter matters because it lets you choose that trade-off at the account, database, schema, or table level instead of letting it hide behind a legacy boolean.

If you are still sorting out where Iceberg belongs in your platform, start with our guide to putting your data lake in Snowflake Iceberg tables. This one is narrower: how this new switch works, how to audit it, and where it can move credits.

What did Snowflake actually ship for Iceberg DML?

Snowflake added a string parameter, ICEBERG_MERGE_ON_READ_BEHAVIOR, with three values: AUTO, ENABLED, and DISABLED. The 10.20 release notes say the parameter controls how Snowflake performs row-level updates on Apache Iceberg tables, specifically UPDATE, DELETE, and MERGE, by choosing between merge-on-read and copy-on-write in Snowflake-issued DML.

The default is AUTO. In that mode, Snowflake checks two things: the Iceberg format version and whether the table is Snowflake-managed or externally managed. Snowflake-managed v2 tables use copy-on-write. Snowflake-managed v3 tables use merge-on-read. Externally managed v2 and v3 tables use merge-on-read.

That gives you the 3 to 1 split shown below.

Snowflake's AUTO matrix has 3 Iceberg table cases using merge-on-read and 1 case using copy-on-write.

Snowflake's docs spell out the matrix in the row-level deletes guide. The vendor-safe read is obvious: AUTO protects Snowflake-managed v2 tables because external readers might not support v2 positional delete files. The builder read is sharper: if you want merge-on-read on Snowflake-managed v2, you must say so.

Here is the minimum table-level change:

ALTER ICEBERG TABLE lake_db.public.events
  SET ICEBERG_MERGE_ON_READ_BEHAVIOR = 'ENABLED';

And here is the safer default pattern for a database with mixed tables:

ALTER DATABASE lake_db
  SET ICEBERG_MERGE_ON_READ_BEHAVIOR = 'AUTO';

ALTER ICEBERG TABLE lake_db.public.hot_events
  SET ICEBERG_MERGE_ON_READ_BEHAVIOR = 'ENABLED';

ALTER ICEBERG TABLE lake_db.public.reader_sensitive_events
  SET ICEBERG_MERGE_ON_READ_BEHAVIOR = 'DISABLED';

The parameter is case-insensitive, and the most specific setting wins. A table setting beats a schema setting, which beats a database setting, which beats the account setting. Snowflake documents the same syntax on CREATE ICEBERG TABLE, where the parameter defaults to AUTO and can be set when the table is created in Snowflake as the Iceberg catalog.

CREATE ICEBERG TABLE lake_db.public.events (
  event_id STRING,
  event_ts TIMESTAMP_NTZ,
  customer_id STRING
)
  CATALOG = 'SNOWFLAKE'
  EXTERNAL_VOLUME = 'lake_volume'
  BASE_LOCATION = 'events'
  ICEBERG_VERSION = 3
  ICEBERG_MERGE_ON_READ_BEHAVIOR = 'AUTO';

The gotcha is scope. ICEBERG_MERGE_ON_READ_BEHAVIOR only controls writes that Snowflake performs. If Spark, Flink, Trino, or another engine writes the same Iceberg table, that engine uses Iceberg table properties such as write.delete.mode, write.update.mode, and write.merge.mode. Snowflake says it does not use those properties to choose the Snowflake write method.

How does AUTO decide between merge-on-read and copy-on-write?

The new setting is really a compatibility switch disguised as a performance knob.

Table case	AUTO behavior	File type Snowflake may write	Why you should care
Snowflake-managed Iceberg v2	Copy-on-write	Rewritten data files	Safest for readers that do not handle positional deletes
Snowflake-managed Iceberg v3	Merge-on-read	Deletion vectors when conditions are met	Better fit for frequent row-level changes
Externally managed Iceberg v2	Merge-on-read	Positional delete files	Snowflake follows an external-lake pattern
Externally managed Iceberg v3	Merge-on-read	Deletion vectors when conditions are met	The cleanest path if every engine supports v3

Do not read ENABLED as a promise that Snowflake will always write only delete files. Even when the setting resolves to merge-on-read, Snowflake still applies per-file heuristics. The docs say Snowflake writes a deletion vector only if fewer than approximately 5 percent of rows in a data file are deleted, and only when the file is larger than about 1.6 MB. If at least 5 percent of rows are deleted, Snowflake rewrites the file with copy-on-write.

That is good engineering. A delete file for half a file is not clever. It is a future read tax with a tiny hat.

The practical test is simple. If your workload deletes or updates a small share of rows across large files, merge-on-read can save write work. If your workload regularly rewrites large chunks of a partition, copy-on-write may be simpler and faster for downstream reads.

You can inspect the effective parameter before changing anything:

SHOW PARAMETERS LIKE 'ICEBERG_MERGE_ON_READ_BEHAVIOR'
  IN TABLE lake_db.public.events;

And you can reset a table override back to inherited behavior:

ALTER ICEBERG TABLE lake_db.public.events
  UNSET ICEBERG_MERGE_ON_READ_BEHAVIOR;

This matters during migrations. The old boolean ENABLE_ICEBERG_MERGE_ON_READ is deprecated. Snowflake says existing legacy settings are still honored when the new parameter is at AUTO, but the legacy setting is ignored when the new parameter is explicitly ENABLED or DISABLED in the new migration guidance.

-- Before
ALTER ICEBERG TABLE lake_db.public.events
  SET ENABLE_ICEBERG_MERGE_ON_READ = TRUE;

-- After
ALTER ICEBERG TABLE lake_db.public.events
  UNSET ENABLE_ICEBERG_MERGE_ON_READ;

ALTER ICEBERG TABLE lake_db.public.events
  SET ICEBERG_MERGE_ON_READ_BEHAVIOR = 'ENABLED';

The non-obvious migration trap is Snowflake-managed v2. Setting the legacy boolean to TRUE does not force merge-on-read there when the new parameter is still AUTO. To force that case, use the new parameter explicitly.

Where can this move your Snowflake bill?

The parameter itself is not a new metered service. The cost shows up through the work it changes: warehouse DML, reader queries, storage optimization, and sometimes external storage requests.

For Snowflake-issued DML, your warehouse still pays for the UPDATE, DELETE, or MERGE. Snowflake's compute cost docs state that virtual warehouses consume credits while executing queries, loading data, and performing other DML operations in warehouse compute. Merge-on-read can reduce the amount of data rewritten during a small update, but it may add work later when readers have to merge delete files with data files.

Start by measuring DML shape, not arguing about lakehouse philosophy in a meeting room.

SELECT
  query_id,
  warehouse_name,
  query_type,
  rows_updated,
  rows_deleted,
  total_elapsed_time / 1000 AS seconds
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
  AND query_type IN ('UPDATE', 'DELETE', 'MERGE')
  AND query_text ILIKE '%lake_db.public.events%'
ORDER BY start_time DESC;

QUERY_HISTORY keeps 365 days of query data and includes rows_updated and rows_deleted, according to Snowflake's Account Usage reference. Pair that with warehouse metering if you need dollar allocation, but do not pretend one query history row gives perfect per-table cost attribution in a shared warehouse.

The second cost surface is compaction. Merge-on-read creates read-side debt. You pay it down by compacting files and cleaning up delete files. Snowflake's Iceberg management docs say table optimization features include data compaction, manifest compaction, and snapshot expiry. Data compaction is enabled by default for Snowflake-managed Iceberg tables, and Snowflake exposes billed compaction credits in ICEBERG_STORAGE_OPTIMIZATION_HISTORY.

SELECT
  database_name,
  schema_name,
  table_name,
  SUM(credits_used) AS compaction_credits,
  SUM(num_bytes_scanned) / POW(1024, 4) AS tib_scanned,
  SUM(num_rows_written) AS rows_compacted
FROM snowflake.account_usage.iceberg_storage_optimization_history
WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP())
GROUP BY 1, 2, 3
ORDER BY compaction_credits DESC;

That view has up to 2 hours of latency and retains 365 days of history, and Snowflake says the CREDITS_USED column reports credits billed for data compaction in the Iceberg storage optimization view. If this number rises after enabling merge-on-read, you did not get a free lunch. You moved work from the DML path into maintenance.

Snowflake storage adds one more wrinkle. For Iceberg tables using Snowflake storage, Snowflake says compaction is bundled with no separate compaction charge while the table is written only by Snowflake; once an external engine performs DML or DDL through the Iceberg REST Catalog on or after May 21, 2026, compaction charges can appear in the same history view in the storage cost documentation. That is the kind of clause that turns a clean architecture diagram into a FinOps ticket.

If external engines read Snowflake storage through Horizon Catalog, watch request counts too:

SELECT
  operation_type,
  SUM(count) AS requests
FROM snowflake.account_usage.storage_request_history
WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP())
GROUP BY 1
ORDER BY requests DESC;

Snowflake says STORAGE_REQUEST_HISTORY tracks Class 1 operations such as PUT, COPY, POST, PATCH, and LIST, plus Class 2 operations such as GET and SELECT, with up to 6 hours of latency in the storage request view. For Snowflake query engine access, that view is not the bill meter. For external engines, it can explain why an open table suddenly feels less open and more metered.

Who should be allowed to flip the switch?

Treat this like a production performance setting, not a casual table option. Snowflake's ALTER ICEBERG TABLE docs say the executing role needs OWNERSHIP on the Iceberg table, plus USAGE on the external volume and catalog integration where applicable in the access control requirements.

That should push you toward a small owner role, not a broad data engineering super-role.

GRANT USAGE ON DATABASE lake_db TO ROLE iceberg_dml_admin;
GRANT USAGE ON SCHEMA lake_db.public TO ROLE iceberg_dml_admin;

GRANT OWNERSHIP ON ICEBERG TABLE lake_db.public.events
  TO ROLE iceberg_dml_admin
  COPY CURRENT GRANTS;

Then make the actual mode changes through reviewed migrations:

USE ROLE iceberg_dml_admin;

ALTER ICEBERG TABLE lake_db.public.events
  SET ICEBERG_MERGE_ON_READ_BEHAVIOR = 'DISABLED';

The governance point is boring because it is correct: table owners can change read/write cost shape for every downstream consumer. If one team optimizes its nightly MERGE and slows a dozen BI reads, you have not optimized the platform. You have moved pain to a group with worse dashboards.

When should you enable merge-on-read, and when should you refuse it?

Use AUTO as the default until you can name a workload that needs something else. It is conservative in exactly one place: Snowflake-managed v2. That is the place where reader compatibility is most likely to bite.

Enable merge-on-read explicitly when three conditions hold:

The table sees frequent UPDATE, DELETE, or MERGE operations that touch a small share of rows per data file.
Your readers support the relevant Iceberg delete mechanism, positional deletes for v2 or deletion vectors for v3.
You are prepared to monitor compaction through ICEBERG_STORAGE_OPTIMIZATION_HISTORY for at least 30 days.

Disable it when reads dominate and latency matters more than DML speed. Also disable it when you share tables with engines that do not support Iceberg v3 deletion vectors or v2 positional delete files. Snowflake explicitly recommends DISABLED for Iceberg v3 deletion vector compatibility gaps, and that advice is worth taking before your lake turns into a support matrix.

For a table with heavy batch replacements, copy-on-write can be the cleaner model. If each run updates 20 percent of a partition, merge-on-read will not save you from rewriting anyway because Snowflake's heuristic flips to copy-on-write at about 5 percent of rows deleted in a file. You might still see delete files for smaller files or smaller touches, but the broad pattern is not a match.

My default rollout would be boring on purpose:

Leave the account at AUTO.
Pick 3 to 5 high-DML Iceberg tables.
Confirm reader compatibility by engine and version.
Set ENABLED only at the table level.
Compare 30 days of DML duration, warehouse credits, read latency, and compaction credits.

That last step is the moat. Anyone can flip a parameter. The team that wins is the one that proves where the work went.

What is the sensible bet?

ICEBERG_MERGE_ON_READ_BEHAVIOR is a good Snowflake feature because it admits the lakehouse truth: open table formats do not remove trade-offs. They expose them.

The right answer is not universal merge-on-read. The right answer is explicit ownership of write speed, read latency, compatibility, and compaction cost at the table boundary. Snowflake has finally given that boundary a named switch.

Use it like a scalpel. Your bill will know if you use it like a broom.

Sources

Snowflake Adaptive Compute: the bill owner playbook

2026-06-08T00:00:00Z

Snowflake has spent years telling you the warehouse is the abstraction. Snowflake Adaptive Compute quietly says the old abstraction still leaked too much. If your team has a spreadsheet full of MEDIUM versus LARGE, max cluster counts, QAS settings, and angry dashboard owners, this feature is aimed directly at you.

Snowflake Adaptive Compute is a new adaptive warehouse model that replaces fixed warehouse sizing with workload-aware compute. The key finding for bill owners is simple: you get 2 primary knobs instead of warehouse size, multi-cluster settings, Query Acceleration Service settings, and suspend policies. That is a real simplification, but it is not a magic cost cutter. It moves the FinOps job from choosing node shapes to setting performance ceilings, throughput caps, and evidence-based guardrails.

Snowflake lists Adaptive Compute as an open preview feature introduced in April 2026, and the docs say adaptive warehouses currently require Enterprise Edition or higher and are available only in 3 AWS regions during public preview: US West 2 (Oregon), EU West 1 (Ireland), and AP Northeast 1 (Tokyo). The official Adaptive Compute documentation is the source of truth here, because early blog posts and preview behavior can drift.

What does Snowflake Adaptive Compute actually change?

Adaptive Compute changes the unit you manage. A standard Snowflake warehouse asks you to pick a size, maybe add multi-cluster scaling, choose a scaling policy, decide whether Query Acceleration Service belongs on that warehouse, and tune suspend behavior. An adaptive warehouse asks you to create a warehouse of type ADAPTIVE and set 2 properties: MAX_QUERY_PERFORMANCE_LEVEL and QUERY_THROUGHPUT_MULTIPLIER.

The simplest valid DDL is intentionally boring:

CREATE ADAPTIVE WAREHOUSE analytics_adaptive_wh;

That creates an adaptive warehouse with Snowflake's documented defaults: MAX_QUERY_PERFORMANCE_LEVEL = XLARGE and QUERY_THROUGHPUT_MULTIPLIER = 2. If you want to make the guardrails explicit, do it at creation time:

CREATE ADAPTIVE WAREHOUSE analytics_adaptive_wh
  WITH MAX_QUERY_PERFORMANCE_LEVEL = LARGE
       QUERY_THROUGHPUT_MULTIPLIER = 3
       STATEMENT_TIMEOUT_IN_SECONDS = 1800;

MAX_QUERY_PERFORMANCE_LEVEL is the per-statement performance ceiling. It accepts 8 values: XSMALL, SMALL, MEDIUM, LARGE, XLARGE, XXLARGE, XXXLARGE, and X4LARGE. Snowflake says this value does not map to a specific underlying compute configuration. Read that twice before you put it in a chargeback deck. XLARGE here is a cap on what the system may use when it has high confidence an optimization helps, not a promise that every query burns XLARGE-style resources.

QUERY_THROUGHPUT_MULTIPLIER is a non-negative integer that controls how much total query work the warehouse can run at once relative to Snowflake's internal baseline for the chosen performance level. The default is 2. A value of 0 means unlimited throughput, which is the sort of setting that should require a change ticket, not a Slack shrug.

Snowflake also supports the standard warehouse syntax if your IaC templates expect CREATE WAREHOUSE:

CREATE WAREHOUSE analytics_adaptive_wh
  WITH WAREHOUSE_TYPE = 'ADAPTIVE'
       MAX_QUERY_PERFORMANCE_LEVEL = LARGE
       QUERY_THROUGHPUT_MULTIPLIER = 3;

Here is the practical translation for an engineer who owns both latency and credits:

Decision you used to make	Standard or Gen2 warehouse	Adaptive warehouse
Size ceiling	`WAREHOUSE_SIZE`, up to `X6LARGE` for standard warehouses	`MAX_QUERY_PERFORMANCE_LEVEL`, 8 levels from `XSMALL` to `X4LARGE`
Burst control	`MIN_CLUSTER_COUNT`, `MAX_CLUSTER_COUNT`, and `SCALING_POLICY`	`QUERY_THROUGHPUT_MULTIPLIER`, default `2`, `0` for unlimited
Query Acceleration Service	Separate feature behavior and metering	Included in adaptive compute credits, no separate QAS credit column
Idle billing behavior	Virtual warehouses consume credits while running, with documented minimums	Adaptive charges begin when queries run
Main permission to change settings	`MODIFY` on the warehouse	`MODIFY` on the warehouse

That table is why this is a FinOps story. Adaptive Compute removes several places where humans make bad sizing calls. It also removes several places where humans used to understand the bill through familiar warehouse-hour math.

How is an adaptive warehouse billed?

Adaptive warehouses use query-based billing. Snowflake's docs say you are not charged for creating an adaptive warehouse, and charges start when the first query runs. The Snowflake Service Consumption Table, effective June 4, 2026, says Adaptive Compute Services consume Platform Credits when queries run on an adaptive warehouse, with consumption scaling based on factors such as compute usage, software optimizations, and active queries.

The important operational shift is this: there is no fixed credits-per-hour table for Adaptive Compute like the standard XS to 6XL table. For standard warehouses, Snowflake publishes familiar hourly credit rates. For Adaptive Compute, the rate depends on what the query actually uses under the customer-provided settings.

That makes the old mental model less useful. You can no longer say, "this team ran a Large for 4 hours, so we know the upper bound." You need to measure the actual adaptive warehouse and per-query usage.

For warehouse-level showback, keep using SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY:

SELECT
  start_time::DATE AS usage_date,
  warehouse_name,
  SUM(credits_used) AS credits_used
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE warehouse_name = 'ANALYTICS_ADAPTIVE_WH'
  AND start_time >= DATEADD(day, -7, CURRENT_DATE())
GROUP BY 1, 2
ORDER BY 1;

For adaptive per-query credit usage, the newer view is the one to watch. Snowflake's QUERY_METERING_HISTORY documentation says the view returns per-query credit usage for adaptive warehouses over the last 365 days, may lag by up to 1 hour, and can emit multiple rows for a query that spans multiple metering hours.

SELECT
  query_id,
  user_name,
  role_name,
  query_tag,
  SUM(credits_used) AS credits_used,
  SUM(credits_used_compute) AS compute_credits,
  SUM(credits_used_cloud_services) AS cloud_services_credits
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_METERING_HISTORY
WHERE warehouse_name = 'ANALYTICS_ADAPTIVE_WH'
  AND query_start_time >= DATEADD(day, -7, CURRENT_DATE())
GROUP BY 1, 2, 3, 4
ORDER BY credits_used DESC
LIMIT 50;

That query should be in your migration runbook before the first production conversion. If it is not, you are not testing Adaptive Compute. You are donating a workload to a preview.

Snowflake's June 2, 2026 performance blog claims Adaptive Compute delivered up to 1.6x faster analytical workloads, 2.2x higher throughput for highly concurrent operational analytics, and 3.5x faster execution for DML-heavy workloads in benchmarks measured in May 2026. Treat those as vendor benchmark claims, not your committed savings plan. The chart below shows the claims you should try to reproduce on your own workload before raising throughput caps.

Snowflake reports Adaptive Compute benchmark claims of up to 1.6x faster analytical workloads, 2.2x higher throughput for highly concurrent operational analytics, and 3.5x faster DML-heavy execution.

The sharp read: if your current waste comes from idle warehouses, bad suspend settings, or forgotten dev clusters, Adaptive Compute can help by changing the billing shape. If your current waste comes from expensive SQL, bad clustering, runaway BI extracts, or unlimited concurrency, Adaptive Compute can make that waste finish faster.

How do you convert without breaking workloads?

Snowflake says converting to or from an adaptive warehouse is an online operation and does not interrupt running queries. Existing queries continue on the old compute resources while new queries use the new warehouse type. During that overlap, Snowflake says you are charged for both sets of compute resources. That overlap detail is easy to miss and painful to explain after a batch window.

The conversion syntax is one line:

ALTER WAREHOUSE finance_wh SET WAREHOUSE_TYPE = 'ADAPTIVE';

Snowflake derives adaptive property values from the existing warehouse configuration, including warehouse size, MAX_CLUSTER_COUNT, QAS scale factor, and warehouse generation. That is useful for first migration. It is not a substitute for review. After conversion, inspect the result:

SHOW WAREHOUSES LIKE 'FINANCE_WH';

For a safer pilot, convert one warehouse that has clean query tags, stable consumers, and a known weekly pattern. A messy shared warehouse called REPORTING_WH used by 19 tools is a lousy first candidate. If you need a refresher on the old sizing model you are leaving behind, our Snowflake Gen2 warehouse guide covers the fixed-size trade-offs Adaptive Compute is trying to retire.

You can tune the adaptive properties after conversion:

ALTER WAREHOUSE finance_wh SET
  MAX_QUERY_PERFORMANCE_LEVEL = LARGE
  QUERY_THROUGHPUT_MULTIPLIER = 2;

If the pilot goes badly, convert back:

ALTER WAREHOUSE finance_wh SET WAREHOUSE_TYPE = 'STANDARD';

Do not bulk convert until you have 2 weeks of before and after evidence. Snowflake provides SYSTEM$BULK_UPDATE_WH, including a dry-run mode, but the existence of a bulk function is not an argument for using it on Monday morning.

SELECT SYSTEM$BULK_UPDATE_WH(
  'WAREHOUSE_TYPE',
  'ADAPTIVE',
  '{"WAREHOUSE_TYPE": "STANDARD"}',
  'DRY_RUN'
);

When the dry run matches exactly what you expect, and only then, use ACTIVE:

SELECT SYSTEM$BULK_UPDATE_WH(
  'WAREHOUSE_TYPE',
  'ADAPTIVE',
  '{"WAREHOUSE_TYPE": "STANDARD"}',
  'ACTIVE'
);

Preview limits matter. During public preview, Snowflake says you cannot convert to or from X5LARGE or X6LARGE warehouses, and you cannot convert to or from Snowpark-optimized or interactive warehouses. If you run high-memory Snowpark jobs, do not force them through Adaptive Compute just because the word adaptive sounds modern.

What should you monitor after the switch?

Start with queuing. QUERY_THROUGHPUT_MULTIPLIER is an admission-control lever, so WAREHOUSE_LOAD_HISTORY should be in the first dashboard. If queued overload time rises after migration, you probably set the multiplier too low for the workload's peak shape.

SELECT
  start_time,
  warehouse_name,
  avg_running,
  avg_queued_load,
  avg_queued_provisioning
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_LOAD_HISTORY
WHERE warehouse_name = 'ANALYTICS_ADAPTIVE_WH'
  AND start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
ORDER BY start_time;

Then compare latency and queuing by query tag. This is where teams with sloppy tagging pay the tax. If your dbt jobs, BI dashboards, notebooks, and ad hoc admin queries all share a blank QUERY_TAG, Adaptive Compute will not fix your accountability problem.

SELECT
  query_tag,
  COUNT(*) AS queries,
  AVG(total_elapsed_time) / 1000 AS avg_elapsed_seconds,
  AVG(queued_overload_time) / 1000 AS avg_queue_seconds
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE warehouse_name = 'ANALYTICS_ADAPTIVE_WH'
  AND start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
GROUP BY 1
ORDER BY avg_queue_seconds DESC;

Use the adaptive-specific metering view for credits, and use query history for behavior. The combination tells you whether a setting change bought throughput, masked bad SQL, or simply moved spend around.

One more governance point: separate the people who can use the warehouse from the people who can widen the blast radius. Snowflake's ALTER WAREHOUSE access-control docs list MODIFY, MONITOR, OPERATE, and USAGE as warehouse privileges, and the global MANAGE WAREHOUSES privilege is equivalent to MODIFY, MONITOR, and OPERATE across all warehouses.

GRANT USAGE, MONITOR
  ON WAREHOUSE analytics_adaptive_wh
  TO ROLE analytics_engineer;

GRANT MODIFY
  ON WAREHOUSE analytics_adaptive_wh
  TO ROLE finops_platform_owner;

GRANT OPERATE
  ON WAREHOUSE analytics_adaptive_wh
  TO ROLE platform_operations;

That split matters because QUERY_THROUGHPUT_MULTIPLIER = 0 means unlimited throughput. You do not want every dashboard owner to discover that setting during quarter close.

When is Adaptive Compute the wrong choice?

Adaptive Compute is the wrong first move when you need strict predictability more than managed optimization. If a finance reporting workload runs the same 120 queries every morning with stable concurrency and a well-tuned Gen2 warehouse, Adaptive Compute may add a layer of opacity without enough benefit. The docs explicitly say standard Gen2 warehouses remain the better fit when you need direct control over warehouse size and scaling policy.

It is also the wrong fit for workloads Snowflake calls out elsewhere: primarily HTAP workloads may belong on standard Gen2, very low-latency dashboards and data-backed applications may belong on interactive warehouses, and high-memory Snowpark or machine-learning jobs may belong on Snowpark-optimized warehouses.

The best candidates have variance. Think mixed BI and ETL, ad hoc analytics, data loading pipelines with changing parallelism, and teams that keep overprovisioning because the worst 15 minutes of the day dominate the warehouse setting. If you are already running 12 warehouses mostly to preserve chargeback names and avoid stepping on each other's concurrency, adaptive warehouses let you keep those logical names while routing work into an account-dedicated adaptive pool.

Here is the decision rule: migrate where human sizing decisions are the bottleneck, not where deterministic control is the product requirement.

What would I do before trusting it with production spend?

Run a controlled pilot with a budget, a rollback, and a scoreboard. Pick 1 warehouse, 3 success metrics, and 14 days. The metrics should include credits from WAREHOUSE_METERING_HISTORY, top query costs from QUERY_METERING_HISTORY, and queue behavior from WAREHOUSE_LOAD_HISTORY. If you cannot name the success metric before the migration, the migration is theater.

A practical pilot sequence looks like this:

Capture 14 days of baseline credits, p95 elapsed time, and queued overload time for the standard or Gen2 warehouse.
Convert with ALTER WAREHOUSE ... SET WAREHOUSE_TYPE = 'ADAPTIVE' during a low-risk window.
Keep the default XLARGE and 2 for the first 48 hours unless a resource monitor fires.
Lower MAX_QUERY_PERFORMANCE_LEVEL if a few queries dominate spend without business value.
Raise QUERY_THROUGHPUT_MULTIPLIER only if queueing hurts a named workload.
Roll back if credits rise and the latency gain is not worth it to the business owner.

Adaptive Compute is Snowflake admitting that warehouse tuning became a product surface area of its own. Good. Most data teams have better things to do than debate MEDIUM versus LARGE for the fifth time this quarter. But the bill does not disappear. It just becomes more query-shaped.

The teams that win with Adaptive Compute will not be the teams that turn every knob to maximum. They will be the teams that treat the 2 knobs like production APIs: versioned, monitored, reviewed, and boring on purpose.

Sources

Snowflake warehouse sizing: stop paying for idle compute

2026-06-07T00:00:00Z

If your Snowflake bill jumped last quarter and nobody changed the data, the culprit is almost always compute, and almost always a warehouse that is bigger or busier than the work needs. A Snowflake virtual warehouse is just a cluster you rent by the second, and its size is the single dial that sets how fast credits drain. Get the dial wrong and you either throttle every analyst or you torch budget on idle compute. An XS warehouse burns 1 credit per hour; a 4XL burns 128 for the same wall-clock hour. That is a 128x spread on one setting, and most teams pick it once and never revisit it.

This guide is for the person who owns the warehouse and answers to finance when the credit line spikes. The goal is to size by workload, not by reflex, and to prove the change with numbers you can pull from your own account.

How does warehouse size actually behave?

Snowflake sizes go XS, S, M, L, XL, then 2XL through 6XL. Each step up doubles the compute, and it doubles the credit rate in lockstep. The pricing is not a curve you have to model; it is a clean power of two.

Credits per hour double with every Snowflake warehouse size, from 1 at XS to 128 at 4XL. Source: Snowflake documentation.

The trap is assuming bigger is wasteful and smaller is safe. It is the opposite as often as not. A larger warehouse finishes a heavy query faster, and because billing is per-second after the first 60 seconds, a query that runs in 2 minutes on an L can cost the same as one that crawls for 8 minutes on an S. The size that wins is the smallest one that does not spill to disk and does not queue. Doubling the size only saves money when it more than halves the runtime, which holds for large scans and big joins but breaks for small, serial, or metadata-bound queries.

You can see the difference in the query profile. Two signals tell you a warehouse is too small for the job:

Spilling. When a query runs out of memory it spills to local then remote storage, and remote spill is brutally slow. Any remote spill is a sign to size up.
Queuing. If queries wait for a slot, the warehouse is saturated. That is a concurrency problem, not a size problem, and the fix is different.

What does it cost, and where does it break?

Sizing up fixes spilling. It does nothing for queuing, because a single larger cluster still runs a fixed number of concurrent queries before it starts holding them in a line. The right tool for a crowd of small queries is multi-cluster scaling: keep the size modest and let Snowflake add clusters under concurrency, then retire them when the rush passes. Reach for a bigger size when one query is slow; reach for more clusters when many queries are waiting.

Here is the comparison that matters when you are deciding which lever to pull:

Symptom	Right lever	Wrong lever	Why
One query spills to remote disk	Size up one step	Add clusters	Extra clusters do not give a single query more memory
Many short queries queue at 9am	Multi-cluster (min 1, max 3)	Size up	A bigger single cluster still serializes the crowd
Warehouse runs all day at 5% load	Auto-suspend at 60s	Bigger warehouse	You are paying for idle, not for slow
Nightly batch runs 40 minutes	Size up, measure cost	Leave it on an S	Faster finish can cost the same and frees the window

The most expensive mistake is not the wrong size at all. It is idle time. A warehouse left running with no queries bills every second until it suspends. Set auto-suspend to 60 seconds for interactive warehouses and confirm auto-resume is on so the next query wakes it. The classic 600-second default means each abandoned warehouse quietly bills ten minutes of nothing, over and over.

How do I roll it out without guessing?

Do not size by vibes. Snowflake records every query and every credit in ACCOUNT_USAGE, so you can measure the real distribution before you touch anything. Start by finding your spillers, because those are where sizing up pays for itself:

-- Queries that spilled to remote storage in the last 7 days,
-- ranked by how much they spilled. These are your size-up candidates.
SELECT
    warehouse_name,
    query_id,
    ROUND(bytes_spilled_to_remote_storage / POWER(1024, 3), 1) AS remote_spill_gb,
    ROUND(total_elapsed_time / 1000, 1) AS elapsed_s,
    LEFT(query_text, 80) AS query_preview
FROM snowflake.account_usage.query_history
WHERE start_time > DATEADD('day', -7, CURRENT_TIMESTAMP())
  AND bytes_spilled_to_remote_storage > 0
ORDER BY remote_spill_gb DESC
LIMIT 50;

Then look at the other end: warehouses that bill credits while doing almost nothing. Pair the credit spend from WAREHOUSE_METERING_HISTORY with the query counts from QUERY_HISTORY, and any warehouse with high credits and low query volume is an auto-suspend problem, not a sizing one.

Once you have the data, roll out in three controlled moves:

Set guardrails first. Put a RESOURCE MONITOR on each warehouse with a monthly credit quota and a suspend trigger, so a runaway query or a forgotten session cannot run up an open-ended bill. This is your seatbelt before you start changing sizes.
Change one warehouse, then measure. Resize a single warehouse with ALTER WAREHOUSE ... SET WAREHOUSE_SIZE, leave it for a few days, and compare credits and median runtime against the week before. Changing everything at once means you learn nothing.
Split workloads. Stop running dashboards, ad-hoc analysis, and heavy ELT through one shared warehouse. Give each workload its own warehouse so you can size and monitor them independently, and so a 3XL backfill never starves the analyst running a quick count.

The rollback is trivial, which is why this is safe to try: resizing takes effect on the next query, and you can drop back a size in one statement if the cost does not move the way you expected.

If you run dbt or scheduled ELT, point those at their own warehouse and size it for the heaviest model in the run, not the average. Batch work is exactly where a larger warehouse earns its credits, because it finishes faster and hands the time window back. The rest of the Snowflake guides go deeper on the pipeline and governance side.

The one number to watch

Track credits per active query-hour, not raw credits. Raw credits go up when usage grows, which can be healthy. Credits burned per hour of actual query work is the number that exposes idle warehouses and oversized clusters, and it is the one that drops the day you right-size. Pull it weekly, watch the trend, and let the warehouse that does the least work for the most credits be the first one you fix.

Sources

Dynamic Tables vs Streams and Tasks: which Snowflake pipeline to build

2026-06-07T00:00:00Z

Most Snowflake data teams hit the same fork. You have raw data landing in a table and you need a clean, transformed version that stays current. Do you write the transformation as a declarative Dynamic Table and let Snowflake keep it fresh, or do you wire up a Stream to capture changes and a Task to process them on a schedule you control? Pick wrong and you either fight the orchestration you did not need or hit a freshness wall you did not see coming. The single hard number that settles a lot of these arguments: Dynamic Tables cannot refresh faster than a 60-second target lag. If your SLA is tighter than a minute, that choice is already made for you.

This guide is for the engineer designing a transformation pipeline on Snowflake who wants to stop relitigating the same build-versus-declare debate on every table. We will use real Snowflake behavior, not vibes.

What is each one actually doing?

A Dynamic Table is a materialized result of a SELECT that Snowflake keeps up to date for you. You write the query and a TARGET_LAG, and Snowflake figures out the dependency graph, watches the base tables, and refreshes, incrementally when it can, so readers never see a partial result.

CREATE OR REPLACE DYNAMIC TABLE dt_orders
    TARGET_LAG = '10 minutes'
    WAREHOUSE = transform_wh
    REFRESH_MODE = INCREMENTAL
AS
    SELECT order_id, customer_id, order_date,
           TRIM(UPPER(product_name)) AS product_name,
           quantity * unit_price AS line_total
    FROM raw_orders
    WHERE order_status != 'returned';

That is the whole pipeline. No scheduler, no change-tracking code. Set TARGET_LAG = '10 minutes' and Snowflake tries to keep the table no more than ten minutes behind its source. Chain dynamic tables that read from each other and Snowflake refreshes them in dependency order against a consistent snapshot, which is the part that makes them genuinely pleasant for multi-step transforms.

Streams and Tasks are the imperative alternative. A Stream is a change-tracking cursor over a table: it records the rows inserted, updated, or deleted since you last consumed it. A Task runs a SQL statement (or calls a procedure) on a schedule or when a predecessor finishes. You compose them yourself: a Stream captures what changed, a Task reads the Stream and applies the change with a MERGE. You own the logic, the ordering, and the failure handling.

Illustrative: the lowest practical lag each Snowflake approach reaches. Dynamic Tables and minute-level Tasks both bottom out near 60 seconds; Snowpipe Streaming goes lower; an hourly task sits at 3,600. Source: Snowflake documentation on dynamic tables and tasks.

Which one should I reach for?

The honest answer is that Dynamic Tables are the right default for most analytical transforms now, and Streams and Tasks are the tool you keep for the cases Dynamic Tables cannot express. Snowflake's own rule of thumb is blunt: if your logic fits in a SELECT, it is a candidate for a Dynamic Table.

Reach for Dynamic Tables when the transform is expressible as SQL, you want declarative freshness you tune with one parameter, and a minute or more of lag is fine. This is the bulk of cleaning, joining, and aggregating work.
Reach for Streams and Tasks when you need procedural logic (calling a stored procedure, an external function, branching), sub-minute freshness, or fine control over exactly when and how a change is applied. CDC into a slowly changing dimension with custom merge rules is the classic case.
Reach for Snowpipe Streaming when the requirement is genuinely low-latency ingestion, rows available in seconds, which neither of the above delivers on its own.

A practical gotcha sits inside the freshness column: a Task scheduled "every 1 minute" is not the same as one-minute freshness. The task has to start, the warehouse has to resume if it was suspended, and the merge has to run, so real end-to-end lag is the schedule plus the run time. Snowflake's triggered tasks, which fire when an underlying Stream gets data instead of on a fixed clock, close most of that gap and are usually the better choice than a tight cron when you want responsiveness without polling an empty stream every minute.

Here is the comparison that actually drives the decision:

Dimension	Dynamic Tables	Streams + Tasks
Programming model	Declarative: write a SELECT	Imperative: you orchestrate
Lowest freshness	60-second target lag minimum	Down to ~1 minute on a schedule, faster with triggered tasks
Multi-step pipelines	Auto dependency graph, consistent snapshot	You sequence tasks yourself
Stored procedures / external functions	Not supported in the definition	Fully supported
Failure handling	Managed by Snowflake	Yours to design and monitor
Best fit	Cleaning, joins, aggregations	CDC, custom merge logic, procedural steps

What does it cost, and where does it bite?

Both approaches bill the same underlying things, so cost is rarely the deciding factor, but the shape differs. A Dynamic Table charges warehouse compute for each refresh query, Cloud Services for the dependency tracking and change detection, and storage for the materialized rows plus Time Travel. The trap is target lag: a shorter lag means more frequent refreshes and more scheduling overhead, so setting TARGET_LAG = '1 minute' on a table nobody reads more than hourly just burns credits for freshness no one consumes. Match the lag to how fresh the data genuinely needs to be, and use TARGET_LAG = DOWNSTREAM on intermediate tables so they only refresh when something downstream needs them.

Streams and Tasks bill the warehouse (or serverless compute) for each task run. The classic waste here is a frequent schedule on a Stream that is usually empty: guard every task with WHEN SYSTEM$STREAM_HAS_DATA('my_stream') so it skips the run, and the credits, when nothing changed.

If you run dbt, this maps cleanly: dbt can materialize models as Dynamic Tables, so you get declarative freshness inside your existing project rather than hand-rolling tasks. Point that work at its own warehouse, sized for the heaviest refresh, as covered in the warehouse sizing guide. The other Snowflake guides go deeper on cost monitoring.

The rule that saves the most rework

Start declarative, escalate only when blocked. Build the table as a Dynamic Table with a target lag that matches the real SLA. If you hit something a SELECT cannot express, or you need freshness under a minute, drop that one table down to Streams and Tasks. Choosing imperative orchestration for a whole warehouse of tables you could have declared is the most common way teams sign up for maintenance they never needed.

Sources

Snowflake clustering: when a clustering key actually pays off

2026-06-07T00:00:00Z

When a Snowflake query is slow, the instinct is to size up the warehouse. Sometimes that is right. Often the real problem is that the query is reading the whole table to answer a question about a sliver of it, and no amount of extra compute fixes a full scan, it just pays for it faster. The fix is pruning: getting Snowflake to skip the storage that cannot contain your answer. A clustering key is the main lever you have over how well that pruning works, and on the right table it is the difference between scanning 9,800 micro-partitions and scanning 140.

This guide is for the data engineer who owns a large, slow table and a query profile that says "partitions scanned" is close to "partitions total". The goal is to know when a clustering key earns its credits, and when it just quietly bills you for nothing.

How does Snowflake decide what to skip?

Every Snowflake table is silently split into micro-partitions, contiguous chunks holding 50 to 500 MB of uncompressed data each, stored column by column. For every micro-partition, Snowflake keeps metadata: the min and max value of each column, the distinct count, and more. That metadata is the whole game. When you filter WHERE event_date = '2026-06-01', Snowflake checks each micro-partition's stored range for event_date and skips any whose range cannot contain that date. Per Snowflake's own docs, a query touching 10% of a value range should ideally scan only 10% of the micro-partitions.

Pruning only works when the values you filter on are physically grouped together. Data lands in micro-partitions in roughly the order you load it. If you load by day, rows for one day already sit together and a date filter prunes beautifully for free. If you load in random order, every micro-partition holds a smear of every date, no range can be ruled out, and the query reads everything even though it returns almost nothing.

Illustrative: clustering a large event table on its date column lets a one-day query prune from 9,800 micro-partitions down to 140. Source: Snowflake documentation on micro-partitions and pruning.

A clustering key tells Snowflake to keep the table physically sorted on the columns you actually filter by, so that smear never forms. You can check how good the current grouping is without changing anything:

-- How well is this table clustered on the column you filter by?
-- Lower average_depth = better pruning. A high depth on a big table
-- that you filter by event_date is the signal a clustering key may help.
SELECT SYSTEM$CLUSTERING_INFORMATION('events', '(event_date)');

The number that matters in the result is clustering depth: the average number of overlapping micro-partitions for that column. Depth near 1 means almost no overlap and excellent pruning. A large depth means heavy overlap and wasted scans.

Clustering is not the only pruning lever, and reaching for it reflexively is a mistake. If your slow queries are highly selective point lookups, WHERE customer_id = 12345 against a huge table, the Search Optimization Service often fits better: it builds a separate search-access index that prunes for equality and substring filters without physically reordering the table. It bills its own credits too, so the evaluation discipline is identical, but the two solve different shapes of problem. Clustering wins on range and date filters that scan a contiguous slice; search optimization wins on needle-in-haystack lookups across the whole table.

What does a clustering key cost, and where does it break?

A clustering key is not free, and this is where teams get burned. Once you set one with ALTER TABLE events CLUSTER BY (event_date), Snowflake's automatic clustering service reorganizes micro-partitions in the background to keep the table sorted as new data arrives. That background work is serverless compute, and it bills credits that show up in AUTOMATIC_CLUSTERING_HISTORY, separate from your warehouses. The more the table churns, the more reclustering it triggers, and the more you pay.

That cost profile decides where clustering wins and where it loses money:

Table profile	Clustering key?	Why
Large, filtered by one date/ID column, append-mostly	Yes	Pruning savings dwarf the steady reclustering cost
Small (under a few GB)	No	Snowflake already prunes it well; you would pay to reorder nothing
High-churn, rows updated all over the key	Rarely	Constant reclustering can cost more than the queries save
Filtered by many different columns each query	No	One key cannot serve every filter; pick the dominant one or none

Two rules keep you out of trouble. First, cluster on low-cardinality-to-medium columns you filter on, like a date or a region, not a unique ID with billions of values, because an ultra-high-cardinality key forces near-constant reordering. Second, do not cluster a table that fits in a handful of micro-partitions; Snowflake prunes small tables fine on its own and the service would bill you to sort data that was never the bottleneck.

How do I roll it out without guessing?

Prove the need before you turn anything on, then measure the bill after.

Confirm the table is actually scan-bound. Open the query profile for the slow query and compare "partitions scanned" to "partitions total". If you are scanning most of the table to return a small result, pruning is failing and clustering is a real candidate. If the scan is already small, your problem is elsewhere (a join, spilling, or a missing filter) and a clustering key will not help.
Baseline, then enable on one table. Record the query runtime and the SYSTEM$CLUSTERING_INFORMATION depth. Set the key with ALTER TABLE ... CLUSTER BY, let automatic clustering settle over a day or two, then re-measure both the query and the credits in AUTOMATIC_CLUSTERING_HISTORY.
Compare savings against the reclustering bill. This is the step people skip. If the query got 20x faster and reclustering costs a few credits a day, keep it. If reclustering is burning more than the warehouse time you saved, suspend it with ALTER TABLE ... SUSPEND RECLUSTER or drop the key.

The rollback is clean: ALTER TABLE events DROP CLUSTERING KEY stops the service and leaves the data in place. Nothing breaks, you just stop paying for ordering. Before you reach for a clustering key at all, make sure the warehouse running the query is the right size, because the two levers interact. The warehouse sizing guide covers that side, and the rest of the Snowflake guides go deeper on the query profile.

The number to watch

Track partitions scanned divided by partitions total for your heaviest recurring query. That ratio, not raw runtime, tells you whether pruning is working. When it is high on a big table you filter the same way every day, a clustering key is worth a test. When it is already low, leave the table alone and spend the credits somewhere they move the needle.

Sources

Snowflake Openflow: managed ingestion built on Apache NiFi

2026-06-07T00:00:00Z

Every data team has the same unglamorous problem: getting data in. Change-data-capture from a transactional database, events off a Kafka topic, PDFs from SharePoint, rows from a SaaS API. The usual answer is a patchwork of Fivetran connectors, custom scripts, and a NiFi cluster someone has to babysit. Openflow is Snowflake's bid to own that whole layer: a fully managed integration service, built on Apache NiFi, that moves structured and unstructured data from hundreds of sources into Snowflake with the platform's security and governance baked in. It went generally available across AWS, Azure, and GCP, and the pitch is that ingestion becomes a Snowflake feature instead of a separate system to run.

This guide is for the data engineer who owns the pipelines and is tired of gluing ingestion tools together. What Openflow actually is, the two ways it runs, what it is good at, and the trade-off you are signing up for when you let Snowflake manage the pipe.

What is Openflow, and why build it on NiFi?

Apache NiFi is a battle-tested open-source dataflow tool: you build pipelines on a visual canvas out of processors, small building blocks that read, transform, route, and write data, wired together with connections that buffer and backpressure. It has been the quiet workhorse of enterprise data movement for a decade. Openflow takes that engine, runs it as a managed service, and wires it natively into Snowflake's security model so you are not hand-rolling credentials and network rules.

The headline capability is breadth. Openflow handles structured and unstructured data, in both batch and streaming modes, through hundreds of processors. That unstructured part is the strategically interesting bit: it can pull documents off Google Drive, Box, or SharePoint and land them in Snowflake ready for Cortex to index, which is exactly the feedstock a Cortex Search service or a RAG chatbot needs. The common use cases the docs call out:

Database CDC. Replicate change-data-capture from operational tables into Snowflake for centralized reporting.
Streaming events. Ingest real-time events from Apache Kafka for near real-time analytics.
SaaS connectors. Pull from platforms like LinkedIn Ads into Snowflake for reporting.
Unstructured for AI. Continuously ingest documents from Drive, Box, and SharePoint so you can chat with them through Cortex.

You build a flow by dropping Snowflake and NiFi processors and controller services onto the Openflow canvas, the same mental model as NiFi, with Snowflake handling the runtime underneath.

Where does Openflow actually run?

This is the decision that shapes cost, security, and operational burden, because Openflow ships in two deployment types and they are genuinely different products under one name.

Illustrative: BYOC keeps the data plane in your own VPC for maximum control, while the SPCS deployment trades that for managed simplicity. Source: Snowflake Openflow deployment documentation.

	Snowflake deployment (SPCS)	Bring Your Own Cloud (BYOC)
Where the data plane runs	Inside Snowflake on Snowpark Container Services	In your own cloud VPC
Setup and ops	Simplest, self-contained in Snowflake	You run the data plane, Snowflake runs the control plane
Billing	Compute-pool utilization, by uptime and usage	Your cloud compute, infrastructure, and storage charges
Best for	Teams that want least operational overhead	Sensitive data that must be preprocessed inside your own perimeter

The split maps to a familiar trade-off. The SPCS deployment runs entirely inside Snowflake on a compute pool, so it is the easy button: native security, no infrastructure of your own, billed on the compute pool's uptime. BYOC runs the data-processing engine inside your own VPC while Snowflake manages the control plane, which is what you reach for when sensitive data has to be handled within your own cloud boundary before it ever moves. In both, the control plane that hosts the canvas and APIs is Snowflake-managed; only the data plane location changes.

Authentication is one place Openflow genuinely simplifies life. The default is the Snowflake Managed Token, short-lived credentials that Snowflake rotates for you, so you stop generating, storing, and rotating long-lived key pairs:

-- Openflow needs an account admin to grant the privileges that let a
-- role create deployments and runtimes. Fine-grained RBAC governs the rest.
GRANT CREATE OPENFLOW DATA PLANE INTEGRATION ON ACCOUNT TO ROLE openflow_admin;

In a BYOC deployment the runtime uses workload identity federation, exchanging its cloud identity such as an AWS IAM role for a Snowflake token, so there are still no long-lived secrets to leak.

What does it cost, and what should you watch?

Openflow does not have a single price tag; it inherits the cost shape of wherever it runs. A SPCS deployment bills on compute-pool utilization, meaning the uptime and compute usage of the container pool hosting your runtimes, the same serverless-ish model as anything on Snowpark Container Services. A BYOC deployment bills you directly through your cloud provider for the compute, infrastructure, and storage the data plane consumes, plus whatever Snowflake charges for the managed control plane.

The practical watch items:

Runtimes are where flows execute, and you will have several. Teams typically run multiple runtimes to isolate projects or environments, and each one is compute that costs while it is up. Idle runtimes are idle spend.
Streaming means always-on. A continuous Kafka or CDC flow keeps a runtime warm around the clock, which is a very different cost profile from a nightly batch. Size that into your estimate before you commit a real-time pipeline.
Unstructured ingestion compounds downstream. Landing documents is only step one; embedding and indexing them for Cortex is a second meter. Budget the Cortex Search cost alongside the ingestion cost, not after.

Openflow also brings real security plumbing: fine-grained RBAC, TLS in transit, PrivateLink compatibility, AWS Secrets Manager or HashiCorp Vault integration in BYOC, and Tri-Secret Secure support. That is the part that makes it credible for regulated data, and it is the reason to prefer it over a hand-built NiFi box you now have to secure and patch yourself.

Should you move your ingestion onto Openflow?

Openflow makes the most sense when ingestion is already a real cost center: many sources, a mix of structured and unstructured data, and a NiFi or scripts setup that someone maintains by hand. Consolidating that onto a managed service inside your governance boundary is a genuine simplification, and the unstructured-to-Cortex path is something the bolt-on connectors do not do as cleanly. It is less compelling if you have one or two simple batch loads that COPY INTO or Snowpipe and Dynamic Tables already handle, where adding a NiFi-based service is more machinery than the job needs.

The honest trade-off: Openflow is powerful and broad, but it is still NiFi underneath, which means a real flow-design skillset and runtimes you have to size and watch. It moves the babysitting from your own cluster to a managed service, it does not delete it. For a team drowning in connectors and custom CDC scripts, that is a clear win. For a team with a tidy handful of loads, it is a solution looking for a problem.

The honest read

Openflow is Snowflake pulling the ingestion layer inside its walls, and for enterprises with sprawling, multi-format data movement that is a strong offer: one managed, governed, NiFi-powered service from any source to Snowflake, with a clean path for the unstructured data that feeds AI. The decision that actually matters is SPCS versus BYOC, because that one choice sets your cost model, your security perimeter, and how much you operate yourself. Pick SPCS for least overhead, BYOC for data that must stay in your own cloud, and size your runtimes honestly, especially for streaming. Done right, ingestion stops being a patchwork and becomes a feature. Done lazily, it is just NiFi with a bigger invoice.

Sources

Should you put your data lake in Snowflake Iceberg tables?

2026-06-07T00:00:00Z

The question landing in every enterprise data architecture review right now: do we keep paying Snowflake to store our data, or do we put it in open Apache Iceberg tables and keep one copy that every engine can read? Iceberg is an open table format that adds database features, ACID transactions, schema evolution, hidden partitioning, and time-travel snapshots, on top of plain Parquet files sitting in your own S3, GCS, or Azure storage. Snowflake supports it natively. The headline that makes finance lean in: with an external volume, Iceberg tables incur zero Snowflake storage cost, because your cloud provider bills you for the bytes directly. The headline that should make architects slow down: not all Iceberg tables are equal, and the catalog you choose decides how much of Snowflake you actually get to keep.

This guide is for the data engineer or platform lead weighing a lakehouse move on Snowflake: when Iceberg is the right call, what you give up, and how to avoid the interoperability promise quietly costing you more than it saves.

What problem does Iceberg actually solve?

A standard Snowflake table stores data in Snowflake's proprietary format. It is fast and fully managed, but the data is locked behind Snowflake's engine: Spark, Trino, or Databricks cannot read it without exporting a copy. The moment two teams want two engines on the same data, you are either copying it or paying twice.

Iceberg breaks that lock. The table data lives as Parquet in open cloud storage, and an Iceberg catalog tracks which files make up the current table state. Any Iceberg-aware engine can read it. So the real question is not "Snowflake or open format" but who owns the catalog, because Snowflake supports two very different models and they are not interchangeable.

Snowflake as the catalog (Snowflake-managed): Snowflake owns the metadata pointer, handles maintenance like compaction, and gives you read and write with full platform support. The data still sits in your external volume, so storage stays cheap, but Snowflake behaves almost like it is a native table.
External catalog (AWS Glue, Databricks Unity Catalog, a remote Iceberg REST catalog): another system owns the metadata. Snowflake connects through a catalog integration and gives you limited platform support. Snowflake does not manage the table lifecycle here.

How much of Snowflake do you give up with an external catalog?

This is the trade-off the marketing glosses over, and it is the single most important thing to get right. Going Snowflake-managed keeps nearly the whole platform. Going external-catalog trades platform features for ecosystem neutrality.

Illustrative: a Snowflake-managed Iceberg catalog retains most platform features while an external catalog supports a much smaller subset. Source: Snowflake Iceberg tables documentation, considerations and limitations.

Per Snowflake's own documentation, here is what the catalog choice actually costs you:

Capability	Snowflake-managed catalog	External catalog
Read and write	Full	Full (writes supported via Iceberg REST)
Clustering keys	Supported	Not supported
Replication	Supported	Not supported
Cloning	Supported	Not supported (externally managed)
Standard streams (CDC)	Supported	Insert-only streams only
Lifecycle maintenance (compaction)	Snowflake handles it	You own it in the external engine
Query from other engines	Sync to Snowflake Open Catalog	Native, that is the point

The pattern that follows: if Snowflake is your primary engine and you just want cheap open storage, use Snowflake as the catalog and sync to Open Catalog when another engine needs read access. If a Spark or Databricks platform is the system of record and Snowflake is a guest, use the external catalog and accept that clustering, cloning, and replication are off the table. Snowflake even supports a catalog-linked database that stays in sync with a remote Iceberg REST catalog, including bidirectional access to Databricks Unity Catalog, so the two platforms can share one copy of the data.

What does it really cost, and where does the bill hide?

The storage saving is real but narrower than it sounds. Snowflake bills you for virtual warehouse compute and cloud services whenever you query or maintain Iceberg tables, exactly as it does for native tables. What changes is storage.

Illustrative: with an external volume, Snowflake charges no storage for Iceberg, your cloud provider bills you instead; with Snowflake-managed storage, Snowflake charges storage as normal. Source: Snowflake Iceberg tables billing documentation.

The nuance that catches teams out: storage is free from Snowflake only when you use your own external volume. If you pick the convenience option of EXTERNAL_VOLUME = SNOWFLAKE_MANAGED storage, Snowflake charges for storage just like a normal table, and the headline saving evaporates. And the most common surprise bill is geography. If your Snowflake account and your external volume sit in different regions, every query triggers cross-region egress that your cloud provider charges you for, and Snowflake adds cross-region data-transfer usage on top for managed tables. Keep compute and storage in the same region or that interoperability dream turns into an egress line item.

Two more honest caveats before you migrate a critical table:

No Fail-safe. Iceberg tables on an external volume get no Snowflake Fail-safe recovery. You own data protection and recovery for that storage. For a standard table, Snowflake's seven-day Fail-safe is a safety net you are quietly giving up.
Maintenance is real work. For externally managed tables, you own compaction and cleanup. Excessive position deletes can actually block table creation and refresh, and orphan files from failed writes can make your storage bill drift above what Snowflake reports. This is operational overhead a native table never asked of you.

When is Iceberg the right call, and when is it a trap?

Reach for Iceberg when you have a genuine multi-engine reality or an existing data lake you cannot or will not move into Snowflake. The open format pays off precisely when more than one tool needs the same data and the alternative is copies that drift. Snowflake says it plainly: Iceberg tables are ideal for existing data lakes you choose not to store in Snowflake.

Do not reach for Iceberg when Snowflake is your only engine and you just heard "open format" in a keynote. For a single-engine shop, a Snowflake-managed Iceberg table on an external volume buys you cheaper storage and an exit option, which is a reasonable hedge, but a standard table buys you Fail-safe, zero maintenance, and every feature with no asterisks. The worst outcome is adopting an external catalog for openness you never use, then discovering six months later that you cannot cluster your biggest table or replicate it for disaster recovery.

If cost is the driver, weigh the storage saving against the maintenance time and egress risk before you commit, the same discipline from the warehouse sizing guide: measure the real number, do not assume the cheap-looking option is cheaper once you count everything. The rest of the Snowflake guides cover the compute side that Iceberg does not change.

The decision in one line

Pick the catalog before you pick the format. Snowflake-managed Iceberg gives you open storage with almost the whole platform intact; an external catalog gives you true engine neutrality at the cost of clustering, cloning, replication, and a maintenance burden you now own. Choose external only when a second engine is genuinely the system of record, otherwise you are paying in lost features for an openness you will never spend.

Sources

Snowflake RBAC and masking: lock it down without grinding to a halt

2026-06-07T00:00:00Z

Governance is where a fast-moving Snowflake account quietly turns into a liability. Someone needs access, an admin grants it straight to their user, and a year later nobody can answer who can see the salary table. The fix is not more process, it is using the access model Snowflake actually gives you. Snowflake is role-based: privileges are granted to roles, and roles are granted to users, never privileges to users directly. Get the role design right and you collapse what would be roughly 10,000 individual grants down to a few hundred while making access auditable instead of archaeological.

This guide is for the data engineer or platform owner who has to keep Snowflake both usable and defensible: analysts unblocked, auditors satisfied, and PII not leaking into a dashboard. We will stick to how Snowflake's RBAC and masking actually behave.

Why grant to roles and not users?

In Snowflake, a privilege (say, SELECT on a schema) is granted to a role, and a user gets access by being granted that role. Grant directly to users and the math explodes: fifty users who each need access to two hundred objects is up to ten thousand grants to create, track, and eventually revoke. Miss a few on offboarding and you have a standing audit finding.

Illustrative: a two-layer role hierarchy collapses grant sprawl from roughly 10,000 direct user grants to about 260. Source: Snowflake documentation on access control.

The pattern that scales is a two-layer role hierarchy, which Snowflake's own guidance recommends. Access roles own the privileges on objects: analytics_db_read holds SELECT on the analytics schemas, raw_db_write holds write on the landing zone. Functional roles map to jobs: data_analyst, data_engineer, bi_developer. You grant access roles to functional roles, and functional roles to people. Now a new analyst gets exactly one grant, data_analyst, and inherits everything that role is supposed to see.

-- Access role owns the object privileges.
CREATE ROLE analytics_read;
GRANT USAGE ON DATABASE analytics TO ROLE analytics_read;
GRANT USAGE ON SCHEMA analytics.marts TO ROLE analytics_read;
GRANT SELECT ON ALL TABLES IN SCHEMA analytics.marts TO ROLE analytics_read;

-- Functional role = the job. It inherits the access role.
CREATE ROLE data_analyst;
GRANT ROLE analytics_read TO ROLE data_analyst;

-- People get one grant: the job.
GRANT ROLE data_analyst TO USER jdoe;

Two discipline points keep this clean. Keep ACCOUNTADMIN for break-glass only and run day-to-day administration through SECURITYADMIN and SYSADMIN, because handing out the top role defeats the whole hierarchy. And give every object a deliberate owner role, so OWNERSHIP is not scattered across whoever happened to run the CREATE.

How do I protect specific columns without copying data?

RBAC controls which tables a role can touch. It does not, on its own, hide the ssn column from an analyst who legitimately needs the rest of the row. That is what Dynamic Data Masking is for, and it is the governance feature that earns its keep fastest.

A masking policy is a schema-level object that rewrites a column's value at query time based on the querying role. The data on disk never changes; what a user sees is decided per query.

CREATE MASKING POLICY mask_email AS (val string) RETURNS string ->
    CASE
        WHEN CURRENT_ROLE() IN ('PII_READER', 'SECURITYADMIN') THEN val
        ELSE REGEXP_REPLACE(val, '.+@', '****@')
    END;

ALTER TABLE customers MODIFY COLUMN email SET MASKING POLICY mask_email;

Now PII_READER sees real email addresses and everyone else sees ****@example.com, from the same table, with no copy and no second pipeline. The leverage Snowflake's docs call out: you write the policy once and apply it to thousands of columns, and you can change the policy's logic centrally without reapplying it anywhere. Pair it with tag-based masking, attach the policy to a pii_email tag and tag the columns, and protection follows the data automatically as new tables appear. Row-level filtering has a sibling feature, row access policies, which hides whole rows by role using the same query-time model.

A few realities to plan around:

Dynamic Data Masking is an Enterprise Edition feature. If you are on Standard, it is not available, and that may itself be the reason to upgrade.
A column takes one masking policy at a time. You cannot stack two; decide the policy per column.
Masking interacts with materialized views. Apply policies to the base table columns, not to a materialized view, or you will hit errors.

Where masking gets genuinely powerful is in combination with tags. Define the sensitivity taxonomy once, pii, financial, restricted, attach a masking policy to each tag, and then governance becomes a tagging exercise rather than a per-column chase. Snowflake can also help you find what to tag: sensitive data classification scans columns and proposes semantic categories like email or phone number, so you are not auditing thousands of columns by eye. The pattern that scales is classify, tag, mask-by-tag, because new tables that inherit a tagged column's lineage pick up protection automatically instead of waiting for someone to remember.

How do I roll this out on an account that is already messy?

You rarely get a greenfield account. Retrofit in order, and audit as you go.

See what exists. SHOW GRANTS and the ACCOUNT_USAGE.GRANTS_TO_USERS view expose every direct-to-user grant. That list is your cleanup backlog and, usually, a sobering one.
Stand up the hierarchy alongside the mess. Create the access and functional roles, grant the access roles into them, and move users onto functional roles one team at a time. Nothing breaks for users still on the old grants while you migrate.
Revoke the direct grants last. Once a team is fully on functional roles, strip their direct-to-user grants. Now access is described entirely by which roles a person holds, which is exactly what an auditor wants to see.
Classify and mask the sensitive columns. Tag PII columns, attach masking policies through the tags, and verify with the POLICY_REFERENCES view that every sensitive column is actually covered.

Audit continuously, not at year-end: ACCOUNT_USAGE.POLICY_REFERENCES lists every object a masking policy is set on, and the GRANTS_TO_ROLES view lets you answer "who can read this table" with a query instead of a meeting. The same instinct from the rest of the Snowflake guides applies, measure the real state in ACCOUNT_USAGE rather than trusting the diagram on the wiki.

The test that proves it works

Pick your most sensitive table and ask: can you answer "who can see this column, and what do they see" with a single query? If yes, your RBAC and masking are doing their job. If it takes a meeting and three Slack threads, the access model is living in people's heads instead of in Snowflake, and that gap is exactly what fails an audit.

Sources

Snowflake Gen2 warehouses: faster compute you have to opt into

2026-06-07T00:00:00Z

Snowflake quietly shipped a second generation of its compute engine, and most teams have not noticed they are now paying for the choice. Generation 2 standard warehouses (Gen2) run on faster underlying hardware with software optimizations to delete, update, merge, and table-scan operations, and Snowflake says the majority of queries finish faster as a result. That sounds like a free win, but it is not free: Gen2 bills at a higher credit rate than Gen1, and depending on when and where your account was created, you may have to ask for it explicitly with a SQL clause. The question that decides whether Gen2 helps or hurts your bill: does the speedup beat the rate increase for your workload?

This guide is for the data engineer or FinOps owner who runs the warehouses and signs off on the credit spend. If you have a heavy data-engineering pipeline or a wall of analytics queries, Gen2 is the single most consequential warehouse setting you are probably not thinking about.

What actually changed under the hood?

A Snowflake virtual warehouse is just a cluster of compute that runs your queries, sized from XS up to 6XL, and you pay credits per second it runs. Gen1, the original engine, is what every account has used for years. Gen2 keeps the same sizes and the same per-second model but swaps in faster hardware and engine improvements aimed squarely at the operations that dominate modern pipelines: the DML that rewrites tables and the scans that feed big aggregations.

Illustrative: Gen2 aims to finish the same query faster, the exact gain depends on your workload, so benchmark it. Source: Snowflake Gen2 warehouse documentation.

Snowflake is careful, and you should be too: the exact gain depends on your configuration and workload, and the docs explicitly tell you to test it rather than assume. Gen2 is not available for the two largest sizes, X5LARGE and X6LARGE, and it applies only to standard warehouses, not Snowpark-optimized ones. There is one genuine bonus that ships with it: a new Gen2 warehouse turns on the Query Acceleration Service by default with a scale factor of 2, which lets bursty queries borrow extra serverless compute for the heavy parts.

How do you actually get a Gen2 warehouse?

This is where teams trip, because the default depends on your account's age and region. For new organizations created after the mid-2025 rollout dates in supported regions, standard warehouses now default to Gen2. For everyone else, if you do not specify a generation when you create a warehouse, you still get Gen1. So an older account is almost certainly running Gen1 everywhere and paying Gen1 speeds without realizing there is a switch.

The switch is one clause. The recommended syntax is the GENERATION parameter on CREATE WAREHOUSE:

-- Create a new Gen2 standard warehouse. Without this clause an
-- older account silently gets Gen1.
CREATE OR REPLACE WAREHOUSE etl_wh
  GENERATION = '2'
  WAREHOUSE_SIZE = MEDIUM;

You can flip an existing warehouse in place, running or suspended, with a single ALTER:

-- Convert an existing warehouse to Gen2 without recreating it.
ALTER WAREHOUSE etl_wh SET GENERATION = '2';

One billing gotcha worth knowing before you convert a live warehouse: if you convert it while queries are running, the in-flight queries finish on Gen1 compute while new queries start on Gen2, and you are billed for both sets of compute until the old queries drain. Convert while suspended to avoid the double charge, or convert while running if you care more about zero downtime than a few minutes of overlap. Note also that the GENERATION clause is not in Snowsight yet, so this is a SQL-only change today, and the setting shows up in the resource_constraint column of SHOW WAREHOUSES:

-- Confirm which generation each warehouse is running.
SHOW WAREHOUSES;
-- look at the "resource_constraint" column: STANDARD_GEN_2 means Gen2.

Does Gen2 actually save you money?

This is the only question that matters, and the honest answer is: it depends, so measure. Gen2 finishes faster, which means fewer credit-seconds per query, but it charges a higher credit rate per second than Gen1, with the exact rates published in Snowflake's Service Consumption Table. The maths is a race between two effects.

Factor	Pushes cost down	Pushes cost up
Query runtime	Faster, so fewer seconds billed	-
Credit rate	-	Higher per-second rate than Gen1
Concurrency	More queries done per running hour	-
Auto-suspend gaps	Shorter active windows	-

The break-even logic is simple. If Gen2 cuts your runtime by more than the rate premium, you win. A warehouse running heavy merges and large scans, exactly what Gen2 was tuned for, is the most likely winner. A warehouse running tiny, cheap queries where the bottleneck is not compute may see the rate increase swamp a speedup it barely benefits from. The right move is to A/B it: run a representative workload on a Gen1 and a Gen2 copy, then compare credits in ACCOUNT_USAGE:

-- Compare credits burned per warehouse over the last 7 days.
SELECT warehouse_name,
       SUM(credits_used) AS credits
FROM   snowflake.account_usage.warehouse_metering_history
WHERE  start_time >= DATEADD('day', -7, CURRENT_TIMESTAMP())
GROUP  BY warehouse_name
ORDER  BY credits DESC;

Pair that with QUERY_HISTORY to confirm the runtime actually dropped, not just the credit line. The discipline here is the same one from the warehouse sizing guide: never assume the faster-or-newer option is cheaper until you have the two numbers side by side.

What should you do this week?

If you run an older account, you are almost certainly on Gen1 everywhere and leaving a possible speedup on the table, so this is worth ten minutes. The plan:

Find your heaviest warehouse. The one with the most credits in the query above, usually an ETL or transformation warehouse doing merges and big scans, is the best Gen2 candidate.
Clone the workload, not the prod warehouse. Point a representative job at a GENERATION = '2' copy and a Gen1 copy, same size, and compare credits and runtime over a real day.
Mind replication. If you replicate warehouses across regions, every secondary region must also support Gen2, or a Gen2 warehouse may fail to resume after a failover. Test the failover path before you standardize on Gen2.
Leave tiny, idle warehouses alone. A warehouse that mostly serves cheap dashboard queries will feel the rate increase more than the speedup. Gen2 earns its premium on heavy work.

For the read on Gen2 against the rest of your compute strategy, the other Snowflake guides cover sizing, clustering, and the pipeline patterns that decide how much work a warehouse does in the first place.

The honest read

Gen2 is a real upgrade, not marketing: faster hardware, smarter DML, Query Acceleration on by default. But Snowflake made it an opt-in with a higher rate, which means it is a FinOps decision dressed as a performance feature. The teams that win are the ones that benchmark before they standardize, because for compute-heavy pipelines Gen2 can pay for its premium several times over, and for light, bursty workloads it can quietly raise the bill for a speedup you never needed. Run the two-warehouse test, read the two numbers, then decide. Do not let a default, old or new, make the call for you.

Sources

Cortex Search: the managed RAG engine inside Snowflake

2026-06-07T00:00:00Z

Every team building a chatbot on their own data hits the same wall: retrieval. The large language model is the easy part; the hard part is finding the right three paragraphs out of a million to feed it, keeping that index fresh as the data changes, and not standing up a separate vector database to do it. Cortex Search is Snowflake's answer: a fully managed hybrid search service that embeds your text, runs vector and keyword search together with semantic reranking, and refreshes the index automatically, all inside Snowflake. It is the retrieval engine behind enterprise RAG chatbots and high-quality search bars, and it pairs directly with the Cortex Agents framework as the tool that answers questions about unstructured data. The thing to understand before you ship it: it is genuinely low-effort to stand up, but the bill has several meters, and one of them runs even when nobody is searching.

This guide is for the engineer asked to "add search" or "build a chatbot on our docs" who needs to know what Cortex Search does, how good it is out of the box, and where the cost hides.

Why not just use a vector database?

The default 2024-era answer to RAG was: chunk your text, run it through an embedding model, load the vectors into a dedicated vector store, and query it. That works, but it is a second system to run, secure, and keep in sync with the source data, and tuning retrieval quality is a research project of its own. Cortex Search collapses that stack. You point it at a column of text in a Snowflake table, and it handles embedding, indexing, refresh, and serving.

The quality story is the part that earns the "managed" label. Cortex Search does not just do vector similarity; it takes a hybrid approach combining vector search, keyword search, and a semantic reranking step, which is what gets you good results across messy real-world queries without hand-tuning. Vector search catches "internet is down" matching "connectivity problem"; keyword search catches exact product codes and names that embeddings blur; reranking puts the genuinely relevant hits on top. You get all three with no parameters to fiddle.

Creating a service is one SQL statement:

-- Point Cortex Search at a text column. It embeds, indexes,
-- and keeps the result fresh on its own.
CREATE OR REPLACE CORTEX SEARCH SERVICE transcript_search_service
  ON transcript_text
  ATTRIBUTES region
  WAREHOUSE = cortex_search_wh
  TARGET_LAG = '1 day'
  EMBEDDING_MODEL = 'snowflake-arctic-embed-l-v2.0'
  AS (
    SELECT transcript_text, region, agent_id
    FROM support_transcripts
  );

That TARGET_LAG = '1 day' is the freshness contract: the service checks the base table for changes about once a day and re-embeds only what changed. The embedding model is swappable, from the fast English-only snowflake-arctic-embed-m-v1.5 default up to multilingual and long-context options.

How do you query it, and how do you chunk the text?

Querying is a REST API, a Python API, or a SQL preview function. The SQL preview is the fastest way to sanity-check that retrieval works before you wire up an app:

-- Preview retrieval straight from a worksheet, with a filter on an attribute.
SELECT PARSE_JSON(
  SNOWFLAKE.CORTEX.SEARCH_PREVIEW(
    'cortex_search_db.services.transcript_search_service',
    '{
       "query": "internet issues",
       "columns": ["transcript_text", "region"],
       "filter": {"@eq": {"region": "North America"}},
       "limit": 1
     }'
  )
)['results'] AS results;

The single biggest lever on quality you control is chunk size. Cortex Search truncates anything longer than the embedding model's context window before vectorizing, and Snowflake's own research says smaller chunks retrieve more precisely. The recommendation is concrete: split your text into chunks of no more than 512 tokens, roughly 385 English words. Snowflake gives you a built-in function so you do not have to write a splitter:

-- Chunk long documents before indexing for sharper retrieval.
SELECT SNOWFLAKE.CORTEX.SPLIT_TEXT_RECURSIVE_CHARACTER(
  document_text, 'markdown', 512, 64
) AS chunks
FROM raw_documents;

Granting access follows Snowflake's normal model, and it matters because search services run with owner's rights: the service reads data as its creator, so you control exposure through who you grant usage to, not through the caller's row access. Lock that down deliberately, the same discipline as the RBAC and masking guide:

GRANT USAGE ON CORTEX SEARCH SERVICE transcript_search_service TO ROLE support_app;

What does it actually cost?

Here is where the managed convenience meets the invoice, and it is the part teams underestimate. A Cortex Search service bills on four separate meters, not one.

Illustrative: serving compute, billed per GB of indexed data per month, runs even when no queries are served. Source: Snowflake Cortex Search cost documentation.

Meter	What it charges for	The gotcha
Embedding tokens	Vectorizing each text row	Only added or changed rows re-embed, so churn drives it
Serving compute	Per GB of indexed data per month	Bills while the service is available, even with zero queries
Warehouse refresh	Running the source query on refresh	No credits if nothing changed since last refresh
Storage	The materialized index and structures	Flat rate per terabyte

The one that surprises people is serving compute, charged per gigabyte of indexed data per month whether or not anyone searches. A big index that sits idle still costs money, because the low-latency serving layer is kept warm for you. Snowflake added a fix worth knowing: you can set AUTO_SUSPEND (minimum 30 minutes of inactivity) so an idle service parks its serving compute and resumes on the next query. The first query after a suspend waits for the resume and concurrent ones get a 429, so build retry logic into your client.

-- Park serving compute after 30 minutes idle to stop paying for an unused index.
ALTER CORTEX SEARCH SERVICE transcript_search_service SET AUTO_SUSPEND = 1800;

Track the spend per service with the CORTEX_SEARCH_DAILY_USAGE_HISTORY view, and right-size the refresh warehouse: Snowflake recommends a dedicated warehouse no larger than MEDIUM for each service.

What are the limits you will hit?

Set expectations before you scale. A service's materialized result must be under 100 million rows or the create fails, though you can ask Snowflake to raise it. A single service is rate-limited to 20 queries per second and 140 across the account by default, with 429s when you exceed it, again contact your account team to raise it. Because the source query must qualify for Dynamic Table incremental refresh, the same query restrictions apply, so an arbitrary complex join may not be eligible. And Cortex Search does not yet support cloning, and the tables it reads must not be dropped or modified while the service runs, so coordinate schema changes around it.

None of these are dealbreakers for a typical knowledge base, but they are real edges, and hitting the row cap or the QPS limit in production without knowing it exists is an avoidable outage.

The honest read

Cortex Search is one of the cleaner managed-AI stories Snowflake tells: it deletes the vector-database tier, gives you genuinely good hybrid retrieval with no tuning, and keeps the index fresh on its own. For building RAG on data that already lives in Snowflake, it is the path of least resistance, and the tight integration with Cortex Agents makes it the obvious retrieval backbone. The catch is the serving meter that bills idle indexes, so treat AUTO_SUSPEND and right-sized chunks as setup, not afterthoughts. Get the chunking and the cost controls right up front and you have enterprise search and RAG without running a search stack. Skip them and you are paying rent on an index nobody is querying.

Sources

Cortex Analyst: let business users query Snowflake in plain English

2026-06-07T00:00:00Z

The most expensive bottleneck in most data teams is not compute, it is the queue. Business users have questions, only the analysts can write SQL, and every "quick number" becomes a ticket. Cortex Analyst is Snowflake's answer: a fully managed text-to-SQL service where a business user asks "what was month-over-month revenue growth in EMEA last quarter" in plain English and gets a real answer, generated as SQL, run on your warehouse, with no analyst in the loop. It ships as a REST API so you can drop it into Slack, Teams, a Streamlit app, or your own product. The thing that decides whether it delights users or embarrasses you: the semantic view you build first. Point it at a raw schema and it guesses; give it a semantic model and it gets the business logic right.

This guide is for the data engineer who will be asked to "add AI to our analytics" and needs to know what Cortex Analyst really is, what makes it accurate, what it costs, and where it falls down.

Why does a semantic model matter so much?

Generic text-to-SQL fails in enterprises for a boring reason: a database schema does not contain business meaning. A column called rev_amt does not tell a model that revenue excludes returns, that "EMEA" maps to a specific set of country codes, or that "active customer" has a precise definition your finance team agreed on. Hand a model just the schema and it hallucinates the business logic.

Cortex Analyst closes that gap with a semantic view, a schema-level Snowflake object that defines the business layer over your tables: logical tables for entities like customers and orders, dimensions for categorical context, facts for row-level numbers, metrics for the KPIs with their correct aggregation formulas, and the relationships that define how tables join. That metadata is what turns a vague question into the right SQL.

Illustrative: giving Cortex Analyst a semantic view rather than a bare schema is the single biggest lever on answer accuracy. Source: Snowflake Cortex Analyst documentation on semantic models.

The practical consequence: the work is not the AI, it is the semantic model. Snowflake handles the language model, the model selection, and the text-to-SQL machinery. Your job is to encode the business definitions once, well, so the answers are trustworthy. Skip that and you ship a confident liar.

-- A semantic view is the business layer Cortex Analyst reasons over.
-- It names entities, the metrics with their real formulas, and join paths,
-- so "revenue" means what finance means, not whatever a column is called.
CREATE SEMANTIC VIEW sales_analytics
  TABLES (
    orders AS analytics.public.orders PRIMARY KEY (order_id),
    customers AS analytics.public.customers PRIMARY KEY (customer_id)
  )
  RELATIONSHIPS (
    orders (customer_id) REFERENCES customers (customer_id)
  )
  FACTS (orders.line_total AS quantity * unit_price)
  METRICS (orders.net_revenue AS SUM(line_total) WHERE status != 'returned')
  DIMENSIONS (customers.region AS region);

You can build it with the Semantic View Autopilot or hand-write the YAML, and you should seed it with verified example questions and their correct SQL, which Snowflake uses to guide generation and lets you measure accuracy over time.

What does it cost, and how is that different from raw Cortex?

This is where Cortex Analyst surprises people in a good way. Most Cortex AI functions bill per token, so a long prompt costs more. Cortex Analyst bills per message instead: each successful request (HTTP 200) counts as one unit, and the number of tokens does not affect the price unless you call it through Cortex Agents. Failed requests are not charged.

The cost you must not forget is the second meter. Cortex Analyst's per-message charge covers only the text-to-SQL generation. The generated SQL then runs on your virtual warehouse, and that compute is billed separately. So a chatty dashboard that fires hundreds of questions an hour costs you on two lines: the Analyst messages and the warehouse time to execute every query. Track the first with the CORTEX_ANALYST_USAGE_HISTORY view in ACCOUNT_USAGE and the second the same way you watch any warehouse, as covered in the warehouse sizing guide.

Right-size the warehouse behind it. The questions are usually small aggregations, so a small warehouse with auto-suspend is plenty. You do not need a big cluster to answer "total revenue last month".
Cache the obvious. If the same ten questions arrive all day, the generated SQL is deterministic enough to cache results upstream rather than re-running every time.
Watch multi-turn cost. Follow-up questions resend the whole conversation history on every turn, and the cost grows with each round, so long rambling sessions cost more than crisp ones.

What can it not do yet?

Set expectations honestly with stakeholders, because Cortex Analyst is narrower than "ask anything". It answers questions that can be resolved with SQL over your structured data, and nothing else. It does not generate open-ended business insight: ask "what trends do you see" and it has no answer, because that is not a SQL query. It also cannot reference the results of a previous query, so "what is the revenue of the second product you just listed" breaks, since it does not have the earlier result set in hand. And very long, intent-shifting conversations degrade, at which point the fix is to reset and start clean.

Governance is the part you can reassure security about. Cortex Analyst runs inside Snowflake's perimeter, the default models from Mistral and Meta keep data and prompts within Snowflake's governance boundary, it does not train on your data, and the generated SQL executes under the calling user's role-based access control, so a user can never get an answer from data their role cannot see. Access is gated by the SNOWFLAKE.CORTEX_ANALYST_USER database role, which you grant to a custom role rather than directly to users. For the broader access-control pattern, see the governance guide.

The honest read

Cortex Analyst is one of the few enterprise AI features where the value is real and the work is well understood: it moves the analyst queue off your team and onto a managed service, and it does so without your data leaving Snowflake. The catch is that it is only as good as the semantic model you invest in, and that model is ordinary, unglamorous data-modelling work, not magic. Teams that treat the semantic view as the product ship something business users trust. Teams that point it at a raw schema and call it AI ship a demo that quietly gives wrong numbers, which is worse than no answer at all.

Sources

Snowflake Cortex: running LLMs where your data already lives

2026-06-07T00:00:00Z

Every data team has been handed the same ask: "can we use AI on this?" The usual answer involves standing up a separate service, shipping data to an external API, and owning a new security review. Snowflake Cortex removes most of that by exposing large language models as plain SQL functions that run inside the Snowflake perimeter. You call AI_COMPLETE('llama3.1-70b', prompt) in a query, against data that never leaves your account, and get a result back in the same result set. The catch that decides your bill: these functions are billed per token by model, and the spread between a small model and a frontier one is roughly 40x. Model choice is not a detail here, it is the budget.

This guide is for the data engineer or data scientist who wants to add LLM work to a Snowflake pipeline without standing up new infrastructure, and who needs to know what is production-ready versus what is a demo.

What can you actually call?

Cortex ships LLM capability as two kinds of SQL function. The task-specific functions do one job well with no prompt engineering: AI_CLASSIFY sorts text or images into categories you define, AI_FILTER returns true or false so you can use a model inside a WHERE or JOIN, AI_SENTIMENT extracts sentiment, AI_EXTRACT pulls structured fields out of text and documents, AI_TRANSLATE localizes, and AI_AGG and AI_SUMMARIZE_AGG summarize across many rows without hitting a context-window limit. The general function is AI_COMPLETE, the one you reach for when you want a specific model to do an open-ended generation.

The point that makes this worth using is that it is just SQL, so a model call composes with everything else you do in a query:

-- Triage support tickets in one pass: classify, score sentiment,
-- and summarize, all inside the warehouse, no data leaving Snowflake.
SELECT
    ticket_id,
    AI_CLASSIFY(body, ['billing', 'bug', 'feature_request', 'churn_risk']):labels[0]::string AS topic,
    AI_SENTIMENT(body):categories[0]:sentiment::string AS sentiment,
    AI_COMPLETE('llama3.1-8b',
        'Summarize this ticket in one sentence: ' || body) AS one_line
FROM support_tickets
WHERE created_at > DATEADD('day', -1, CURRENT_TIMESTAMP());

To run any of this, the role needs the USE AI FUNCTIONS account privilege plus the CORTEX_USER database role. Models from OpenAI, Anthropic, Meta, Mistral, and DeepSeek are available depending on your region, and all of them run inside Snowflake's service perimeter rather than calling out to a third-party endpoint, which is the entire security argument for using Cortex over a raw API.

Beyond the one-shot text functions, Cortex also covers the building blocks for retrieval. AI_EMBED turns text or images into embedding vectors you can store in a VECTOR column and search with VECTOR_COSINE_SIMILARITY, which is the foundation of a retrieval-augmented generation pipeline that never leaves Snowflake. For teams that need more than SQL functions, Snowpark runs custom Python, including your own models, on Snowflake compute, so the classic build-versus-buy line sits between a managed Cortex function and a Snowpark job you own end to end.

What does it cost, and where does it bite?

Cortex AI functions are billed by tokens processed, metered as Snowflake credits, and the rate depends on the model. That is the lever that dominates everything else.

Illustrative: relative cost per million tokens climbs steeply with model size in Cortex AI_COMPLETE, roughly 1x for a small model, 9x mid, 40x frontier. Source: Snowflake Cortex documentation; check the current consumption table for exact per-model rates.

The practical consequence: defaulting every call to the biggest model is how a proof-of-concept turns into a budget incident. Most classification, sentiment, and extraction work runs fine on a small model, and the small models are where the per-token rate is a fraction of frontier. Reserve the large models for genuinely hard generation, and you can cut the bill by an order of magnitude without anyone noticing a quality drop. Three habits keep Cortex spend honest:

Right-size the model per task. Use a small model for classification and tagging; only escalate to a frontier model when the output quality demonstrably needs it.
Count tokens before you run at scale. AI_COUNT_TOKENS tells you the token load of a prompt, so you can estimate the cost of a batch before you point it at a 50-million-row table.
Batch, do not trickle. Cortex functions are optimized for throughput over large tables. Running them row-by-row from an app is the slow, expensive path; for interactive latency Snowflake points you at the REST APIs instead.

Track spend with the Cortex functions in ACCOUNT_USAGE so model cost lands in the same FinOps view as your warehouses. The same right-sizing instinct from the warehouse sizing guide applies here: the cheapest unit that does the job, not the biggest one available.

One more cost trap worth naming: the prompt is part of the token count, not just the answer. Stuffing a 4,000-token system prompt and the full document into every row of a large table means you pay for that context on every single call. If you are classifying ten million rows, a 200-token prompt versus a 2,000-token prompt is a 10x difference on the input side alone. Trim the prompt, pass only the columns the model needs, and use the task-specific functions instead of hand-rolling the same job through AI_COMPLETE, because they are tuned for exactly that work.

What is production-ready, and what is still a demo?

Be honest with stakeholders about the maturity line, because Cortex spans both sides of it. The task-specific functions and AI_COMPLETE are generally available and fine to ship; they are SQL functions with predictable billing. Higher up the stack, Cortex Search (retrieval) and Cortex Analyst (natural-language-to-SQL) are powerful but deserve real evaluation before you put them in front of users, and some individual functions are still Preview features, which means they can change and should not anchor a production SLA. The rule: check whether the specific function you are calling is GA or Preview before it goes near a customer path. Generally available functions are safe to build on; Preview ones are for prototypes.

The number to watch

Track credits per thousand Cortex calls, broken down by model. That single view exposes the most common failure mode, an expensive model quietly handling work a cheap one could do, and it turns "can we use AI on this?" into a question you can actually price. When the per-call cost is dominated by one frontier model on a high-volume task, that is your first optimization, not a bigger budget. Get that one number on a dashboard and the AI line in your Snowflake bill stops being a mystery.

Sources

Building an AI agent on your Snowflake data with Cortex Agents

2026-06-07T00:00:00Z

Every enterprise that bought into chat-with-your-data quickly hit the same wall: a text-to-SQL tool answers questions about tables, a search tool answers questions about documents, and a real business question needs both at once. "Why did churn spike in EMEA last quarter, and what did the support tickets say" is half a SQL query and half a document search, stitched together with reasoning. Cortex Agents is Snowflake's framework for exactly that: an AI agent that plans a multi-step task, calls the right tool for each step, reflects on the result, and keeps going until it has an answer, all inside Snowflake's governance boundary. It is the orchestration layer that sits above Cortex Analyst and Cortex Search rather than replacing them.

This guide is for the builder who has been asked to "build us an AI agent" on company data and needs to know what Cortex Agents actually does, how the loop works, what privileges it needs, and where the costs hide before you ship it.

What does an agent do that a single Cortex call does not?

A plain Cortex call is one shot: a prompt in, a completion out. An agent runs a loop. Snowflake's orchestration follows a plan-act-reflect cycle that should be familiar to anyone who has built with agent frameworks:

Planning. The agent reads the request, explores what it knows, splits the task into steps, and routes each step to a tool. "Churn plus ticket sentiment" becomes a structured query step and a document search step.
Tool use. It calls the tools. Structured questions go to a Cortex Analyst tool over your semantic view. Unstructured questions go to a Cortex Search tool over indexed documents. It can also call custom tools you expose as stored procedures or UDFs, and a web-search tool backed by the Brave API with zero data retention.
Reflection. It evaluates the tool output, decides whether it has enough to answer or needs another step, and iterates.
Monitor and respond. It assembles the final answer and you can monitor, evaluate, and tune the whole trajectory.

The agent itself is a first-class Snowflake object, and it uses threads to persist conversation context across turns, so a follow-up question keeps the earlier context instead of starting cold. You access it through the agent:run REST API, which means the same agent can power a Streamlit app, an internal portal, or a product feature.

-- An agent is a Snowflake object that bundles an orchestration model
-- with the tools it is allowed to use. The model plans; the tools act.
CREATE AGENT support_analyst
  WITH PROFILE = '{"orchestration_model": "auto"}'
  COMMENT = 'Answers questions across sales tables and support tickets'
  TOOLS = (
    cortex_analyst_tool(semantic_view => 'sales_analytics'),
    cortex_search_tool(service => 'support_tickets_search')
  );

Setting the orchestration model to auto lets Snowflake pick, which is the recommended default; you can pin a specific model such as claude-sonnet-4-5 or openai-gpt-4.1 when you need predictable behaviour.

What does it cost to run?

This is the question that decides whether your agent reaches production, and the honest answer is that an agent has no single price. A Cortex Agent bill is the sum of four separate meters, and a careless agent can light up all four on every question.

Illustrative: a Cortex Agent combines four cost components rather than one, so a single question can bill on all four at once. Source: Snowflake Cortex Agents cost documentation.

Meter	What it charges for	What drives it up
Orchestration tokens	The planning and reflection model's reasoning	More steps, longer threads, bigger context
Cortex Analyst tokens	Each structured-data tool call	Every SQL step the agent takes
Cortex Search index	Keeping the document index live	Index size and persistence over time
Warehouse run	Executing the SQL the agent generates	Query size and warehouse uptime

The trap is that an agent multiplies calls. A single user question can trigger several planning rounds, two or three tool calls, and a reflection pass, so what feels like "one question" is a dozen billed operations under the hood. Watch the trajectory, cap the number of steps where you can, and keep threads from growing unbounded, because every turn resends accumulated context and the orchestration-token line climbs with it. The warehouse discipline from the warehouse sizing guide applies to the fourth meter unchanged.

What privileges and guardrails does it need?

Cortex Agents is governed like the rest of Snowflake, which is the reason to build the agent here rather than wiring an external LLM to a database connection. To create and run agents a role needs SNOWFLAKE.CORTEX_USER (or the more specific CORTEX_AGENT_USER database role) plus the object privileges to CREATE AGENT, and USAGE, OWNERSHIP, MODIFY, or MONITOR on the agents themselves. Every tool the agent calls still runs under the caller's role, so the agent can never read data the user could not, the same boundary that protects Cortex Analyst and is enforced by the RBAC and masking setup.

Two operational caveats before you put an agent in front of users:

Accuracy is not guaranteed. Snowflake is explicit that agent answers can be wrong and should be reviewed, especially for anything that drives a decision. Build a review step for high-stakes use, do not auto-execute on the agent's word.
Runtime matters. Agents are not supported from the Streamlit-in-Snowflake warehouse runtime; you run them in the container runtime instead. Get this wrong and your first deploy fails for an unobvious reason.

The honest read

Cortex Agents is the right tool when a real question genuinely spans structured and unstructured data and you want the reasoning, the data, and the access control to stay in one governed place. That is a meaningful capability, and keeping it inside Snowflake's perimeter is a genuine advantage over bolting an external agent onto a database. The discipline it demands is cost observability: four meters, a loop that multiplies calls, and answers you still have to verify. Build the semantic view and the search service well first, instrument the trajectory before you scale, and treat the agent as a powerful assistant that needs a reviewer, not an oracle you can trust unattended. The rest of the Snowflake guides cover the foundations an agent is only as good as.

Sources

Snowflake Adaptive Compute rewrites warehouse sizing

2026-06-07T00:00:00Z

Snowflake warehouse sizing used to be a small act of fiction. You picked a size, guessed at concurrency, argued about auto-suspend, and hoped next month’s bill did not punish last month’s optimism. Snowflake Adaptive Compute changes that bargain. It replaces fixed warehouse sizing with adaptive warehouses that set compute per query, bill by query usage, and expose only 2 primary knobs: MAX_QUERY_PERFORMANCE_LEVEL and QUERY_THROUGHPUT_MULTIPLIER.

The important correction: Snowflake’s June 2, 2026 blog says Snowflake Adaptive Compute is generally available soon, but the current Snowflake Adaptive Compute documentation lists it as an Open Preview feature. For platform teams, that is the whole story in miniature. This is not just a faster warehouse type. It is a new operating model for Snowflake credits, observability, and accountability.

If you already moved steady workloads to Snowflake Gen2 warehouses, Adaptive Compute is the next question you need to answer. Gen2 keeps the old control surface. Adaptive Compute asks you to let Snowflake schedule and scale inside an account-level compute pool, then prove whether the bill got better.

What actually changes when you create an adaptive warehouse?

An adaptive warehouse is still a Snowflake virtual warehouse from the user’s point of view. You USE WAREHOUSE, run SQL, load data, and monitor usage in SNOWFLAKE.ACCOUNT_USAGE. The difference is what you stop managing. Snowflake says adaptive warehouses remove manual warehouse size, multi-cluster settings, Query Acceleration Service settings, and suspend or resume policies from your tuning loop.

The default create statement is deliberately boring:

CREATE ADAPTIVE WAREHOUSE bi_adaptive_wh;

That creates a warehouse with MAX_QUERY_PERFORMANCE_LEVEL = XLARGE and QUERY_THROUGHPUT_MULTIPLIER = 2, according to the SQL examples in Snowflake’s adaptive warehouse docs. Those defaults matter because they are not cosmetic. MAX_QUERY_PERFORMANCE_LEVEL is the upper bound Snowflake may apply for a single statement when it has high confidence an optimization helps. QUERY_THROUGHPUT_MULTIPLIER controls how much total query work can run at once relative to Snowflake’s computed baseline.

Here is the version you should put in Terraform or a migration script when you want intent on the page:

CREATE ADAPTIVE WAREHOUSE etl_adaptive_wh
  WITH MAX_QUERY_PERFORMANCE_LEVEL = LARGE
       QUERY_THROUGHPUT_MULTIPLIER = 4
       STATEMENT_QUEUED_TIMEOUT_IN_SECONDS = 300
       STATEMENT_TIMEOUT_IN_SECONDS = 3600;

The supported performance levels run from XSMALL through X4LARGE. A throughput multiplier is a non-negative integer, and 0 means unlimited throughput. That last value is powerful and dangerous. In a FinOps review, 0 should read as no instantaneous cap, not as a clever shortcut.

Snowflake’s claimed benchmark gains are large enough to justify a pilot, but not large enough to skip one. Its June 2026 blog reports Adaptive Compute gains of 1.6x for analytics, 2.2x for operational throughput, and 3.5x for DML-heavy workloads, based on TPC-DS and internal benchmarks measured in May 2026 against standard compute.

Snowflake reported Adaptive Compute benchmark gains of 1.6x faster analytics, 2.2x higher operational throughput, and 3.5x faster DML execution, measured in May 2026.

Read the chart as a migration hypothesis, not as your savings forecast. The strongest number, 3.5x faster DML execution, points at pipelines, ingestion, and transformation workloads. The least surprising number, 1.6x faster analytics, still matters if your analysts live in ad hoc query land and your warehouse queue is a standing meeting with better snacks.

How is Snowflake Adaptive Compute billed?

The billing change is the feature. Standard warehouses make you reason about size, run time, idle time, and cluster count. Adaptive warehouses use query-based billing. Snowflake says the cost of each query depends on compute and software resources used, including cluster sizes and capacity used by features like Query Acceleration Service. Creating the warehouse is free. Charges start when the first query runs.

That shift kills one familiar FinOps metric: idle waste. On standard warehouses, WAREHOUSE_METERING_HISTORY.CREDITS_ATTRIBUTED_COMPUTE_QUERIES helps separate query work from idle compute. Snowflake’s WAREHOUSE_METERING_HISTORY documentation says that column is NULL for adaptive warehouses. So do not port your old idle-cost dashboard and call the migration measured.

For adaptive warehouses, start at the query level:

SELECT
  query_id,
  warehouse_name,
  SUM(credits_used) AS credits_used,
  SUM(credits_used_compute) AS compute_credits,
  SUM(credits_used_cloud_services) AS cloud_services_credits
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_METERING_HISTORY
WHERE warehouse_name = 'BI_ADAPTIVE_WH'
  AND query_start_time >= DATEADD(day, -7, CURRENT_DATE())
GROUP BY query_id, warehouse_name
ORDER BY credits_used DESC;

The QUERY_METERING_HISTORY view returns per-query credit usage for queries run on adaptive warehouses over the last 365 days, with view latency of up to 1 hour. That is the view your FinOps team should care about first. It lets you find the expensive query patterns that a warehouse-level total hides.

Use warehouse metering for the monthly control plane:

SELECT
  warehouse_name,
  DATE_TRUNC(day, start_time) AS usage_day,
  SUM(credits_used) AS total_credits,
  SUM(credits_used_compute) AS compute_credits
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE warehouse_name = 'BI_ADAPTIVE_WH'
  AND start_time >= DATEADD(day, -30, CURRENT_DATE())
GROUP BY warehouse_name, usage_day
ORDER BY usage_day;

The old question was whether an XLARGE warehouse sat idle. The new question is whether an XLARGE performance cap let a handful of queries consume more instantaneous compute than your service-level objective deserved.

Which workloads should you move first?

Start with workloads where static sizing is already lying to you. Snowflake’s docs call out analytics, data loading pipelines, mixed BI and ETL, high size variance, and occasional HTAP queries as adaptive warehouse candidates. They also say you may prefer Gen2 for workloads that need direct sizing control, interactive warehouses for very low latency dashboards or applications, and Snowpark-optimized warehouses for high-memory Snowpark or ML workloads.

A practical migration order looks like this:

Workload	First adaptive setting to test	Why it belongs in the pilot
Bursty BI plus ad hoc SQL	`MAX_QUERY_PERFORMANCE_LEVEL = XLARGE`, multiplier `2`	Matches the default and tests whether queues fall without manual multi-cluster tuning.
Cost-sensitive ELT	`MAX_QUERY_PERFORMANCE_LEVEL = MEDIUM`, multiplier `4`	Lets more work run while capping per-statement optimization.
DML-heavy pipelines	`MAX_QUERY_PERFORMANCE_LEVEL = LARGE`, multiplier `4` or `6`	Snowflake reports the largest benchmark gain here: 3.5x faster DML execution.
User-facing low-latency apps	Do not start here	Snowflake points those to interactive warehouses, not adaptive warehouses.

The table is intentionally conservative. Adaptive Compute is Open Preview, requires Enterprise Edition or higher, and is currently limited in Snowflake’s docs to AWS US West 2 (Oregon), EU West 1 (Ireland), and AP Northeast 1 (Tokyo). That is enough to run serious tests. It is not enough to rewrite every warehouse standard across a global estate on Monday morning.

The most interesting candidate is the messy shared warehouse you already dislike. The one with BI dashboards at 9 a.m., analyst exploration at noon, and transformation work after someone forgot to reschedule a task. Adaptive Compute’s account-level shared pool is built for that mess. It routes jobs from all adaptive warehouses in the account to a dedicated pool that is not shared with other accounts or other warehouse types.

How do you convert without breaking running queries?

Snowflake says converting a standard warehouse to or from adaptive is an online operation. Existing queries continue on the old compute resources, while new queries use the new warehouse type. During that overlap, Snowflake says you are charged for both sets of compute resources.

That detail deserves a runbook line in bold: convert during a quiet window even when the operation is online.

The SQL is simple:

ALTER WAREHOUSE bi_wh SET WAREHOUSE_TYPE = 'ADAPTIVE';

Rolling back is just as direct:

ALTER WAREHOUSE bi_wh SET WAREHOUSE_TYPE = 'STANDARD';

On conversion, Snowflake computes adaptive values from the existing warehouse size, MAX_CLUSTER_COUNT, Query Acceleration Service scale factor, and warehouse generation. After conversion, standard properties such as WAREHOUSE_SIZE, MIN_CLUSTER_COUNT, MAX_CLUSTER_COUNT, and SCALING_POLICY no longer apply. Adaptive properties do not apply after converting back to standard.

You can inspect the new state with SHOW WAREHOUSES:

SHOW WAREHOUSES LIKE 'BI_WH';

For adaptive warehouses, Snowflake adds columns such as STATE, MAX_QUERY_PERFORMANCE_LEVEL, QUERY_THROUGHPUT_MULTIPLIER, and DISABLED_REASONS. STATE is ENABLED or DISABLED, which is separate from the old mental model of a warehouse being suspended.

There are hard conversion limits. Snowflake’s docs say conversions to or from X5LARGE or X6LARGE are not supported, and neither are conversions to or from Snowpark-optimized or interactive warehouses. If you run those, create a new adaptive warehouse for testing instead of trying to be clever with ALTER.

What should your cost guardrails look like?

Do not hand Adaptive Compute to every team with CREATE WAREHOUSE. The control surface is smaller, which makes the blast radius easier to miss. QUERY_THROUGHPUT_MULTIPLIER = 0 can remove the throughput cap, and a high MAX_QUERY_PERFORMANCE_LEVEL can raise per-query spend when Snowflake believes optimization will help.

Start with roles:

GRANT CREATE WAREHOUSE ON ACCOUNT TO ROLE platform_compute_admin;

GRANT USAGE ON WAREHOUSE bi_adaptive_wh TO ROLE bi_analyst;
GRANT MONITOR ON WAREHOUSE bi_adaptive_wh TO ROLE finops_analyst;
GRANT OPERATE ON WAREHOUSE bi_adaptive_wh TO ROLE platform_operator;

Snowflake’s access control docs say CREATE WAREHOUSE is required at the account level, while warehouse privileges include USAGE, MONITOR, OPERATE, MODIFY, and OWNERSHIP. Keep MODIFY away from workload teams unless you want multiplier changes to become the new shadow scaling policy.

Then track queuing and latency before you raise the multiplier:

SELECT
  DATE_TRUNC(hour, start_time) AS hour_start,
  warehouse_name,
  AVG(queued_overload_time) AS avg_queued_overload_ms,
  AVG(total_elapsed_time) AS avg_elapsed_ms,
  COUNT(*) AS query_count
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE warehouse_name = 'BI_ADAPTIVE_WH'
  AND start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
GROUP BY hour_start, warehouse_name
ORDER BY hour_start;

If queued_overload_time stays high, increase QUERY_THROUGHPUT_MULTIPLIER one step and watch query-level credits. If credits spike while latency barely moves, lower the cap. This is the new tuning loop. It is less warehouse babysitting, but it is not zero governance.

A controlled adjustment looks like this:

ALTER WAREHOUSE bi_adaptive_wh SET
  MAX_QUERY_PERFORMANCE_LEVEL = LARGE
  QUERY_THROUGHPUT_MULTIPLIER = 3;

For production, pair that with a resource monitor or Snowflake budget. Snowflake says the same cost tools work with adaptive warehouses, including budgets, resource monitors, QUERY_METERING_HISTORY, and WAREHOUSE_METERING_HISTORY. The point is to govern total spend over time while the warehouse adapts inside those guardrails.

What should you do before moving production spend?

Run a two-week A/B pilot, not a belief exercise. Pick one existing warehouse with volatile demand. Clone the workload routing, set query tags, and compare p50, p95, total credits, credits per successful query, and queued time. Use the same 7-day and 30-day windows on both sides. Snowflake’s benchmark chart is useful because it tells you where to look first: analytics at 1.6x, operational throughput at 2.2x, and DML execution at 3.5x.

Your acceptance criteria should fit on one screen:

Credits per business event fall, or latency falls enough to justify flat credits.
QUERY_METERING_HISTORY identifies the top 10 query patterns by adaptive spend.
No team can change MAX_QUERY_PERFORMANCE_LEVEL or QUERY_THROUGHPUT_MULTIPLIER without platform approval.
Preview-region and Enterprise Edition constraints match the accounts you plan to use.
Rollback to WAREHOUSE_TYPE = 'STANDARD' has been tested once, not merely admired in a doc.

The feature is promising because it moves Snowflake closer to the way teams actually run data platforms: mixed workloads, uneven demand, and bills that need attribution below the warehouse. The lock-in is also plain. You are outsourcing more scheduling intelligence to Snowflake, and your cost model becomes more Snowflake-specific at the query level.

That trade can be worth it. Just make Snowflake earn the credits query by query.

Sources

Snowflake Adaptive Compute: a bill owner's guide

2026-06-07T00:00:00Z

Snowflake warehouse sizing used to be a tax you paid in meetings, runbooks, and Slack threads. Someone asks whether the finance dashboard should be on Medium or Large. Someone else asks why the ELT warehouse queued for 11 minutes at 8:05 a.m. Then the bill arrives and everybody rediscovers AUTO_SUSPEND.

Snowflake Adaptive Compute is Snowflake's attempt to make that whole ritual optional. It replaces fixed warehouse sizing with an adaptive warehouse that chooses compute per query, while you set two guardrails: MAX_QUERY_PERFORMANCE_LEVEL and QUERY_THROUGHPUT_MULTIPLIER. The catch is the same as the gift: Snowflake hides more of the machinery, and during public preview it does not give you per query cost visibility.

Snowflake lists Adaptive Compute as an open preview feature introduced in April 2026, and its documentation says it currently requires Enterprise Edition or higher and is available only in 3 AWS regions: US West 2 Oregon, EU West 1 Ireland, and AP Northeast 1 Tokyo. That makes this a migration candidate for real workloads, but not a blind replacement for your most politically sensitive warehouse.

If you already read our guide to how Snowflake Adaptive Compute rewrites warehouse sizing, treat this as the bill owner's companion piece: how it works, what to monitor, and where the control moves.

What did Snowflake actually change in the warehouse model?

Adaptive Compute gives you a new warehouse type, not a new SQL engine you call directly. You create an adaptive warehouse, point sessions and jobs at it, and Snowflake routes queries into an account dedicated compute pool. Snowflake says that pool is not shared with other accounts, but it is separate from your standard and Snowpark optimized warehouses.

The basic DDL is intentionally boring:

CREATE ADAPTIVE WAREHOUSE wh_adaptive_bi;

That creates an adaptive warehouse with Snowflake's documented defaults: MAX_QUERY_PERFORMANCE_LEVEL = XLARGE and QUERY_THROUGHPUT_MULTIPLIER = 2. You can also use the standard warehouse syntax with WAREHOUSE_TYPE = 'ADAPTIVE', which matters if your provisioning code already emits CREATE WAREHOUSE statements. Snowflake documents both forms in its Adaptive Compute SQL reference.

CREATE WAREHOUSE wh_adaptive_bi
  WITH WAREHOUSE_TYPE = 'ADAPTIVE'
       MAX_QUERY_PERFORMANCE_LEVEL = LARGE
       QUERY_THROUGHPUT_MULTIPLIER = 3;

What disappears is the old sizing choreography. You no longer set WAREHOUSE_SIZE, MIN_CLUSTER_COUNT, MAX_CLUSTER_COUNT, SCALING_POLICY, or a separate Query Acceleration Service scale factor on the adaptive warehouse. Snowflake's docs are explicit that standard warehouse properties such as WAREHOUSE_SIZE, MIN_CLUSTER_COUNT, MAX_CLUSTER_COUNT, and SCALING_POLICY cannot be set on an adaptive warehouse.

The chart below counts the configuration surface that matters for day to day tuning. It is illustrative, but the inputs come from Snowflake's documented properties: a standard warehouse exposes the usual size, cluster, scaling, and QAS controls, while an adaptive warehouse exposes 2 primary controls.

Illustrative: Standard warehouses expose 4 common tuning controls in this comparison, while Snowflake Adaptive Compute exposes 2 primary controls: MAX_QUERY_PERFORMANCE_LEVEL and QUERY_THROUGHPUT_MULTIPLIER.

That reduction is the product bet. Snowflake is saying most teams do not really want finer grained knobs. They want bounded latency, bounded spend, and fewer 9 a.m. warehouse autopsies.

The two remaining knobs are worth reading literally:

Control	Applies to	Default or special value	What it really limits
`MAX_QUERY_PERFORMANCE_LEVEL`	Adaptive warehouse	`XLARGE` default	Upper bound for a single statement's performance level
`QUERY_THROUGHPUT_MULTIPLIER`	Adaptive warehouse	`2` default	Burst throughput as a multiplier over Snowflake's computed minimum
`QUERY_THROUGHPUT_MULTIPLIER = 0`	Adaptive warehouse	Special value `0`	Unlimited throughput, subject to available capacity
`WAREHOUSE_SIZE`	Standard warehouse	`XSMALL` default in standard `CREATE WAREHOUSE` docs	Fixed cluster size for a running warehouse

The important word is cap. Setting MAX_QUERY_PERFORMANCE_LEVEL = XLARGE does not mean every tiny lookup burns XLARGE equivalent resources. Snowflake says smaller queries can run below the cap when they do not need that much compute. That is why this is not just auto resize with a fresh coat of paint.

How do you migrate without breaking jobs or chargeback?

The clean migration path is conversion in place. Snowflake documents that converting to or from an adaptive warehouse is an online operation: running queries continue on existing compute, while new queries use the new warehouse type. The warehouse name survives, which is more important than it sounds if your dbt profiles, Airflow DAGs, BI connections, and stored procedures have warehouse names hardcoded.

ALTER WAREHOUSE wh_bi_prod SET WAREHOUSE_TYPE = 'ADAPTIVE';

Snowflake automatically derives the adaptive values from the old warehouse's size, MAX_CLUSTER_COUNT, QAS scale factor, and generation. That is a sensible first move because it preserves the intent of the old shape. It is not a reason to skip review.

After conversion, inspect the visible properties:

SHOW WAREHOUSES LIKE 'WH_BI_PROD';

Snowflake adds adaptive specific SHOW WAREHOUSES columns such as MAX_QUERY_PERFORMANCE_LEVEL, QUERY_THROUGHPUT_MULTIPLIER, STATE, and DISABLED_REASONS. Properties that no longer apply show as NULL.

If the derived values are too generous for a dashboard warehouse, bring them down before the business discovers a new definition of interactive:

ALTER WAREHOUSE wh_bi_prod SET
  MAX_QUERY_PERFORMANCE_LEVEL = LARGE
  QUERY_THROUGHPUT_MULTIPLIER = 2;

If the migration goes sideways, you can convert back:

ALTER WAREHOUSE wh_bi_prod SET WAREHOUSE_TYPE = 'STANDARD';

There is one billing wrinkle in the conversion path that deserves a bright yellow sticky note. Snowflake says that while old queries finish and new queries run on the new warehouse type, you are charged for both sets of compute resources. For a quiet BI warehouse that may be noise. For a heavy ETL warehouse with 2 hour transformations already running, choose the migration window with intent.

Do not convert unsupported shapes. During preview, Snowflake says you cannot convert to or from X5Large or X6Large warehouses, Snowpark optimized warehouses, or interactive warehouses. That means a compute heavy Snowpark workload should stay where it is unless Snowflake broadens support.

How is Adaptive Compute billed, and what can you prove today?

Adaptive warehouses use query based billing. That sounds like a clean break from classic warehouse uptime billing, but Snowflake still reports the usage as virtual warehouse credits under compute. You are not charged for creating an adaptive warehouse. Charges start when the first query runs.

This is the cost model in one sentence: you manage spend with caps and monitors, not with idle time math.

That is a meaningful change for teams that spent years training everyone to fear idle warehouses. On a standard warehouse, the size determines the compute resources in each cluster and therefore the credits consumed while the warehouse is running. On an adaptive warehouse, Snowflake says each query's cost depends on compute and software resources used, including cluster sizes and additional capacity used by features like QAS.

Here is the part finance will ask about first: QAS does not show up as a separate adaptive warehouse credit line during preview. Snowflake says QAS usage is included in compute credits for adaptive warehouses. That simplifies showback, but it also removes a familiar line item you may have used to explain spikes.

Use WAREHOUSE_METERING_HISTORY for daily warehouse level credits:

SELECT
  start_time::DATE AS usage_date,
  warehouse_name,
  SUM(credits_used) AS credits_used
FROM snowflake.account_usage.warehouse_metering_history
WHERE warehouse_name = 'WH_BI_PROD'
  AND start_time >= DATEADD(day, -14, CURRENT_TIMESTAMP())
GROUP BY 1, 2
ORDER BY 1;

Use QUERY_HISTORY to confirm that the workload is actually running as adaptive, and to watch latency and queuing:

SELECT
  warehouse_name,
  COUNT(*) AS queries,
  AVG(total_elapsed_time) AS avg_elapsed_ms,
  AVG(queued_overload_time) AS avg_queued_overload_ms
FROM snowflake.account_usage.query_history
WHERE warehouse_name = 'WH_BI_PROD'
  AND warehouse_size = 'ADAPTIVE'
  AND start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
GROUP BY 1;

Snowflake's docs also recommend WAREHOUSE_LOAD_HISTORY for queuing behavior. That is the view you should wire into an alert before you increase the throughput multiplier:

SELECT
  start_time,
  warehouse_name,
  avg_running,
  avg_queued_load
FROM snowflake.account_usage.warehouse_load_history
WHERE warehouse_name = 'WH_BI_PROD'
  AND start_time >= DATEADD(hour, -24, CURRENT_TIMESTAMP())
ORDER BY start_time;

What you cannot prove yet is per query cost. Snowflake says query level cost visibility is not available during public preview and is planned for general availability. That is the biggest practical reason to pilot Adaptive Compute on workloads with good warehouse level ownership. If 12 teams share one warehouse, adaptive billing will not magically produce clean accountability.

When is Adaptive Compute better than Gen2, and when is it just less control?

Gen2 warehouses and Adaptive Compute solve different problems. Gen2 keeps the familiar fixed warehouse model and improves the engine and hardware under it. Adaptive Compute changes the operating model.

Snowflake's 2025 product blog said Standard Warehouse Generation 2 delivered 2.1x faster performance for core analytics workloads over the 12 months ending May 2, 2025, and positioned Adaptive Compute as the next step toward less infrastructure tuning. If you moved to Gen2 and got the performance you needed, you do not have to treat Adaptive Compute as an emergency migration.

Choice	Status or number	What you still tune	Billing behavior	Best fit
Standard warehouse Gen1	Default generation `1` in `CREATE WAREHOUSE` docs	Size, clusters, scaling, suspend, QAS	Credits while the warehouse runs	Stable workloads with tight manual control
Standard warehouse Gen2	Snowflake cited 2.1x faster core analytics performance in 2025	Same warehouse model, newer generation	Credits while the warehouse runs	Existing warehouses that need faster execution without model change
Adaptive warehouse	Open preview introduced April 2026	2 primary knobs	Query based compute credits	Variable concurrency where tuning overhead is the pain

The strongest fit is a warehouse where the hard problem is workload variance: Monday dashboards, hourly ELT bursts, ad hoc analyst queries, and the occasional monster join. Adaptive Compute can choose resources per query and let you cap the worst case.

The weaker fit is a warehouse where you need deterministic cost attribution or a tightly reasoned performance envelope. If a regulated team asks why one query cost what it cost, preview Adaptive Compute may not satisfy them yet. You can show warehouse level credits and query level timing. You cannot show query level credits.

There is also a lock in angle. With standard warehouses, the mental model maps to other platforms: cluster size, concurrency, queueing, idle time. With Adaptive Compute, the most important scheduling logic is Snowflake proprietary. That may be fine. Most teams are not looking to lovingly hand tune cluster topology. But if your internal platform team has built a router that assigns queries to warehouses based on fingerprints, SLAs, and chargeback tags, Adaptive Compute competes with part of that control plane.

How should you lock it down before the pilot grows legs?

Start with roles. Adaptive warehouses are still warehouses, so do not give every enthusiastic analyst the ability to create or modify them. Snowflake's CREATE WAREHOUSE docs say the account level CREATE WAREHOUSE privilege is required to create warehouses, and only SYSADMIN or higher has it by default.

A simple pattern is one owner role, one operator role, and one user role:

CREATE ROLE adaptive_wh_admin;
CREATE ROLE adaptive_wh_operator;
CREATE ROLE adaptive_wh_user;

GRANT CREATE WAREHOUSE ON ACCOUNT TO ROLE adaptive_wh_admin;

After the admin creates the warehouse, grant usage widely and modification narrowly:

GRANT USAGE ON WAREHOUSE wh_bi_prod TO ROLE adaptive_wh_user;
GRANT MONITOR ON WAREHOUSE wh_bi_prod TO ROLE adaptive_wh_operator;
GRANT OPERATE ON WAREHOUSE wh_bi_prod TO ROLE adaptive_wh_operator;
GRANT MODIFY ON WAREHOUSE wh_bi_prod TO ROLE adaptive_wh_admin;

That split matters because MODIFY can change cost affecting properties. OPERATE can change state, including warehouse operations. For adaptive warehouses, Snowflake also supports ENABLE and DISABLE; disabling rejects new jobs while already running queries continue.

ALTER WAREHOUSE wh_bi_prod DISABLE;
ALTER WAREHOUSE wh_bi_prod ENABLE;

Use this for preview blast radius. A disabled adaptive warehouse is a cleaner stop sign than dropping a warehouse that your jobs still reference.

Then add a resource monitor or budget. Snowflake says existing budgets and resource monitors work with adaptive warehouses. The product story is automatic performance. Your job is automatic regret prevention.

A practical pilot plan looks like this:

Pick 1 warehouse with a clear owner and at least 14 days of baseline history in WAREHOUSE_METERING_HISTORY.
Convert in a low traffic window, especially if long queries are already running.
Keep QUERY_THROUGHPUT_MULTIPLIER at the derived value or the default 2 for the first week unless WAREHOUSE_LOAD_HISTORY shows sustained queueing.
Do not use QUERY_THROUGHPUT_MULTIPLIER = 0 on a shared production warehouse unless a resource monitor is already attached.
Report weekly on credits, query count, average elapsed time, and average queued overload time.

That is boring FinOps. Boring is the point.

So is this the end of warehouse sizing?

For many teams, yes, eventually. Snowflake Adaptive Compute moves the warehouse decision from "what size should this be?" to "what is the largest single query we are willing to fund, and how much burst do we allow?" That is a better conversation for most data teams.

But the preview version is not a blank check. It is available in 3 AWS regions, requires Enterprise Edition or higher, excludes several warehouse types, and lacks per query credit visibility. If you own the Snowflake bill, your first move should be a measured pilot, not a fleet wide conversion script.

The best use of Adaptive Compute is not to save you from understanding cost. It is to stop spending human time on knobs that Snowflake can probably tune better than your Tuesday afternoon hunch.