Snowflake Adaptive Warehouses: What We Know, and How It May Affect Your Bill

Snowflake Adaptive Compute reached general availability on June 16, 2026. Adaptive warehouses are no longer a preview curiosity. You can turn one on today.

We wrote the first version of this post when Adaptive Compute was announced. Back then we predicted that it would simplify operations and that most teams should not expect a smaller bill. A year of later, that prediction holds up about half the time.

The half it gets wrong matters. Adaptive warehouses might save money on some workload shapes. They cost meaningfully more on others. The difference can be tested but it is not very predictable, due to the dynamic nature of Adaptive compute, although you can test it before you migrate.

Here is what changed and how to tell which side of the line your workload falls on.

How Adaptive Warehouses Actually Work

Every adaptive warehouse in your account draws from one shared pool of compute dedicated to that account. Snowflake inspects each query, decides how much compute it needs, and dispatches it against the pool.

The warehouse object survives. It still shows up in your metering views, your budgets, and your chargeback reports. What disappears is the fixed size behind it and the hourly cost rate.

What Changed at General Availability

A few things are different from the preview version most people read about.

Adaptive Compute launched at GA on AWS across six regions: US West 2, US East 2, EU West 1, EU Central 1, AP Northeast 1, and AP Southeast 2. Coverage has widened since to include select Microsoft Azure and Google Cloud regions. Check current region support before you plan a migration.

Query-level cost visibility shipped. During preview you could not attribute credits to individual queries. Snowflake now exposes per-query credit usage, with metering views lagging up to an hour behind execution.

Limitations to be aware of: You still need Enterprise Edition or higher. You cannot convert 5X-Large warehouses, 6X-Large warehouses, Snowpark-optimized warehouses, or interactive warehouses.

Gen1 vs. Gen2 vs. Adaptive: The Actual Differences

Adaptive warehouses are a new compute option in your account, alongside standard Gen1, standard Gen2, and Snowpark-optimized warehouses. Here is how the three general-purpose types compare.

Two rows carry most of the decision.

Look at what you bill for. Gen1 and Gen2 charge for a warehouse being awake. Adaptive charges for work performed.

Then look at idle time. If your warehouses run hot from 9 a.m. to 6 p.m., Adaptive has nothing to give back. If they wake up for a query every eleven minutes, it has plenty.

Gen2 is a different trade entirely. It buys speed at a 1.35x credit rate, and it only pays for itself when total uptime falls more than 25.93%. We worked through that math in our Gen1 vs. Gen2 breakdown.

The Two Settings That Decide Your Bill

Adaptive Compute removed the size picker, multi-cluster and auto-suspend settings and replaced them with two knobs. Both cost money when you set them wrong.

MAX_QUERY_PERFORMANCE_LEVEL caps how much compute any single query can claim. It accepts the familiar sizes, from X-Small to 4X-Large, and defaults to X-Large. Set it low and large queries start failing. Set it high and the router spends against the ceiling you granted.

QUERY_THROUGHPUT_MULTIPLIER controls concurrent capacity relative to a system baseline. It defaults to 2. Setting it to 0 removes the limit entirely.

The second parameter is the expensive one. In independent testing, moving the multiplier from 2 to 8 doubled cost and bought back only seconds of runtime. The relationship between the setting and your bill is not linear.

Snowflake documents three starting patterns:

The sizing decision did not go away. It changed shape. You now pick a ceiling and a concurrency factor instead of a fixed size, and both land on your invoice.

What Snowflake’s Benchmarks Found

Snowflake published two sets of numbers at GA.

Against Generation 2 standard warehouses, Snowflake reports 1.2 times better price-performance on a TPC-DS 10TB concurrency benchmark.

Against Generation 1 standard warehouses, measured on a mix of TPC-DS and internal benchmarks in May 2026, Snowflake reports:

• Up to 1.6 times faster on analytical workloads
• Up to 2.2 times higher throughput on highly concurrent operational analytics
• Up to 3.5 times faster on data manipulation language (DML) work such as transformations and ingestion

One customer reported up to 30% lower query latency at comparable cost, using fewer warehouses.

Note the framing. Snowflake’s own language describes running significantly more queries at a similar cost to Gen2. That is throughput per dollar, not fewer dollars. Those are different outcomes, and only one of them shows up on your invoice.

What Happened to Our Original Prediction

We made three calls in the first version of this post. GA settled all three.

Operations get simpler. Correct. Capacity planning collapses into two parameters. That is a real improvement, and teams feel it in week one.

Costs will not fall automatically. Mostly correct. No benchmark found a broad, workload-agnostic saving. Snowflake’s own claim is price-performance, not price. Teams that migrate expecting a smaller bill by default are still going to be disappointed. The initial preview blog highlighted Pfizer’s experience. The word “cost” does not appear even once in the entire case study.

One opaque policy will oversize everyone’s queries. Partly wrong. This was our sharpest concern, and the router turned out better than we expected. Plan-aware sizing genuinely avoids over-provisioning on DML and single-query work, and the benchmarks show it. What we got right was the mechanism, if not the severity. The router optimizes for speed within the ceiling you set. Grant it a big ceiling and it will use one.

The control problem did not disappear. It moved. You used to pick a size per warehouse. You now pick a performance ceiling and a concurrency multiplier per warehouse, and you pick which of four warehouse types each workload runs on.

What You Still Have to Decide

Snowflake now offers standard Gen1, standard Gen2, Snowpark-optimized, Interactive, and Adaptive warehouses. Every workload in your account needs an answer to four questions:

1. Which warehouse type fits this workload’s shape?
2. What performance ceiling does it actually need?
3. What concurrency multiplier matches its arrival pattern?
4. When does the answer stop being true?

The fourth question is the one nobody plans for. A dbt schedule change alters your arrival pattern. A new dashboard shifts your concurrency profile. Data growth moves your cache hit rate. Any of those can push a warehouse from the winning column into the losing one, and nothing in Snowflake tells you it happened.

Running Adaptive Warehouses and Keebo in the Same Account

Adopting Adaptive Compute is not an all-or-nothing migration, and it does not replace what Keebo does. Conversion happens one warehouse at a time, so almost every account that adopts Adaptive ends up mixed. Some workloads move, most stay on standard warehouses, and the two run side by side indefinitely.

Adaptive Compute governs what happens inside a converted warehouse. It sizes and dispatches each query against the shared pool, and it does nothing at all for the standard warehouses next to it.

Keebo autonomously optimizes Snowflake warehouses and provides actionable workload intelligence.

Snowflake Adaptive Warehouse FAQs

Will Adaptive Warehouses Cut My Snowflake Bill?

Only on the right workload shape. Bursty concurrency, DML-heavy pipelines, and over-provisioned multi-cluster warehouses tend to save. Sustained batch, sequential streams, and sparse traffic tend to cost more.

Can I Switch Back to a Standard Warehouse?

Yes. Snowflake bills both types until in-flight queries drain.

-- Convert a standard warehouse to adaptive ALTER WAREHOUSE analytics_wh SET WAREHOUSE_TYPE = 'ADAPTIVE';  -- Convert back ALTER WAREHOUSE analytics_wh SET WAREHOUSE_TYPE = 'STANDARD';