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 can improve compute efficiency for some workload patterns, while others may consume more credits. The outcome depends on workload characteristics and configuration, which is why testing before migration is important.
Here is what changed and how to tell which side of the line your workload falls on.
Table of Contents
- How Adaptive Warehouses Actually Work
- What Changed at General Availability
- Gen1 vs. Gen2 vs. Adaptive: The Actual Differences
- The Two Settings That Decide Your Bill
- What Happened to Our Original Prediction
- What to Evaluate Before Adopting Adaptive Compute
- Running Adaptive Warehouses and Keebo in the Same Account
- Snowflake Adaptive Warehouse FAQs
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. But the traditional fixed warehouse size and associated hourly credit rate are replaced by query-level compute consumption.
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 updating up to an hour after 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.
| Gen1 | Gen2 | Adaptive | |
|---|---|---|---|
| Compute Management | Managed by you | Managed by you | Snowflake managed |
| Cost Model | Warehouse uptime billed per-second with a 1-minute minimum charge | Warehouse uptime billed per-second with a 1-minute minimum charge | Compute each query consumes |
| Credit Rate | 1.0x baseline | 1.35x on AWS and GCP, 1.25x on Azure | No published per-hour rate |
| Idle Time | Billed for running compute | Billed for running compute | Not billed |
| Sizing Control | Fixed size you pick | Fixed size you pick | Per-query ceiling you cap |
| Horizontal Scaling | Multi-cluster min and max | Multi-cluster min and max | Automated, within the MAX_QUERY_PERFORMANCE_LEVEL x QUERY_THROUGHPUT_MULTIPLIER budget |
| Size Range | X-Small to 6X-Large | X-Small to 4X-Large | X-Small to 4X-Large |
| Edition Required | Any, Enterprise for multi-cluster | Any, Enterprise for multi-cluster | Enterprise or higher |
| Region Coverage | All regions | Most regions | Limited regions |
| Ideal Workload Types | Scheduled ETL, batch processing, fixed reporting workloads | Enterprise BI, data engineering, analytics applications, production workloads | Ad hoc analytics, unpredictable queries, large analyst populations, mixed workloads |
| Primary Limitation | Can lead to over-provisioning or idle compute | Still requires humans to size and tune warehouses | You have less direct control over compute decisions |
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 offers improved performance at a 1.35x credit rate on AWS and GCP. Under our assumptions, the higher credit rate is offset when total runtime decreases by more than 25.93%. We worked through that math in our Gen1 vs. Gen2 breakdown.
The Two Settings That Decide Your Bill
Adaptive Compute replaces traditional warehouse sizing and configuration controls with two primary settings that influence performance and compute consumption.
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.
In our independent testing, increasing the multiplier from 2 to 8 doubled compute consumption while reducing runtime by only a few seconds for the workload tested. This illustrates why the relationship between configuration and consumption should be evaluated against actual workload performance.
Snowflake documents three starting patterns:
| Workload Profile | Performance Level | Throughput Multiplier |
|---|---|---|
| Latency-sensitive | X-Large or higher | Higher |
| Cost-sensitive, high throughput | Medium to Large | Medium |
| Tightly budgeted | Lower | Lower, with strict budgets |
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.
These benchmarks highlight improvements in price-performance, particularly for workloads that benefit from higher throughput. However, improved throughput at a similar cost does not necessarily translate into lower total credit consumption. Organizations should evaluate both performance and consumption against their own workload requirements.
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 evaluating Adaptive Compute should distinguish between improvements in price-performance and reductions in total credit consumption. The two do not necessarily move together. The initial preview blog highlighted Pfizer’s experience. As with other performance-focused case studies, the results should be evaluated separately from potential reductions in total compute consumption.
One shared policy could lead to over-provisioning. 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. Our original concern was about how the configured ceiling could influence compute allocation. The router optimizes query execution within the limits established by those settings, making configuration an important part of managing the performance and consumption trade-off.
The management considerations have changed. 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 to Evaluate Before Adopting Adaptive Compute
Snowflake now offers standard Gen1, standard Gen2, Snowpark-optimized, Interactive, and Adaptive warehouses. Every workload in your account needs an answer to four questions:
- Which warehouse type fits this workload’s shape?
- What performance ceiling does it actually need?
- What concurrency multiplier matches its arrival pattern?
- 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. These changes can affect the economics of a workload over time, making continuous monitoring and optimization important.
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.
| Workload Pattern | Recommended Solution | Why |
|---|---|---|
| Spiky/idle-heavy, bursty, mixed BI/ETL, unpredictable demand with strict performance SLAs which justify high spending periods | Adaptive Compute | Shared-pool allows for high throughput with minimal compute provisioning time. |
| Predictable or steady, core BI/analytics/reporting | Standard Warehouse + Keebo | For highly utilized workloads, standard warehouses with autonomous optimization may offer favorable compute economics. Keebo applies configurable optimization guardrails to help maintain workload performance requirements. |
Adaptive Compute manages query execution within converted warehouses, sizing and dispatching queries against the shared pool. Standard warehouses continue to operate under their existing configuration and management model.
Keebo complements Snowflake’s native capabilities by autonomously optimizing standard warehouses and providing actionable workload intelligence across warehouse and query behavior.
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';
