Adaptive Compute¶

Adaptive Compute is a compute service focused on delivering strong performance with effortless operations. It replaces the fixed compute engine with a workload-aware one that adapts to your queries automatically. The system decides how to allocate resources for the best performance, eliminating the need for infrastructure tuning.

By automatically scaling resources and intelligently routing queries, Adaptive Compute removes the operational complexity that comes with traditional warehouse management: manual cluster sizing, disruptive upgrades, and hands-on performance tuning. It also incorporates the latest hardware and performance enhancements, so adaptive warehouses can run significantly more queries at a similar cost to Gen2.

You access Adaptive Compute through adaptive warehouses. With an adaptive warehouse, you no longer need to manage:

• Warehouse size (XSMALL, SMALL, MEDIUM, and so on).
• Multi-cluster warehouse settings.
• Query Acceleration Service settings.
• Suspend and resume policies.

To control whether an adaptive warehouse accepts new jobs, see Enable or disable an adaptive warehouse.

Snowflake handles sizing, scaling, and query routing automatically, so your team can focus on working with data rather than managing the infrastructure behind it.

All jobs across all adaptive warehouses in an account are routed to a shared pool of compute resources. This pool is dedicated to your account: it isn’t shared with other accounts in your organization and isn’t used by other warehouse types, such as standard, interactive, or Snowpark-optimized. You can still have multiple adaptive warehouses per account for grouping workloads with similar performance and cost characteristics, reporting, and governance.

Adaptive warehouses use a query-based billing model, where the cost of each query depends on factors like the amount of compute and software resources it uses. You can still reason about costs at the warehouse level, because all queries running in an adaptive warehouse add up to the total cost of that warehouse.

The same cost management tools are available:

• Budgets and resource monitors for cost governance.
• QUERY_METERING_HISTORY view for per-query credit usage.
• WAREHOUSE_METERING_HISTORY view for aggregated warehouse credit usage.

You can create new adaptive warehouses or convert existing standard warehouses to adaptive without downtime. Converting existing warehouses allows you to retain your existing chargeback and showback structures and workload segregation (analytics versus ETL, team-based warehouses, and so on). For example, the finance team might use one adaptive warehouse and the engineering team might use another.

When to use an adaptive warehouse¶

Adaptive warehouses are a good fit when you want Snowflake to handle compute scaling and tuning, and your workloads benefit from consistent performance without ongoing warehouse administration.

Consider adaptive warehouses for:

• Analytical workloads, where adaptive warehouses can deliver strong, consistent performance improvements compared with static warehouse sizing.
• Data loading pipelines, where per-query scheduling adapts well to changing ingestion parallelism.
• Mixed BI and ETL workloads, where bursty, varied query shapes are handled better than a fixed warehouse size.
• Workloads with high size variance, where queries range from XSMALL to XLARGE and benefit from per-query resource allocation.
• Reduced operational overhead, when you prefer not to manage warehouse size, multi-cluster settings, Query Acceleration Service configuration, or suspend and resume policies.
• Warehouses with occasional HTAP queries, where analytical queries account for most usage and hybrid transactional/analytical processing (HTAP) is a smaller share. You can convert to adaptive; both query types continue to run on the warehouse after conversion.

You might prefer a different warehouse type when:

• Warehouses used primarily for HTAP, where hybrid transactional/analytical processing (HTAP) accounts for most of the workload. Use a standard Gen2 warehouse instead of converting to adaptive.
• You need direct control over warehouse size and scaling policy for predictable, everyday analytics and reporting. Standard Gen2 warehouses give you full configuration control.
• You need very low latency for dashboards, applications, or other user-facing queries. Consider interactive warehouses.
• You run high-memory Snowpark or machine learning workloads on a single node. Consider Snowpark-optimized warehouses.

For supported and unsupported conversion paths, see Limitations.

Limitations¶

Adaptive warehouses require Enterprise Edition (or higher).

During Public Preview, adaptive warehouses are available in the following AWS regions: US West 2 (Oregon), EU West 1 (Ireland), and AP Northeast 1 (Tokyo).

The following conversions are also not yet supported:

• Converting to or from an X5Large or X6Large warehouse.
• Converting to or from a Snowpark-optimized or interactive warehouse.

Managing performance and throughput¶

Adaptive warehouses expose two primary properties to control performance and throughput:

• MAX_QUERY_PERFORMANCE_LEVEL
• QUERY_THROUGHPUT_MULTIPLIER

MAX_QUERY_PERFORMANCE_LEVEL¶

MAX_QUERY_PERFORMANCE_LEVEL expresses the upper bound of performance for any individual query. It’s set at the warehouse level and serves as the mechanism to allow the system to apply performance optimizations on a query if it can do so with high confidence.

The property is expressed in units of t-shirt sizes (XSMALL through X4LARGE). Each t-shirt size conveys a similar or better level of performance than its commensurate classic warehouse size.

Type:

{ XSMALL | SMALL | MEDIUM | LARGE | XLARGE | XXLARGE | XXXLARGE | X4LARGE }

Default:

XLARGE

Semantics:

• Larger values raise the upper bound, giving the system more room to apply performance optimizations when it has high confidence, at the cost of potentially higher instantaneous spend for a single query.
• Smaller values lower the upper bound, limiting how aggressively the system optimizes queries when it has high confidence.
• This value doesn’t map to a specific underlying compute configuration. It expresses only a performance level: Snowflake determines the actual resources used for each query.

Behavior:

For each query, Adaptive Compute evaluates whether it can improve performance with high confidence. When confidence is high, the system may apply performance optimizations up to MAX_QUERY_PERFORMANCE_LEVEL. When confidence is lower, the system might use less compute, even if that level is below MAX_QUERY_PERFORMANCE_LEVEL.

If the system determines that the compute needed for an optimization exceeds MAX_QUERY_PERFORMANCE_LEVEL, Snowflake caps performance at MAX_QUERY_PERFORMANCE_LEVEL.

Guidance:

Set MAX_QUERY_PERFORMANCE_LEVEL to the highest performance level you’re comfortable allowing when the system has high confidence to optimize a query. Use budgets and resource monitors to govern total spend over time.

QUERY_THROUGHPUT_MULTIPLIER¶

QUERY_THROUGHPUT_MULTIPLIER is a scale factor that controls how many queries and how much total work an adaptive warehouse can run at once, relative to a system-computed baseline for your chosen MAX_QUERY_PERFORMANCE_LEVEL.

Type:

Non-negative integer

Default:

2

Setting this value to 0 means unlimited throughput: the warehouse can use as much burst capacity as available with no cap.

Semantics:

Snowflake calculates a throughput budget from QUERY_THROUGHPUT_MULTIPLIER and MAX_QUERY_PERFORMANCE_LEVEL.

Higher values increase how many queries and how much total work can run at once, which reduces queuing at the cost of potentially higher instantaneous spend. Lower values constrain burst throughput and reduce the risk of sudden spikes in spend, but might lead to queuing.

Behavior:

Each query has an estimated amount of work it needs to run based on the determined compute configuration. Query work is fungible.

Admission control uses the throughput budget and estimated work to decide whether to start or queue each new query.

A value of N doesn’t mean exactly N queries run concurrently at MAX_QUERY_PERFORMANCE_LEVEL. Instead, it raises or lowers the overall concurrency the system targets. The actual number of concurrent queries depends on how much work each query needs relative to the budget.

Guidance:

Set QUERY_THROUGHPUT_MULTIPLIER to the aggregate amount of query processing your workload needs. Consider testing the system defaults before tuning. If you see queuing, increase QUERY_THROUGHPUT_MULTIPLIER.

Workloads with uneven load can have peaks that exceed the allotted capacity. If you’re more concerned about capping instantaneous spend, reduce QUERY_THROUGHPUT_MULTIPLIER and rely on budgets and resource monitors for absolute cost controls.

Create an adaptive warehouse¶

You can create an adaptive warehouse using Snowsight, SQL, or Cortex Code.

CREATE ADAPTIVE WAREHOUSE my_adaptive_wh;

CREATE ADAPTIVE WAREHOUSE my_adaptive_wh
  WITH MAX_QUERY_PERFORMANCE_LEVEL = XLARGE
       QUERY_THROUGHPUT_MULTIPLIER = 4;

Create an adaptive warehouse called my_adaptive_wh with
MAX_QUERY_PERFORMANCE_LEVEL set to XLARGE and
QUERY_THROUGHPUT_MULTIPLIER set to 4.

Convert a standard warehouse to an adaptive warehouse¶

You can convert a standard warehouse to adaptive using Snowsight, SQL, or Cortex Code.

ALTER WAREHOUSE my_warehouse SET WAREHOUSE_TYPE = 'ADAPTIVE';

ALTER WAREHOUSE my_warehouse SET WAREHOUSE_TYPE = 'STANDARD';

Convert my_warehouse to an adaptive warehouse.

Property behavior during conversion¶

When you convert a standard warehouse to an adaptive warehouse, the only property you must change is WAREHOUSE_TYPE. Snowflake automatically computes appropriate values for MAX_QUERY_PERFORMANCE_LEVEL and QUERY_THROUGHPUT_MULTIPLIER.

The system derives these from the existing configuration of the standard warehouse:

• Warehouse size.
• MAX_CLUSTER_COUNT (for multi-cluster warehouses).
• QAS scale factor.
• Warehouse generation (hardware/software generation).

The goal is to preserve or improve performance compared to the original standard warehouse, provide enough burst capacity for typical load spikes, and avoid requiring manual tuning when switching to adaptive.

After conversion, you can optionally override MAX_QUERY_PERFORMANCE_LEVEL and QUERY_THROUGHPUT_MULTIPLIER using ALTER WAREHOUSE. Standard warehouse properties such as WAREHOUSE_SIZE and MAX_CLUSTER_COUNT no longer apply after conversion to adaptive, and adaptive properties no longer apply after conversion back to standard.

Enable or disable an adaptive warehouse¶

You can enable or disable an adaptive warehouse using ALTER WAREHOUSE. Use this to control whether the warehouse accepts new jobs without dropping the warehouse.

Disable an adaptive warehouse:

ALTER WAREHOUSE my_warehouse DISABLE;

Enable an adaptive warehouse:

ALTER WAREHOUSE my_warehouse ENABLE;

When an adaptive warehouse is disabled, new jobs submitted to that warehouse are rejected. Queries that are already running on the warehouse can continue to completion.

When an adaptive warehouse is enabled, new jobs submitted to that warehouse are accepted for execution.

To check whether a warehouse is enabled or disabled, use SHOW WAREHOUSES. The STATE column shows ENABLED or DISABLED. If the warehouse is disabled, the DISABLED_REASONS column lists why (for example, a manual DISABLE or a resource monitor action). For how resource monitors disable adaptive warehouses and enable them again when monitor conditions clear, see Resource monitors and adaptive warehouses.

Billing and pricing¶

Adaptive warehouses use a query-based billing model. The cost of each query depends on factors like the amount of compute and software resources it uses, including the cluster sizes and additional capacity used by features like Query Acceleration Service (QAS). You aren’t charged for creating an adaptive warehouse: charges start when the first query runs.

All queries running in an adaptive warehouse add up to the total cost of that warehouse, so you can continue to use existing chargeback and showback structures. Adaptive warehouse usage is reported as part of COMPUTE in usage statements using virtual warehouse credits.

You control performance and spend primarily through:

• MAX_QUERY_PERFORMANCE_LEVEL: upper bound for performance optimizations the system applies with high confidence.
• QUERY_THROUGHPUT_MULTIPLIER: caps how much total query work can run at once.
• Budgets and resource monitors: govern total spend over time at the account or warehouse level.

Typical configuration patterns:

You can use ACCOUNT_USAGE views to retrieve granular data on credit consumption for a specific adaptive warehouse. Use QUERY_METERING_HISTORY view to view per-query credit usage, or WAREHOUSE_METERING_HISTORY view for aggregated warehouse credit usage. For a full list of relevant views, see Account and organization usage views.

For more information about compute cost, see Understanding compute cost.

SQL reference¶

CREATE ADAPTIVE WAREHOUSE¶

Creates a new adaptive virtual warehouse.

CREATE [ OR REPLACE ] ADAPTIVE WAREHOUSE [ IF NOT EXISTS ] <name>
  [ [ WITH ] adaptiveProperties ]
  [ [ WITH ] TAG ( <tag_name> = '<tag_value>' [ , ... ] ) ]
  [ objectParams ]

adaptiveProperties ::=
  COMMENT = '<string_literal>'
  MAX_QUERY_PERFORMANCE_LEVEL = { XSMALL | SMALL | MEDIUM | LARGE
                                | XLARGE | XXLARGE | XXXLARGE | X4LARGE }
  QUERY_THROUGHPUT_MULTIPLIER = <integer>

objectParams ::=
  STATEMENT_QUEUED_TIMEOUT_IN_SECONDS = <num>
  STATEMENT_TIMEOUT_IN_SECONDS = <num>

You can also create an adaptive warehouse using the standard CREATE WAREHOUSE syntax with WAREHOUSE_TYPE = 'ADAPTIVE':

CREATE [ OR REPLACE ] WAREHOUSE [ IF NOT EXISTS ] <name>
  [ [ WITH ] WAREHOUSE_TYPE = 'ADAPTIVE'
    [ adaptiveProperties ]
  ]
  [ [ WITH ] TAG ( <tag_name> = '<tag_value>' [ , ... ] ) ]
  [ objectParams ]

Required parameters¶

name

Identifier for the adaptive virtual warehouse. Must be unique for your account. Must start with an alphabetic character and can’t contain spaces or special characters unless enclosed in double quotes. See Object identifiers for details.

Optional properties¶

MAX_QUERY_PERFORMANCE_LEVEL = { XSMALL | SMALL | MEDIUM | LARGE | XLARGE | XXLARGE | XXXLARGE | X4LARGE }

Upper bound on the performance level for a single statement, expressed as a t-shirt size. Default: XLARGE.

The system applies performance optimizations up to this bound only when it has high confidence that doing so will improve query performance. Choose a value appropriate for the performance level you want when the system is highly confident it can optimize a query.

For more details, see Managing performance and throughput.

QUERY_THROUGHPUT_MULTIPLIER = <integer>

Scale factor that controls how many queries and how much total work an adaptive warehouse can run at once, relative to a system-computed baseline for MAX_QUERY_PERFORMANCE_LEVEL. Snowflake calculates a throughput budget from QUERY_THROUGHPUT_MULTIPLIER and MAX_QUERY_PERFORMANCE_LEVEL; admission control uses that budget and per-query estimated work to decide whether to start or queue each new query. A value of 0 means unlimited throughput.

Default: 2.

For more details, see Managing performance and throughput.

STATEMENT_QUEUED_TIMEOUT_IN_SECONDS = <num>

Maximum time, in seconds, a SQL statement can remain queued on the warehouse before Snowflake cancels it. See Parameters for details.

STATEMENT_TIMEOUT_IN_SECONDS = <num>

Maximum time, in seconds, a running SQL statement can run before Snowflake cancels it. See Parameters for details.

Examples¶

Create an adaptive warehouse with defaults:

CREATE ADAPTIVE WAREHOUSE my_adaptive_wh;

Create with a specific performance level:

CREATE ADAPTIVE WAREHOUSE my_adaptive_wh
  WITH MAX_QUERY_PERFORMANCE_LEVEL = XXLARGE;

Create with both properties:

CREATE ADAPTIVE WAREHOUSE my_adaptive_wh
  WITH MAX_QUERY_PERFORMANCE_LEVEL = MEDIUM
       QUERY_THROUGHPUT_MULTIPLIER = 6;

Create using the standard CREATE WAREHOUSE syntax:

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

ALTER WAREHOUSE (adaptive)¶

You can use ALTER WAREHOUSE to enable or disable an adaptive warehouse, convert a standard warehouse to adaptive, modify adaptive warehouse properties, or convert an adaptive warehouse back to standard.

Enable or disable an adaptive warehouse:

ALTER WAREHOUSE my_warehouse ENABLE;
ALTER WAREHOUSE my_warehouse DISABLE;

For more information, see Enable or disable an adaptive warehouse.

Convert a standard warehouse to adaptive:

ALTER WAREHOUSE my_warehouse SET WAREHOUSE_TYPE = 'ADAPTIVE';

Modify adaptive warehouse properties after creation or conversion:

ALTER WAREHOUSE my_adaptive_wh SET
  MAX_QUERY_PERFORMANCE_LEVEL = XLARGE
  QUERY_THROUGHPUT_MULTIPLIER = 8;

Convert an adaptive warehouse back to standard:

ALTER WAREHOUSE my_warehouse SET WAREHOUSE_TYPE = 'STANDARD';

SHOW WAREHOUSES¶

The adaptive warehouse feature introduces new columns to the SHOW WAREHOUSES command. Properties that don’t apply to adaptive warehouses are shown as NULL.

Columns specific to adaptive warehouses include:

Account and organization usage views¶

The following ACCOUNT_USAGE views are available for adaptive warehouses:

• QUERY_METERING_HISTORY view
• WAREHOUSE_METERING_HISTORY view
• QUERY_HISTORY view
• WAREHOUSE_LOAD_HISTORY view

Coming soon in ORGANIZATION_USAGE:

• QUERY_METERING_HISTORY view (organization-wide per-query credit usage; view latency may be up to 24 hours)

Use QUERY_METERING_HISTORY view to monitor per-query cost for adaptive warehouse workloads. View latency may be up to 1 hour, and each row represents credit usage for a query in a metering hour window. See - Latency for the view may be up to 1 hour. Charges accrued by a job may take… for how rows are refreshed while queries are running. For aggregated warehouse credit usage, use WAREHOUSE_METERING_HISTORY view.

The following sample query produces a time series of warehouse-level performance data for any warehouse that ran at least one query in ADAPTIVE state within a specified lookback period.

WITH adaptive_whs AS (
  SELECT DISTINCT warehouse_name
  FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY q
  WHERE q.warehouse_size = 'ADAPTIVE'
    AND q.start_time >= DATEADD(day, -7, CURRENT_DATE())
)
SELECT
  q.end_time::DATE AS ds,
  q.warehouse_name,
  IFF(q.warehouse_size = 'ADAPTIVE', 'ADAPTIVE', 'STANDARD') AS warehouse_type,
  AVG(q.total_elapsed_time) AS avg_query_time,
  AVG(q.execution_time) AS avg_exec_time,
  AVG(q.queued_overload_time) AS avg_queued_overload_time,
  AVG(q.queued_provisioning_time) AS avg_queued_provisioning_time
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY q
WHERE q.start_time >= DATEADD(day, -7, CURRENT_DATE())
  AND q.warehouse_name IN (SELECT warehouse_name FROM adaptive_whs)
GROUP BY ALL;

Bulk migration of standard warehouses to adaptive¶

If you want to migrate many standard warehouses to adaptive simultaneously, you can use the SYSTEM$BULK_UPDATE_WH function.

Parameters for SYSTEM$BULK_UPDATE_WH function

Suggested usage:

1. First, do a dry run and review the results:

   Copy codeExpand code block

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

   Show lessSee more

   Scroll to top

2. Review the output and adjust filters if necessary.

3. After verifying the dry run, call the function again using the active mode:

   Copy codeExpand code block

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

   Show lessSee more

   Scroll to top

4. Carefully review the results and any errors before repeating or broadening the migration scope.