Snowflake quietly shipped a second generation of its compute engine, and most teams have not noticed they are now paying for the choice. Generation 2 standard warehouses (Gen2) run on faster underlying hardware with software optimizations to delete, update, merge, and table-scan operations, and Snowflake says the majority of queries finish faster as a result. That sounds like a free win, but it is not free: Gen2 bills at a higher credit rate than Gen1, and depending on when and where your account was created, you may have to ask for it explicitly with a SQL clause. The question that decides whether Gen2 helps or hurts your bill: does the speedup beat the rate increase for your workload?
This guide is for the data engineer or FinOps owner who runs the warehouses and signs off on the credit spend. If you have a heavy data-engineering pipeline or a wall of analytics queries, Gen2 is the single most consequential warehouse setting you are probably not thinking about.
What actually changed under the hood?
A Snowflake virtual warehouse is just a cluster of compute that runs your queries, sized from XS up to 6XL, and you pay credits per second it runs. Gen1, the original engine, is what every account has used for years. Gen2 keeps the same sizes and the same per-second model but swaps in faster hardware and engine improvements aimed squarely at the operations that dominate modern pipelines: the DML that rewrites tables and the scans that feed big aggregations.
Snowflake is careful, and you should be too: the exact gain depends on your configuration and workload, and the docs explicitly tell you to test it rather than assume. Gen2 is not available for the two largest sizes, X5LARGE and X6LARGE, and it applies only to standard warehouses, not Snowpark-optimized ones. There is one genuine bonus that ships with it: a new Gen2 warehouse turns on the Query Acceleration Service by default with a scale factor of 2, which lets bursty queries borrow extra serverless compute for the heavy parts.
How do you actually get a Gen2 warehouse?
This is where teams trip, because the default depends on your account's age and region. For new organizations created after the mid-2025 rollout dates in supported regions, standard warehouses now default to Gen2. For everyone else, if you do not specify a generation when you create a warehouse, you still get Gen1. So an older account is almost certainly running Gen1 everywhere and paying Gen1 speeds without realizing there is a switch.
The switch is one clause. The recommended syntax is the GENERATION parameter on CREATE WAREHOUSE:
-- Create a new Gen2 standard warehouse. Without this clause an
-- older account silently gets Gen1.
CREATE OR REPLACE WAREHOUSE etl_wh
GENERATION = '2'
WAREHOUSE_SIZE = MEDIUM;You can flip an existing warehouse in place, running or suspended, with a single ALTER:
-- Convert an existing warehouse to Gen2 without recreating it.
ALTER WAREHOUSE etl_wh SET GENERATION = '2';One billing gotcha worth knowing before you convert a live warehouse: if you convert it while queries are running, the in-flight queries finish on Gen1 compute while new queries start on Gen2, and you are billed for both sets of compute until the old queries drain. Convert while suspended to avoid the double charge, or convert while running if you care more about zero downtime than a few minutes of overlap. Note also that the GENERATION clause is not in Snowsight yet, so this is a SQL-only change today, and the setting shows up in the resource_constraint column of SHOW WAREHOUSES:
-- Confirm which generation each warehouse is running.
SHOW WAREHOUSES;
-- look at the "resource_constraint" column: STANDARD_GEN_2 means Gen2.Does Gen2 actually save you money?
This is the only question that matters, and the honest answer is: it depends, so measure. Gen2 finishes faster, which means fewer credit-seconds per query, but it charges a higher credit rate per second than Gen1, with the exact rates published in Snowflake's Service Consumption Table. The maths is a race between two effects.
| Factor | Pushes cost down | Pushes cost up |
|---|---|---|
| Query runtime | Faster, so fewer seconds billed | - |
| Credit rate | - | Higher per-second rate than Gen1 |
| Concurrency | More queries done per running hour | - |
| Auto-suspend gaps | Shorter active windows | - |
The break-even logic is simple. If Gen2 cuts your runtime by more than the rate premium, you win. A warehouse running heavy merges and large scans, exactly what Gen2 was tuned for, is the most likely winner. A warehouse running tiny, cheap queries where the bottleneck is not compute may see the rate increase swamp a speedup it barely benefits from. The right move is to A/B it: run a representative workload on a Gen1 and a Gen2 copy, then compare credits in ACCOUNT_USAGE:
-- Compare credits burned per warehouse over the last 7 days.
SELECT warehouse_name,
SUM(credits_used) AS credits
FROM snowflake.account_usage.warehouse_metering_history
WHERE start_time >= DATEADD('day', -7, CURRENT_TIMESTAMP())
GROUP BY warehouse_name
ORDER BY credits DESC;Pair that with QUERY_HISTORY to confirm the runtime actually dropped, not just the credit line. The discipline here is the same one from the warehouse sizing guide: never assume the faster-or-newer option is cheaper until you have the two numbers side by side.
What should you do this week?
If you run an older account, you are almost certainly on Gen1 everywhere and leaving a possible speedup on the table, so this is worth ten minutes. The plan:
- Find your heaviest warehouse. The one with the most credits in the query above, usually an ETL or transformation warehouse doing merges and big scans, is the best Gen2 candidate.
- Clone the workload, not the prod warehouse. Point a representative job at a
GENERATION = '2'copy and a Gen1 copy, same size, and compare credits and runtime over a real day. - Mind replication. If you replicate warehouses across regions, every secondary region must also support Gen2, or a Gen2 warehouse may fail to resume after a failover. Test the failover path before you standardize on Gen2.
- Leave tiny, idle warehouses alone. A warehouse that mostly serves cheap dashboard queries will feel the rate increase more than the speedup. Gen2 earns its premium on heavy work.
For the read on Gen2 against the rest of your compute strategy, the other Snowflake guides cover sizing, clustering, and the pipeline patterns that decide how much work a warehouse does in the first place.
The honest read
Gen2 is a real upgrade, not marketing: faster hardware, smarter DML, Query Acceleration on by default. But Snowflake made it an opt-in with a higher rate, which means it is a FinOps decision dressed as a performance feature. The teams that win are the ones that benchmark before they standardize, because for compute-heavy pipelines Gen2 can pay for its premium several times over, and for light, bursty workloads it can quietly raise the bill for a speedup you never needed. Run the two-warehouse test, read the two numbers, then decide. Do not let a default, old or new, make the call for you.
