Snowflake Gen1 vs. Gen2 Warehouses: What Changed, and What It Costs You

Keebo Blog | Snowflake Gen1 vs. Gen2 Warehouses

Snowflake Generation 2 (Gen2) warehouses are now the default. Every new standard warehouse in a supported region runs at 1.35 times the Gen1 credit rate on AWS and GCP. On Azure it runs at 1.25 times. You did not opt in.

That rate is worth paying on some workloads and expensive on others. The difference is not query speed.

Snowflake bills warehouse uptime. A query that finishes 30% faster saves you nothing if the warehouse stays open for the query behind it. Only one number decides whether Gen2 is cheaper: how far your total uptime falls. That depends on your workload mix and your arrival patterns, not on anyone’s benchmark.

My team at Keebo started testing Gen2 the day it landed in our accounts. We replayed customer workloads against both generations and ran Snowflake’s headline benchmark ourselves. Here is what we found, updated for what changed in 2026.

Gen1 vs. Gen2: The Actual Differences

Gen1Gen2
Core ConceptTraditional Snowflake virtual warehousesNext-generation warehouse architecture with improved performance and efficiency
Credit Rate1.0x baseline1.35x on AWS and GCP, 1.25x on Azure
SizesX-Small to 6X-LargeX-Small to 4X-Large
Default for New WarehousesNoYes, in supported regions
Query Acceleration ServiceOff by default on single-cluster, max scale factor 8On by default at creation, max scale factor 2
Snowpark-Optimized WarehousesYesNo
Configurable in SnowsightYesNo
Region CoverageAll regionsMost regions, with gaps
Best Fit ScenariosLegacy workloads, stable pipelines, predictable usage patternsMost production workloads requiring control and consistent performance

Everything else holds steady. Same credit price, same auto-suspend and auto-resume behavior, same multi-cluster scaling, and same result cache. Gen2 changes the hardware under the compute and the rate you pay for it.

What Changed in 2026

Two behavior changes shipped in Snowflake’s 2026_03 bundle. Both affect your bill.

Gen2 became the default. BCR-2250 makes Gen2 the default generation for every new standard warehouse in a supported region. Existing Gen1 warehouses keep their generation. Anything you create from now on does not, unless you say otherwise.

Query acceleration turns on by itself. BCR-2269 enables the Query Acceleration Service by default on newly created Gen2 and multi-cluster warehouses. It caps the scale factor at 2. Acceleration bills as separate serverless compute, so it adds a line item your Gen1 warehouses did not carry.

The second change hides a trap. Altering an existing Gen1 warehouse to Gen2 does not enable acceleration. A warehouse you converted and a warehouse you created will behave differently and bill differently, even at identical settings. If you are comparing the two, you are not running a clean test.

A few regions still have no Gen2 at all. The current list includes Zurich and Cape Town on AWS, Dammam on GCP, and US Gov Virginia on Azure. New warehouses there stay on Gen1.

What Is Actually Under the Hood

Snowflake’s release notes say “faster hardware” and stop there. The community filled in the rest.

Analysis of Gen2 nodes on AWS points to C7g instances running the Arm-based Graviton3 CPU. Gen1 appears to sit on C6g and Graviton2. Snowflake has not confirmed either, so treat it as a well-supported inference rather than documented fact. Neither Azure nor GCP has published a backing SKU.

If the Graviton3 read is right, the generational jump looks like this:

Gen1 (C6g / Graviton2)Gen2 (C7g / Graviton3)
CoreArm Neoverse N1Arm Neoverse V1 (~50 % higher IPC)
SIMDNEON 128‑bit x2SVE 256 bit ×2
MemoryDDR4‑3200DDR5‑4800 (~50 % more bandwidth)
L2 Cache1 MiB per core2 MiB per core

Fun note: I’ve heard (word of mouth) that Graviton 3 was architected by some University of Michigan alums. Go Blue!

What That Jargon Means

Three things there matter for query execution.

Wider SIMD units process more values per instruction. Columnar scans and hash aggregations are exactly the shape of work that benefits. Both apply one operation across long runs of identically typed data.

More memory bandwidth shortens the wait between the CPU asking for data and getting it. Joins spill less. Skewed group-bys stall less often.

Larger caches keep more working set close to the core. That compounds with the bandwidth gain rather than adding to it.

My own area of expertise is in databases and machine learning. So I reached out to one of my colleagues at the University of Michigan, professor Nishil Talati, who’s an expert in modern hardware architecture and sought his opinion. Here’s what he told me:

That is the crux. Faster silicon sets a ceiling. Software decides how close you get to it, and your workload decides which parts of the software you exercise.

The Benchmarks and What They Leave Out

Snowflake’s launch blog cited a TPC‑DS 1 TB “power” run showing ≈ 25 – 40 % faster execution (May 5 release notes). Independent engineers quickly validated it:

  • Jason Holt measured a 25 % speed‑up on XS warehouses with only 1 % extra cost (LinkedIn).
  • Masato Takada saw 30 – 40 % median gains (up to 70 %) across 22 TPC‑H queries (Medium).
  • Our researchers at Keebo replayed the Snowflake‑hosted TPC‑DS sample schema and hit the same ballpark.

Worth noting, benchmark suites run on clean caches, uniform data, and perfect parallelism. The suite makes every query compute-bound, because that is what it exists to measure. Your Monday morning dashboard refresh is not that. It reads cold partitions and waits on external stages. One slow query holds the warehouse open for everything else.

Why Faster Doesn’t Mean Cheaper

Here is the math that decides it.

To break even, uptime has to fall by more than 1 minus (1 / cost multiplier).

  • At 1.35x on AWS and GCP, uptime must drop more than 25.93%.
  • At 1.25x on Azure, uptime must drop more than 20%.

Below that line, a faster warehouse produces a larger bill.

Take a single query on an X-Small warehouse. On Gen1 it runs 60 minutes and burns 60 credit-minutes. Move it to Gen2 on AWS and speed it up 25%. Now it runs 45 minutes at 1.35 credits per minute, which is 60.75 credit-minutes. You bought a 25% speedup and paid 1.25% more for it.

Push the speedup to 30% and the picture flips. The query runs 42 minutes, costs 56.7 credit-minutes, and saves you 5.5%. Five percentage points of speedup separate a loss from a win. That is why averages are dangerous here.

Concurrency Is Where the Money Goes

Individual query speedups are not what you pay for. Warehouse uptime is. Concurrency decides how much of a speedup reaches your uptime, and usually the answer is not much. Picture two scenarios:

PatternGen 1 UptimePer-Query SpeedupGen 2 UptimeNet Cost vs. Gen 1
Synchronous batch, 100 queries launch together at 01:00, finish together60 min30%42 minAbout 5% cheaper
Staggered arrivals, same 100 queries trickle in over one hour60 min (warehouse busy entire hour)30%58 minAbout 30% more expensive

Same queries. Same speedup. Opposite outcomes.

Now consider a mixed batch. Nineteen queries speed up 50%, and one long-running query speeds up 5%. The warehouse stays open until the slow one finishes. Uptime falls 5%. You pay 35% more for every minute of it. Your average speedup reads 47.75%, and your bill climbs 28%.

This is the failure mode we see most often. Teams model the migration on average query performance. Average query performance is not connected to the invoice.

Which Workloads Benefit, and Which Do Not

Gen2 rewards compute-bound work. The operations that gain most keep the CPU busy on data already in memory.

Likely to benefit:

  • Joins, aggregations, and sorts
  • Window functions and deduplication
  • DELETE, UPDATE, and MERGE operations
  • Regular expression matching and math user-defined functions
  • Compression, decompression, and encoding work

Unlikely to benefit:

  • Queries that spend most of their time reading remote storage
  • Workloads that spill heavily to local or remote storage
  • Queries that call external functions, external stages, or remote services
  • Queries that run against cold caches
  • Short queries where planning and queuing dominate runtime

The rule underneath both lists is simple. Faster cores do nothing while they wait for data to arrive. The more time your workload spends on I/O, the less of the Gen2 premium you recover.

A Third Option Between Gen1 and a Size Bump

Doubling warehouse size doubles cost. It rarely doubles throughput, because the I/O-bound part of your workload does not scale with compute.

Gen2 gives you a smaller step. On AWS, a Medium Gen2 costs 35% more than a Medium Gen1. On the right workload it runs queries 25% to 40% faster. A Large Gen1 costs twice what the Medium does, for a gain that I/O caps well short of double.

If you are sizing up today because queries queue, test Gen2 at the current size first. The gentler slope sometimes lands closer to what you need.

How to Switch and What Breaks

Gen2 requires SQL. Snowsight does not expose the setting.

-- Create a Gen2 warehouse CREATE WAREHOUSE analytics_wh     WAREHOUSE_SIZE = 'MEDIUM'     GENERATION = '2';  -- Convert an existing warehouse ALTER WAREHOUSE analytics_wh SET GENERATION = '2';  -- Revert to Gen1 ALTER WAREHOUSE analytics_wh SET GENERATION = '1';

Three caveats before you run any of that.

Converting a running warehouse leaves in-flight queries on Gen1 resources. New queries start on Gen2. Snowflake bills both sets until the old queries drain, so convert during a quiet window.

If you use account replication, confirm your secondary region supports Gen2. If it does not, the warehouse may fail to resume after failover.

Reverting takes one statement, so the cheapest test is a real one. Set it, watch two weeks of credits, and set it back if the number moves the wrong way.

The Part That Does Not Stay Solved

Even if you get the answer right today, it expires.

Your query mix shifts when a team ships a new model. Arrival patterns change when someone reschedules a dbt run. Cache hit rates move with data volume. Any of those can push a warehouse across the break-even line. Nothing in Snowflake tells you it happened.

So treat generation as a setting a system tunes, not a decision you make once. Keebo’s artificial intelligence (AI) engine models arrival patterns, compute versus I/O mix, and tail latency. It then adjusts warehouse configuration in real time as those inputs move.

Keebo Workload Intelligence simulates Gen1 against Gen2 credit burn on your own query history, including overlaps and suspends. Keebo Warehouse Optimization then holds the configuration at the lowest cost your performance targets allow.

Snowflake Gen1 vs. Gen2 FAQs

Is Gen2 Faster Than Gen1?

Yes, on compute-bound work. Snowflake reports up to 2.1 times on core analytics and up to 4.4 times on DELETE, UPDATE, and MERGE. Independent testing lands closer to 25% to 40%.

Does Gen2 Cost More?

Yes. Gen2 consumes 1.35 times the credits per hour on AWS and GCP, and 1.25 times on Azure.

Do I Have to Migrate?

No. Existing Gen1 warehouses stay on Gen1 until you convert them. Only new warehouses default to Gen2.