Snowflake Adaptive Compute vs Sized Warehouses: When to Switch

Last updated: August 2026

For a decade the first real decision on a Snowflake account was a T-shirt size, then MIN_CLUSTER_COUNT, MAX_CLUSTER_COUNT, a scaling policy, an auto-suspend value, and the habit of splitting workloads across named warehouses so finance's dashboards couldn't be starved by someone's nightly rebuild. Adaptive Compute deletes all of it: Snowflake picks resources per query and you're left with two dials.

Adaptive Warehouses went GA on AWS on June 16, 2026, initially in six regions, and Snowflake's docs have since added selected Microsoft Azure and Google Cloud regions. Two gates decide this for most readers: the docs make Adaptive Compute available to accounts that are Enterprise Edition (or higher), and only in a published list of regions. If you're on Standard Edition or in AWS Mumbai, this page is a bookmark, not a plan.

This is a decision page, not a feature tour: which workload shapes should move, the create/convert/rollback DDL, and what you give up, mostly the cost-attribution queries your chargeback runs on. It's the 2026 companion to our Snowflake Warehouse Sizing Guide, still correct for accounts that can't switch.

Who can actually turn this on: the edition and region gates

Snowflake's docs are blunt: Adaptive Compute is "Available to accounts that are Enterprise Edition (or higher)" in select AWS, Azure and Google Cloud regions. Vendor recaps sometimes write this as "Enterprise+ accounts," which reads like a new SKU but isn't one; there's no Enterprise+ edition on Snowflake's pricing page. It means Enterprise and above; Standard is out.

Region availability is the gate that actually stops people. It's narrower than Snowflake's overall footprint, and the feature is unavailable in the People's Republic of China.

Treat that as a snapshot: the list keeps expanding, and the docs are the only current source.

What actually changes when a warehouse becomes adaptive

Conversion is a property change, not a rebuild. The warehouse keeps its name, grants, resource monitor and every reference in your dbt profiles, Airflow connections and BI gateways. A block of config just stops existing.

• Gone: warehouse size. WAREHOUSE_SIZE can't be set on an Adaptive Warehouse.
• Gone: multi-cluster settings. Nor can MIN_CLUSTER_COUNT, MAX_CLUSTER_COUNT or SCALING_POLICY.
• Gone: Query Acceleration Service config. QAS is system-managed and its credits fold into compute.
• Changed: the billing clock. You aren't charged for creating an Adaptive Warehouse; charges start when the first query runs.
• New: MAX_QUERY_PERFORMANCE_LEVEL. Ceiling for any single query, in T-shirt sizes XSMALL to X4LARGE. Default XLARGE.
• New: QUERY_THROUGHPUT_MULTIPLIER. Integer scale factor for how much total work runs at once. Default 2. Zero means unlimited.
• Kept: statement timeouts. STATEMENT_TIMEOUT_IN_SECONDS and STATEMENT_QUEUED_TIMEOUT_IN_SECONDS still apply, and matter more than before.

The structural change most people miss is underneath: all jobs across all Adaptive Warehouses in an account are routed to one shared pool. It's dedicated to your account and unused by standard, interactive or Snowpark-optimized warehouses, but your adaptive warehouses are no longer separate machines.

Snowflake Adaptive Compute vs warehouse sizing: which workloads should move

Most coverage describes the feature and stops. The useful question is which warehouses should stay as they are.

A mixed account is fine and probably correct: converting the BI and ELT warehouses while leaving the Snowpark-optimized and HTAP ones sized is a supported end state, not a half-finished job.

The migration DDL: create, convert, bulk-convert

First, snapshot the config you're about to lose. On rollback you'll want the original numbers, not an argument about what reporting_wh was.

CREATE TABLE IF NOT EXISTS ops.admin.warehouse_config_snapshot (
    captured_at    TIMESTAMP_LTZ,
    warehouse_name STRING,
    config         VARIANT
);

SHOW WAREHOUSES;

INSERT INTO ops.admin.warehouse_config_snapshot (captured_at, warehouse_name, config)
SELECT
    CURRENT_TIMESTAMP(),
    "name",
    OBJECT_CONSTRUCT(
        'type',              "type",
        'size',              "size",
        'min_cluster_count', "min_cluster_count",
        'max_cluster_count', "max_cluster_count",
        'scaling_policy',    "scaling_policy",
        'auto_suspend',      "auto_suspend",
        'auto_resume',       "auto_resume"
    )
FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()));

Snowflake supports a dedicated CREATE ADAPTIVE WAREHOUSE command as well as the familiar CREATE WAREHOUSE grammar with WAREHOUSE_TYPE = 'ADAPTIVE'. Both produce the same object; use whichever your provisioning code already speaks.

-- New adaptive warehouse on the defaults
-- (MAX_QUERY_PERFORMANCE_LEVEL = XLARGE, QUERY_THROUGHPUT_MULTIPLIER = 2)
CREATE ADAPTIVE WAREHOUSE bi_adaptive_wh;

-- New adaptive warehouse with explicit bounds
CREATE ADAPTIVE WAREHOUSE elt_adaptive_wh
  WITH MAX_QUERY_PERFORMANCE_LEVEL = LARGE
       QUERY_THROUGHPUT_MULTIPLIER = 4;

-- Same object through the standard CREATE WAREHOUSE grammar
CREATE WAREHOUSE elt_adaptive_wh_alt
  WITH WAREHOUSE_TYPE = 'ADAPTIVE'
       MAX_QUERY_PERFORMANCE_LEVEL = LARGE
       QUERY_THROUGHPUT_MULTIPLIER = 4;

-- Convert an existing sized warehouse in place. Online, no downtime.
ALTER WAREHOUSE reporting_wh SET WAREHOUSE_TYPE = 'ADAPTIVE';

-- Retune after conversion
ALTER WAREHOUSE reporting_wh
  SET MAX_QUERY_PERFORMANCE_LEVEL = XLARGE
      QUERY_THROUGHPUT_MULTIPLIER = 6;

On conversion you only change WAREHOUSE_TYPE. Snowflake derives starting values for both adaptive properties from the existing size, MAX_CLUSTER_COUNT, QAS scale factor and hardware generation, aiming to preserve or improve on what the sized warehouse did. Week one is measurement, not tuning.

For fleets, SYSTEM$BULK_UPDATE_WH takes a property name, a new value, a JSON filter over warehouse properties and an execution mode; the docs also describe a tag filter, though the published examples use the four-argument form below. Run DRY_RUN first; the filter matches more than you expect.

-- Nothing changes; you get the list of candidate warehouses
SELECT SYSTEM$BULK_UPDATE_WH(
  'WAREHOUSE_TYPE',
  'ADAPTIVE',
  '{"WAREHOUSE_TYPE": "STANDARD"}',
  'DRY_RUN'
);

-- Only after you have read and agreed with the dry-run output
SELECT SYSTEM$BULK_UPDATE_WH(
  'WAREHOUSE_TYPE',
  'ADAPTIVE',
  '{"WAREHOUSE_TYPE": "STANDARD"}',
  'ACTIVE'
);

Rollback works, and there's a window where you pay for both

The reversal is symmetric and documented, which is the best reason to treat this as low risk: set WAREHOUSE_TYPE back to 'STANDARD'. Conversion either way is online, with no downtime and no interruption to running queries.

-- Adaptive back to standard, online
ALTER WAREHOUSE reporting_wh SET WAREHOUSE_TYPE = 'STANDARD';

-- Adaptive properties stop applying. Restore the sized config explicitly
-- from the snapshot you took before migrating.
ALTER WAREHOUSE reporting_wh SET
    WAREHOUSE_SIZE    = 'LARGE'
    MIN_CLUSTER_COUNT = 1
    MAX_CLUSTER_COUNT = 3
    SCALING_POLICY    = 'STANDARD'
    AUTO_SUSPEND      = 60
    AUTO_RESUME       = TRUE;

SHOW WAREHOUSES LIKE 'REPORTING_WH';

The cost trap. During conversion, running queries finish on the old compute while new queries start on the new, and Snowflake's docs say plainly that while both are alive you are charged for both. Rolling back is worse: going adaptive to standard, the warehouse does not automatically suspend during that overlap. Flip mid-batch with a 40-minute MERGE in flight and you pay double for 40 minutes, then keep paying for an un-suspended standard warehouse. Convert in a quiet window.

Two conversion paths don't exist yet in either direction: X5LARGE and X6LARGE, and Snowpark-optimized or interactive warehouses.

What you give up: the cost attribution queries that used to work

This is the part that costs real days. Adaptive Warehouses bill per query, so per-query credits are better than before. But they arrive in a different view, and two objects your FinOps queries use go quiet.

Here's Snowflake's documented idle-cost query, and why it stops meaning anything.

-- Standard warehouses: works. Adaptive warehouses: idle_cost is NULL,
-- because CREDITS_ATTRIBUTED_COMPUTE_QUERIES is not populated for them.
SELECT
    warehouse_name,
    SUM(credits_used_compute)
      - SUM(credits_attributed_compute_queries) AS idle_cost
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE start_time >= DATEADD('days', -10, CURRENT_DATE())
  AND end_time < CURRENT_DATE()
GROUP BY warehouse_name;

The replacement is cleaner: per-query credits arrive with the query tag and role attached, so chargeback by team no longer needs a warehouse-per-team convention.

SELECT
    warehouse_name,
    role_name,
    query_tag,
    DATE_TRUNC('day', query_metering_hour)  AS usage_day,
    COUNT(DISTINCT query_id)                AS queries,
    SUM(credits_used_compute)               AS credits_compute,
    SUM(credits_used_cloud_services)        AS credits_cloud_services,
    SUM(credits_used)                       AS credits_total
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_METERING_HISTORY
WHERE query_metering_hour >= DATEADD('day', -30, CURRENT_DATE())
GROUP BY ALL
ORDER BY credits_total DESC;

One caveat: at publication the QUERY_METERING_HISTORY reference page carries a narrower availability note than the Adaptive Compute page it belongs to. Row-count it in your own region first.

What you give up: warehouse-level isolation

Sized warehouses gave you physical isolation for free: if a Tableau extract went sideways on MARKETING_WH, the worst case was a bigger bill and a queue there. Adaptive warehouses route into one account-level pool, so isolation becomes a policy question. The replacements are still per-warehouse.

• MAX_QUERY_PERFORMANCE_LEVEL is your per-query ceiling. Set it lower on warehouses whose queries should never take a large slice, whatever the optimizer thinks it can do.
• QUERY_THROUGHPUT_MULTIPLIER is your concurrency budget. Lower values constrain burst throughput and reduce spend spikes at the cost of queuing. This is the new MAX_CLUSTER_COUNT conversation.
• STATEMENT_QUEUED_TIMEOUT_IN_SECONDS matters more. Admission control queues instead of spinning a cluster, so an unset queue timeout turns contention into an invisible latency problem.
• Resource monitors disable rather than suspend. When an Adaptive Warehouse is disabled, new jobs submitted to it are rejected and queries already running continue to completion. You can flip the same switch manually with ALTER WAREHOUSE my_wh DISABLE; and ALTER WAREHOUSE my_wh ENABLE;, with STATE and DISABLED_REASONS in SHOW WAREHOUSES recording what happened.

If your isolation model was really a political model, that a named warehouse gave a team a number they owned, that survives. What doesn't is the assumption that a bad query on one warehouse can't affect latency on another.

Tuning the two dials you have left

MAX_QUERY_PERFORMANCE_LEVEL is not a size. Snowflake is explicit that it doesn't map to a specific compute configuration; it's a ceiling, and the system only pushes toward it on high confidence. Raising it doesn't guarantee spend, it grants permission to spend.

The cost trap is on the other dial. Setting QUERY_THROUGHPUT_MULTIPLIER = 0 to "fix queuing" doesn't raise the cap, it removes it: zero means unlimited throughput, and the warehouse will use as much burst capacity as is available. On a Monday-morning dashboard stampede that's the last thing you want. Raise the integer and watch instead.

Diagnose with WAREHOUSE_LOAD_HISTORY, which Snowflake points at for exactly this decision. Queuing means raise QUERY_THROUGHPUT_MULTIPLIER. Slow queries with no queuing means raise MAX_QUERY_PERFORMANCE_LEVEL. Getting those backwards is the most common way to spend more and go no faster.

Snowflake's performance numbers, and how to run your own comparison

Snowflake has published a price-performance figure for Adaptive Compute. It's a vendor benchmark on a vendor workload, so here it is with attribution rather than as a claim about your account.

• Snowflake, June 2026: 1.2x better price-performance than Gen2 standard warehouses, measured on the TPC-DS 10TB Concurrency Benchmark.
• Everything else you'll see quoted: Snowflake also describes gains on analytical, high-concurrency and DML-heavy workloads. Those headline multipliers move between blog posts and product refreshes, so read them off the current announcement rather than a second-hand recap.

TPC-DS rewards engines that are good at large joins over clean, evenly distributed data, which isn't what most accounts look like at 09:00 on a Tuesday. Conversion is online and reversible, so your own comparison is cheap: convert one warehouse, leave it a full business cycle, compare.

SELECT
    q.warehouse_name,
    q.warehouse_type                              AS wh_mode,
    q.end_time::DATE                              AS ds,
    COUNT(*)                                      AS queries,
    AVG(q.total_elapsed_time)                     AS avg_total_ms,
    AVG(q.execution_time)                         AS avg_exec_ms,
    AVG(q.queued_overload_time)                   AS avg_queued_overload_ms,
    APPROX_PERCENTILE(q.total_elapsed_time, 0.95) AS p95_total_ms
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY q
WHERE q.start_time >= DATEADD('day', -30, CURRENT_DATE())
  AND q.warehouse_name = 'REPORTING_WH'
GROUP BY ALL
ORDER BY ds;

Pair that with daily credits from WAREHOUSE_METERING_HISTORY and you have the only benchmark that matters: credits per unit of work, before and after, over the same weekday mix. If queued_overload_time climbs after conversion, your throughput multiplier is the problem, not the feature.

A migration sequence that finance will sign off on

• Confirm both gates, then inventory the exclusions: every X5LARGE, X6LARGE, Snowpark-optimized, interactive and HTAP-heavy warehouse is out.
• Fix the FinOps queries first. Grep cost dashboards, dbt exposures and scheduled reports for QUERY_ATTRIBUTION_HISTORY, CREDITS_ATTRIBUTED_COMPUTE_QUERIES and any warehouse_size logic. Rewrite onto QUERY_METERING_HISTORY while the old data still validates the new query.
• Snapshot warehouse config. Ten minutes now versus reconstructing a scaling policy from memory during an incident.
• Convert one warehouse with a well-understood workload, then leave it alone for a full business cycle. Tuning on day two is tuning against noise.
• Compare credits per unit of work, then queuing, and decide from the numbers whether to widen, adjust a dial, or roll back.
• Expand with SYSTEM$BULK_UPDATE_WH, dry run first, one cost centre at a time, with a budget and resource monitor on every adaptive warehouse before you widen.

Step two is the one people skip. Nothing errors when attribution goes NULL: the dashboard renders, the numbers quietly get smaller, and somebody notices six weeks later in a quarterly review.

Does warehouse sizing still matter in 2026?

Yes, for more accounts than the launch coverage suggests. Snowflake Adaptive Compute vs warehouse sizing only has a new answer if you're on Enterprise Edition or higher, in a listed region, and off the exclusion list. Everyone else is still picking a size, a cluster count and a scaling policy. And even after migrating, sizing judgement is the mental model behind MAX_QUERY_PERFORMANCE_LEVEL, which is expressed in T-shirt sizes for a reason.

On the other side of either gate, our Snowflake Warehouse Sizing Guide is still the working document, and the Snowflake Cost Optimization Guide covers the levers that apply whatever the warehouse type. Adaptive Compute makes compute allocation somebody else's problem. It does not make a full table scan cheaper.