Snowflake Gen2 vs Adaptive Warehouses: Decide From Your Query History

Short answer: neither is cheaper by default. Gen2 standard warehouses keep the same sizing model on Snowflake's next-generation compute at a different credit rate, so they save money only when queries finish enough faster to offset it. Adaptive warehouses drop sizing, multi-cluster and suspend settings and bill per query, so they suit bursty, uneven workloads better than a steady batch. Your ACCOUNT_USAGE history can tell you which pattern you have before you convert anything.

Facts here are from Snowflake's documentation for Gen2 standard warehouses and Adaptive warehouses, checked 27 October 2026. This is a method, not a lab: I have no benchmark of your workload, and vendor and third-party benchmarks of either option use workloads that are not yours.

What each option changes

New warehouses default to Gen2 where it is available. Gen2 consumes credits at its own rate, listed in Snowflake's Service Consumption Table. New Gen2 warehouses also have Query Acceleration Service on by default with a scale factor of 2, which can add credits on its own.

Four checks before you convert

Run these against SNOWFLAKE.ACCOUNT_USAGE for the last 30 days. Views can lag by up to a few hours.

1. Where the credits go

SELECT warehouse_name,
       SUM(credits_used_compute) AS compute_credits
FROM snowflake.account_usage.warehouse_metering_history
WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP())
GROUP BY 1 ORDER BY 2 DESC;

Start with the two or three warehouses that make up most of the spend. A warehouse that costs little is not worth a migration.

2. Idle time you pay for

WITH metered AS (
  SELECT warehouse_name, SUM(credits_used_compute) AS metered
  FROM snowflake.account_usage.warehouse_metering_history
  WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP()) GROUP BY 1
), attributed AS (
  SELECT warehouse_name, SUM(credits_attributed_compute) AS attributed
  FROM snowflake.account_usage.query_attribution_history
  WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP()) GROUP BY 1
)
SELECT m.warehouse_name, m.metered, a.attributed,
       ROUND(100 * (1 - a.attributed / NULLIF(m.metered, 0)), 1) AS pct_not_attributed
FROM metered m LEFT JOIN attributed a USING (warehouse_name)
ORDER BY m.metered DESC;

Credits not attributed to any query are mostly a warehouse running with nothing to do: waiting for auto-suspend, or kept warm between sparse queries. A high share is the clearest signal that per-query billing could help. Before switching, try a shorter AUTO_SUSPEND, which is free to test and easy to undo.

3. Spills and pruning

SELECT warehouse_name, warehouse_size,
       COUNT(*) AS queries,
       SUM(IFF(bytes_spilled_to_remote_storage > 0, 1, 0)) AS remote_spills,
       SUM(IFF(bytes_spilled_to_local_storage > 0, 1, 0)) AS local_spills,
       ROUND(AVG(partitions_scanned / NULLIF(partitions_total, 0)), 2) AS avg_scan_ratio,
       ROUND(MEDIAN(execution_time) / 1000, 1) AS median_exec_s
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP())
  AND warehouse_name IS NOT NULL
GROUP BY 1, 2 ORDER BY queries DESC;

Remote spills mean a query ran out of memory and local disk; it will be slow on any warehouse type until the query or the size changes. A scan ratio near 1 on large tables means pruning is not working, and no compute option fixes reading every partition. Fix those queries first, or the comparison you run next will mostly measure them.

4. Queuing

SELECT warehouse_name,
       ROUND(SUM(queued_overload_time) / 1000 / 60, 1) AS queued_minutes,
       ROUND(SUM(execution_time) / 1000 / 60, 1) AS exec_minutes
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP())
GROUP BY 1 ORDER BY queued_minutes DESC;

Queuing during peaks on a single-cluster warehouse is the case multi-cluster and Adaptive were both built for. If you already run multi-cluster with a high maximum and short peaks, Adaptive may cover the same peaks with less idle capacity. Steady, sequential batch with little queuing and little idle time is the pattern most likely to cost more on per-query billing.

Test one warehouse, not the account

1. Pick one warehouse with a clear pattern from the checks above.
2. Record a week of baseline: credits from WAREHOUSE_METERING_HISTORY, and median and p95 execution and queued time from QUERY_HISTORY.
3. Convert while the warehouse is suspended. Converting a running warehouse charges for old and new compute while running queries finish.
4. For Gen2: ALTER WAREHOUSE wh SET RESOURCE_CONSTRAINT = STANDARD_GEN_2;. For Adaptive: ALTER WAREHOUSE wh SET WAREHOUSE_TYPE = 'ADAPTIVE';, then read per-query credits in QUERY_METERING_HISTORY.
5. Compare the same week shape: credits per day and the same latency percentiles. Both conversions can be reversed with the same command.

On Adaptive, set a budget or resource monitor before the test. Snowflake documents no credit cap parameter on the warehouse itself, and a higher QUERY_THROUGHPUT_MULTIPLIER reduces queuing by allowing more spend at once.

For the broader Snowflake picture (clustering, workload isolation, concurrency), see the Snowflake performance page. The same evidence-first method applies to analytical workloads on other engines; see OLAP and analytical performance.