Snowflake Gen2 Warehouse 101: Performance and Cost Breakdown (2025)

Snowflake's virtual warehouses have been the backbone of its cloud data platform since day one. They are the compute engine that powers everything you do in Snowflake. The question is, what if this engine could be even more powerful? What if it could handle more workloads at the same time? Recently, Snowflake introduced Gen2 Standard Warehouses, their next-gen warehouse with faster hardware and intelligent software improvements. Gen2 Warehouse delivers enhanced performance through improvements to delete, update, and merge operations, along with more efficient table scan operations and better overall query processing. Snowflake claims that Gen2 offers approximately ~2.1x faster performance for core analytics compared to standard warehouses.

In this article, we will break down everything you need to know about Snowflake Gen2 Warehouses, including what they are, how they work, their performance and cost breakdowns, and practical implementation strategies.

So, let's get into it.

What Is a Snowflake Gen2 Warehouse?

The Generation 2 Standard Warehouse (Gen2) is Snowflake’s upgraded version (the "next generation") of the current standard Snowflake virtual warehouse, focused on improving performance for analytics and data engineering workloads. It is not a new type of warehouse – it remains a Standard warehouse (not Snowpark-Optimized Warehouse) – but it runs on upgraded hardware and query-engine improvements.

According to Snowflake:

"Generation 2 Standard Warehouse (Gen2) is an updated version (‘the next generation’) of the current standard Snowflake virtual warehouse, focused on improving performance for analytics and data engineering workloads".

Snowflake Gen2 Warehouses bring several key improvements to the table:

1) Upgraded CPU architecture

Snowflake Gen2 Warehouse uses newer CPU chips (AWS Graviton3 Arm architecture processors on AWS C7g instances) with higher single-core performance. The new CPUs offer higher instructions-per-cycle (IPC) and support wider SIMD instructions (256-bit SVE vs 128-bit NEON on Gen1).

2) Faster memory and cache

Snowflake Gen2 Warehouse uses the latest memory (like DDR5 on Graviton3) with roughly 50% more bandwidth than the DDR4 used on Gen1 hardware. Each core also gets a larger L2 cache (2 MiB per core on Gen2 vs 1 MiB on Gen1), reducing data fetch delays. Due to this faster memory and bigger caches, Snowflake Gen2 Warehouses can read and process large data blocks more quickly.

3) Optimized query engine

Behind the scenes, Snowflake has tuned the execution engine for Gen2. There are smarter scheduling and parallelization techniques, so the engine can dispatch more tasks in parallel and keep CPUs busy. The engine also includes targeted optimizations for analytics queries: faster pipelines for table scans, joins, and aggregations, and more efficient handling of DML (INSERT, UPDATE, DELETE, MERGE) operations.

4) Standard Warehouse compatibility

Here's the best part, Snowflake Gen2 Warehouse maintains complete compatibility with existing Standard warehouses. Your existing queries, applications, and integrations work without any kind of major modification.

5) Better concurrency

Snowflake Gen2 Warehouse is designed to handle highly concurrent workloads better. Its hardware and scheduler can support more simultaneous queries or threads before contention becomes a bottleneck.

6) Main focus is on analytics workloads

Snowflake Gen2 Warehouse is targeted for data analytics and engineering workloads (heavy queries, ETL) rather than transactional workloads. It accelerates batch queries, large scans, and transformations, but small interactive queries or extremely low-latency tasks may not see as dramatic gains.

Want to take Chaos Genius for a spin?

It takes less than 5 minutes.

Start Free Trial

Enter your work email

Enter your work email

Start Free Trial

How Do You Create a Snowflake Gen2 Warehouse?

You can't just check a box in the Snowflake Snowsight UI, at least not yet. You have to use SQL.

To create a Gen2 warehouse, you use the same command as for a standard warehouse but with the RESOURCE_CONSTRAINT parameter set to STANDARD_GEN_2.

Here's the basic syntax to create a Snowflake Gen2 Warehouse:

CREATE OR REPLACE WAREHOUSE demo_snowflake_gen2_wh
  RESOURCE_CONSTRAINT = 'STANDARD_GEN_2';

The above statement creates a new Snowflake Gen2 Warehouse with default settings (XS by default).

Note that if you omit the RESOURCE_CONSTRAINT clause entirely, Snowflake will create a Gen1 Warehouse by default.

You can also explicitly choose Snowflake Warehouse size and other options. For example, to create a medium-sized Snowflake Gen2 Warehouse:

CREATE OR REPLACE WAREHOUSE demo_snowflake_gen2_small_wh
  WAREHOUSE_SIZE = MEDIUM
  RESOURCE_CONSTRAINT = STANDARD_GEN_2;

Here you can see, this makes a SMALL warehouse under Snowflake Gen2 Warehouse. (The Snowflake WAREHOUSE_SIZE setting works the same as in standard (Gen1) warehouse).

If you already have a Gen1 Warehouse and want to convert it to Snowflake Gen2 Warehouse, you can use Snowflake ALTER WAREHOUSE with SET RESOURCE_CONSTRAINT.

ALTER WAREHOUSE demo_gen1_wh SUSPEND;
ALTER WAREHOUSE demo_gen1_wh SET RESOURCE_CONSTRAINT = STANDARD_GEN_2;
ALTER WAREHOUSE demo_gen1_wh RESUME;

Note that you should always suspend the warehouse before converting it to a Snowflake Gen2 Warehouse.

All in all, the key is the RESOURCE_CONSTRAINT clause. Setting it to STANDARD_GEN_2 makes a warehouse Gen2, and you can do that at creation or via an ALTER statement.

Architecture Overview of Snowflake Gen2 Warehouse

So, what’s powering these performance gains? It’s a mix of hardware and software upgrades. Here’s a high-level look at what’s under the hood:

Hardware Upgrades

New compute instances. Specifically, on the Amazon Web Services (AWS) platform, Snowflake Gen2 Warehouse uses C7g instances (c7g.2xlarge) powered by the latest Arm-based Graviton3 CPUs. Each C7g.2xlarge node has 8 vCPUs (ARM Neoverse V1 cores) and about 15 GB of RAM. (In contrast, Gen1 used older C6g or other instance types). The Graviton3 delivers roughly 50% higher IPC (instructions per cycle) than the Graviton2 in Gen1.

ARM Architecture and SIMD. The CPUs in Snowflake Gen2 Warehouse are ARM architecture (aarch64) with support for ARMv8.4 features like SVE (Scalable Vector Extensions). Notably, Gen2 cores have 256-bit SIMD registers (SVE), roughly double the 128-bit NEON SIMD on Gen1. Each CPU instruction can operate on twice as many data elements in parallel. (For example, columnar scan operations can process twice the data per cycle). The CPU cores are based on Arm’s Neoverse V1 design, whereas Gen1 used Neoverse N1.

Memory and cache. Snowflake Gen2 Warehouses use DDR5 memory with around 50% more bandwidth than the DDR4 memory used in Gen1 instances. Each core has a larger L2 cache on Gen2: about 2 MiB per core vs 1 MiB per core on Gen1.

Storage. Each compute node includes local SSD storage (hundreds of GB). This local storage is used for caching intermediate data, staging, and spill (same as Gen1). The OS and disks are largely similar to Gen1; but the underlying hardware (CPU, memory) is upgraded.

Software Upgrades

Aside from the physical capability of the new hardware, Snowflake has included sophisticated software optimizations tailored to Snowflake Gen2 Warehouses.

Query engine improvements. Snowflake has optimized its execution engine for the new hardware. The scheduler is more aggressive and can launch more parallel threads to keep all CPU cores busy. The engine pipelines are tuned for Gen2: for example, DML (DELETE, UPDATE, MERGE) operations can run more efficiently, and full table scans and joins are accelerated. In short, the query executor has “smarter parallelism” and better algorithms that take advantage of the faster CPUs, memory, and wider SIMD units.

I/O and caching optimizations. Because Snowflake Gen2 Warehouse has faster CPUs, Snowflake has adjusted its I/O mechanisms. Data movement between storage and compute is optimized so that the CPUs remain fed with data. Larger caches and memory bandwidth also reduce the need to fetch data from remote storage. The effect is that heavy operations like large joins or aggregations can run more smoothly with fewer stalls.

What is the Difference between Snowflake Gen1 vs Snowflake Gen2 Warehouse?

To see the performance improvements you need to know the tech differences between Gen1 and Snowflake Gen2 Warehouses. The main differences are in the core infrastructure and how Snowflake's engine works with it.

The table below compares the key specs.

🔮 TL;DR: Gen2 mainly upgrades the CPU and memory hardware (new instance types, twice the SIMD width, faster RAM, bigger cache). On the software side, Gen2’s engine adds optimizations for common data warehousing tasks. These combine to boost query performance on Gen2 by roughly 25–100% in practice (depending on workload)

Performance Breakdown of Snowflake Gen2 Warehouse

How much faster is Gen2 in practice compared to Gen1? In this section, we're comparing Snowflake Gen2 Warehouses to the original Gen1 ones. We're using the TPC-DS sample dataset to run realistic analytics queries on a LARGE warehouse. To see the difference, we’ll create a Gen1 Warehouse and a Snowflake Gen2 Warehouse, run the same queries on each, and note the performance differences. Snowflake says Gen2 is significantly faster ( ~2.1× faster for core analytics). Our goal here is to show where those speed gains come from in practice, such as during table scans, joins, aggregations, concurrency, and so on.

Warehouse Configuration (Gen1 vs Gen2)

First, we create two identical warehouses that differ only by generation. We set the Snowflake WAREHOUSE_SIZE to LARGE and specify the RESOURCE_CONSTRAINT to select between Gen1 or Gen2.

To create Snowflake Gen2 Warehouse:

CREATE OR REPLACE WAREHOUSE demo_gen2_wh_large
  WAREHOUSE_SIZE = 'LARGE'
  RESOURCE_CONSTRAINT = STANDARD_GEN_2;

To create a Gen1 warehouse, you just omit that parameter, as it's the default.

CREATE OR REPLACE WAREHOUSE demo_gen1_wh_large
  WAREHOUSE_SIZE = 'LARGE';

Use these warehouses for querying. They're both in the AWS us-west-2 region (where Gen2 is available). Just switch between them using USE WAREHOUSE before each query to compare how long they take to run.

Query Preparation

To get clean performance numbers, we took a few preparation steps before running each query on each warehouse. This helps isolate raw execution performance.

1) Disable the Query Cache

First, you need to disable the query cache at the session level. (Disabling caching ensures raw performance is measured). To do so:

ALTER SESSION SET use_cached_result = false;

2) Restart and Select the Warehouse

Suspend and resume the warehouse to clear its cache, and then select it for use. Replace [warehouse_name] with either demo_gen1_wh_large or demo_gen2_wh_large.

ALTER WAREHOUSE [warehouse_name] SUSPEND;
ALTER WAREHOUSE [warehouse_name] RESUME;
USE WAREHOUSE [warehouse_name];

3) Specify the Target Schema

Point the session to the correct TPC-DS dataset.

USE SCHEMA snowflake_sample_data.tpcds_sf10Tcl;

Query 1—Yearly Store Sales by State

• To Test: Scan + Join + GroupBy on a large fact table.
• Final Goal: Exercise full-table scans, filtering by year and grouping by a dimension.

Using the TPC-DS dataset, we write a query that joins STORE_SALES with DATE_DIM and STORE, filtering by year and grouping by state:

Snowflake Gen1 Warehouse

USE SCHEMA snowflake_sample_data.tpcds_sf10Tcl;

SELECT 
  d.d_year, 
  s.s_state, 
  SUM(ss.ss_sales_price) AS total_sales
FROM SNOWFLAKE_SAMPLE_DATA.TPCDS_SF10TCL.STORE_SALES ss
JOIN SNOWFLAKE_SAMPLE_DATA.TPCDS_SF10TCL.DATE_DIM d 
  ON ss.ss_sold_date_sk = d.d_date_sk
JOIN SNOWFLAKE_SAMPLE_DATA.TPCDS_SF10TCL.STORE s 
  ON ss.ss_store_sk = s.s_store_sk
WHERE d.d_year BETWEEN 2001 AND 2003
GROUP BY d.d_year, s.s_state
ORDER BY d.d_year, s.s_state;

Snowflake Gen2 Warehouse

We use the same query as above for testing.

Performance Comparision

We conducted several runs to get the real final performance breakdown.

The first run shows the most dramatic improvement (47.4%), likely due to Gen2's more efficient cold-start performance. Subsequent runs show consistent but smaller gains as both warehouses benefit from warming effects. On average, the Snowflake Gen2 Warehouse was about 3.2 seconds faster.

Snowflake Query Profile Summary: Gen1 vs Snowflake Gen2 Warehouse

Here is the Snowflake query profile for this query on Snowflake Gen1 vs Snowflake Gen2 Warehouse for the very first run.

Snowflake Gen1 Warehouse Query Profile:

Snowflake Gen2 Warehouse Query Profile:

⏱️ Execution time: Gen1 ran in 19 s vs Gen2 in 10 s (47% faster on Gen2)

⚙️ Operator breakdown:

• TableScan: 96.1% (Gen1) → 95.6% (Gen2)
• Aggregate: 3.2% (Gen1) → 3.5% (Gen2)

🔋 Resource consumption:

• Processing time: 7.4% → 8.0%
• Local disk I/O: 0.7% → 0.4%
• Remote disk I/O: 91.6% → 90.8%
• Synchronization: 0.2% → 0.8%

📈 Scan metrics (identical across both):

• Progress: 38.84%
• Data scanned: 38.00 GB, 0% from cache
• Network transfer: 21.54 MB → 21.26 MB
• Partitions: 28243 scanned of 72720 total

Analysis: Gen2 delivers approximately half the execution time of Gen1 while maintaining similar I/O and compute distribution patterns. The performance gain is primarily attributed to improved hardware efficiency rather than algorithmic changes.

Query 2—Category Sales Trend

To Test: Join 3 tables + aggregation with range filter.

Final Goal: Test multi-table joins and filtering.

Snowflake Gen1 Warehouse

Here, we join CATALOG_SALES with ITEM and DATE_DIM to sum sales for a specific year by item category and brand.

-- Query to sum catalog sales by category and brand ID
SELECT
  i.i_category,
  i.i_brand_id,
  SUM(cs.cs_sales_price) AS total_sales
FROM SNOWFLAKE_SAMPLE_DATA.TPCDS_SF10TCL.CATALOG_SALES cs
JOIN SNOWFLAKE_SAMPLE_DATA.TPCDS_SF10TCL.ITEM i
  ON cs.cs_item_sk = i.i_item_sk
JOIN SNOWFLAKE_SAMPLE_DATA.TPCDS_SF10TCL.DATE_DIM d
  ON cs.cs_sold_date_sk = d.d_date_sk
WHERE d.d_year = 2002
GROUP BY i.i_category, i.i_brand_id
ORDER BY i.i_category, i.i_brand_id;

Snowflake Gen2 Warehouse

We use the same query as above for testing.

Again, Gen2 is faster by about 30% (and 3.475 seconds faster). Because this query involves more joining and aggregation, the performance gain isn't just from faster scans. Gen2's architecture, with wider SIMD lanes and higher memory bandwidth, helps with joins and aggregations, too.

Snowflake Query Profile Summary: Gen1 vs Snowflake Gen2 Warehouse

Here is the Snowflake query profile for this query on Snowflake Gen1 vs. Snowflake Gen2 Warehouse for the very first run.

Snowflake Gen1 Warehouse Query Profile:

Snowflake Gen2 Warehouse Query Profile:

⏱️ Execution time: Gen1 ran in 13 s vs Gen2 in 9.2 s (≈ 29% faster on Gen2)

⚙️ Operator breakdown

• TableScan: 79.8% → 84.2%
• Aggregate [10]: 10.6% → 8.7%
• Aggregate [3]: 4.8% → 3.6%
• Join: 3.0% → 1.8%

🔋 Resource consumption

• Processing: 21.4% → 17.0%
• Local disk I/O: 0.9% → 0.3%
• Remote disk I/O: 76.8% → 81.7%
• Network communication: 0.1% → 0.0%
• Synchronization: 0.7% → 0.8%
• Initialization: 0.1% → 0.1%

📈 Scan metrics (identical across both)

• Progress: 19.82%
• Data scanned: 13.10 GB, 0% from cache
• Bytes written to result: 0.07 MB
• Network transfer: 135.23 MB → 86.14 MB
• Partitions: 10885 scanned of 54925 total

Analysis: Snowflake Gen2 Warehouse cuts runtime by almost a third, shifts more work into remote I/O and table scan, and reduces network traffic and local I/O while keeping scan volume constant.

Query 3—Store vs Catalog Sales per Item

To Test: Aggregations + joining subqueries.

Final Goal: Compare separate fact tables joined at the aggregated level.

Snowflake Gen1 Warehouse

Let's dive into a final example where we first aggregate STORE_SALES and CATALOG_SALES by item (using subqueries), then perform a full join. This query mimics a realistic report that compares two channels.

-- Query combining store and catalog sales by item ID and category
WITH store_totals AS (
  SELECT
    i.i_item_id,
    i.i_category,
    SUM(ss.ss_sales_price) AS store_sales
  FROM SNOWFLAKE_SAMPLE_DATA.TPCDS_SF10TCL.STORE_SALES ss
  JOIN SNOWFLAKE_SAMPLE_DATA.TPCDS_SF10TCL.ITEM i
    ON ss.ss_item_sk = i.i_item_sk
  GROUP BY i.i_item_id, i.i_category
),
catalog_totals AS (
  SELECT
    i.i_item_id,
    i.i_category,
    SUM(cs.cs_sales_price) AS catalog_sales
  FROM SNOWFLAKE_SAMPLE_DATA.TPCDS_SF10TCL.CATALOG_SALES cs
  JOIN SNOWFLAKE_SAMPLE_DATA.TPCDS_SF10TCL.ITEM i
    ON cs.cs_item_sk = i.i_item_sk
  GROUP BY i.i_item_id, i.i_category
)
SELECT
  COALESCE(s.i_item_id, c.i_item_id) AS item_id,
  COALESCE(s.i_category, c.i_category) AS category,
  s.store_sales,
  c.catalog_sales
FROM store_totals s
FULL OUTER JOIN catalog_totals c
  ON s.i_item_id = c.i_item_id
ORDER BY item_id;

Snowflake Gen2 Warehouse

We use the same query as above for testing.

On this more complex query, the cold-run improvement is again dramatic (47.1%). The average improvement settles around 31%. On average, the Snowflake Gen2 Warehouse was about 18.25 seconds faster.

This query performs two large aggregations before joining the results, stressing the warehouse's ability to handle compute-intensive work. Gen2's hardware is better suited for this, executing both the subqueries and the final join more efficiently. 

Note that full joins and full scans can stress memory and I/O intensive workloads.

Snowflake Query Profile Summary: Gen1 vs Snowflake Gen2 Warehouse

Here is the Snowflake query profile for this query on Snowflake Gen1 vs. Snowflake Gen2 Warehouse for the very first run.

Snowflake Gen1 Warehouse Query Profile:

Snowflake Gen2 Warehouse Query Profile:

⏱️ Execution time: Gen1 ran in 1 m 27 s vs Gen2 in 46 s (≈ 47% faster on Gen2)

⚙️ Operator breakdown

• TableScan [9]: 54.4% → 54.8%
• TableScan [16]: 38.0% → 38.3%
• Aggregate [7]: 4.8% → 4.2%
• Aggregate [14]: 2.3% → 2.2%

🔋 Resource consumption

• Processing: 9.5% → 8.7%
• Local disk I/O: 0.5% → 0.3%
• Remote disk I/O: 89.8% → 90.5%
• Synchronization: 0.1% → 0.4%
• Initialization: 0.1% → 0.1%
• Network communication: 0.0% → 0.0%

📈 Scan metrics (identical volumes)

• Progress: 100.00%
• Data scanned: 192.85 GB, 0.00% from cache
• Bytes written to result: 6.87 MB
• Bytes sent over network: 1.88 GB → 1.78 GB
• Partitions: 127644 scanned of 127644 total

Analysis: You can see that Snowflake Gen2 Warehouse cuts runtime by nearly half, shifts a touch more work to remote I/O and table scan, and trims network traffic while scan volume stays constant.

Expected Performance Observations

For all queries above, Snowflake Gen2 Warehouses show lower execution time than Gen1. In general:

• Consistent Performance Gains: Snowflake Gen2 Warehouses consistently demonstrate performance improvements of 28-47% across all tested query patterns, with an average improvement of approximately 30%.
• Concurrency/Throughput: Snowflake Gen2 Warehouse can handle more query threads simultaneously. If multiple users run queries at once, Gen2 maintains higher throughput with less queuing.
• Query Behavior: The SQL semantics are identical on Gen1 vs. Gen2. No query rewrite or syntax change is needed. However, Snowflake Gen2 Warehouses have slightly different memory allocation (a standard Snowflake Gen2 Warehouse has memory like Snowpark MEMORY_1X by default). In most cases, this doesn’t hurt typical analytics queries, but extremely memory-intensive sorts or joins could spill differently. We did not hit memory limits in our test queries.
• Data Caching: Both Snowflake Gen1 Warehouse and Snowflake Gen2 Warehouse use the same result cache and local SSD caching. We disabled result caching for fairness. In both generations, repeated identical queries could benefit from result or data caching, but we focus on cold-run performance.

All in all, Snowflake’s own tests report up to ~2.1× faster core analytics on Snowflake Gen2 Warehouses. We see that pattern: if Gen1 takes X seconds, Gen2 often takes about X/2 seconds for the same query. The exact speedup varies by query. For example, scan-heavy queries typically get the largest boost. Multi-join queries also improve but somewhat less.

Cost Breakdown of Snowflake Gen2 Warehouse

Snowflake Gen2 Warehouses use more powerful hardware, so they consume more Snowflake credits per hour. The official Snowflake Service Consumption Table lists the Snowflake Credit cost for Snowflake Gen2 Warehouses on AWS and Azure as follows:

Note: Snowflake Gen2 Warehouse is not available for X5LARGE and X6LARGE and is not yet supported on GCP.

Snowflake Gen2 Warehouse offers better performance but at a higher Snowflake Credit cost burn.

Drawbacks and Limitations of Snowflake Gen2 Warehouse: The Not-So-Shiny Side

Snowflake Gen2 Warehouse has its benefits, but be aware that there are some limitations.

⚠️ No Snowflake Snowsight UI support

Currently, you cannot create or alter a Snowflake Gen2 Warehouse via the Snowflake web interface (Snowflake Snowsight). The RESOURCE_CONSTRAINT = STANDARD_GEN_2 setting must be applied via SQL only. 

⚠️ Not supported on X5LARGE/X6LARGE

Snowflake Gen2 Warehouses only go up to X4 (4XL). The two largest Gen1 Snowflake Warehouse sizes (5XL and 6XL) are not available for Gen2. If you try to set a warehouse to X5 or X6 with STANDARD_GEN_2, Snowflake will reject it. In practice, if you need that scale, you would instead use a multi-cluster Snowflake Gen2 Warehouse, or stick with a Gen1 5XL/6XL if absolutely necessary.

⚠️ Cloud & Region Limits

Snowflake Gen2 Warehouse is available only in the following regions.

• AWS us-west-2 (Oregon)
• AWS eu-central-1 (Frankfurt)
• Azure East US 2 (Virginia)
• Azure West Europe (Netherlands)

It is not available on GCP or in other Snowflake regions. If you replicate a warehouse to another region for DR, that region must also support Gen2 or the warehouse may not resume after failover

⚠️ Higher cost per second

As we have already mentioned above, Snowflake Gen2 Warehouse charges more Snowflake credits per second. For very short or light queries, Gen1 might actually cost slightly less if they don’t fully utilize the extra speed.

⚠️ Resource Constraint not visible in INFORMATION_SCHEMA

Snowflake’s INFORMATION_SCHEMA and ACCOUNT_USAGE views do not show a column for Gen2. The warehouse’s RESOURCE_CONSTRAINT (Gen1 vs Gen2) is only visible in the output of SHOW WAREHOUSES.

⚠️ No Snowpark-Optimized Warehouse Support

Snowflake Gen2 Warehouse applies only to standard warehouses. You cannot use RESOURCE_CONSTRAINT = STANDARD_GEN_2 on a Snowpark-Optimized Warehouse (those use MEMORY_* constraints). Conversely, you can’t directly convert a Snowpark-Optimized Warehouse to Gen2 because the memory models differ. (Snowflake’s docs show a procedure to handle this via changing the resource constraint to MEMORY_1X when switching to Snowpark-Optimized Warehouse mode).

Optimizing Your Use of Snowflake Gen2 Warehouse

To get the best results with Snowflake Gen2 Warehouse (and to control costs), apply the usual warehouse best practices – and a few Gen2-specific tips:

1) Auto-Suspend / Auto-Resume 

Set a short Snowflake AUTO_SUSPEND timeout so idle warehouses stop automatically. Gen2 spins up slightly faster than Gen1, so you can afford to suspend sooner. Enable Snowflake AUTO_RESUME=TRUE so queries auto-start the warehouse when needed.

2) Turn on Snowflake Query Acceleration Service

For very long-running queries, consider enabling Snowflake Query Acceleration Service (ENABLE_QUERY_ACCELERATION = TRUE). This serverless feature can speed up massive scans or joins (at extra per-second cost). Enable it via:

ALTER WAREHOUSE ....
  SET ENABLE_QUERY_ACCELERATION = true;

It may help Gen2 queries complete even faster, though most Gen2 speedups come from the warehouse itself.

3) Create/Implement Resource Monitors

Assign a Snowflake RESOURCE_MONITOR to the warehouse to cap and track Snowflake credit consumption. Resource monitors can trigger alerts or suspend warehouses when a spending threshold is reached. It is useful for Gen2 (more expensive) to avoid runaway bills. 

CREATE RESOURCE MONITOR gen2_monitor
WITH CREDIT_QUOTA = 1000
TRIGGERS ON 75 PERCENT DO NOTIFY
         ON 90 PERCENT DO NOTIFY
         ON 100 PERCENT DO SUSPEND;

ALTER WAREHOUSE demo_gen2_wh
SET RESOURCE_MONITOR = 'gen2_monitor';

4) Use Statement Timeouts

To prevent exceedingly long or runaway queries, set the STATEMENT_TIMEOUT_IN_SECONDS parameter at the session or warehouse level. 

ALTER WAREHOUSE demo_gen2_wh
SET STATEMENT_QUEUED_TIMEOUT_IN_SECONDS = 600, -- 10 minutes
    STATEMENT_TIMEOUT_IN_SECONDS = 3600; -- 1 hour

5) Use Snowflake Snowsight Dashboards, Snowflake QUERY_HISTORY, and Snowflake Query Profiles

Snowflake provides built-in tools for monitoring and optimizing warehouse usage.

Snowflake Snowsight Dashboards offer a visual overview of Snowflake usage and performance.

Snowflake QUERY_HISTORY provides a detailed log of all executed queries, including SQL statements, user information, execution times, and status. It allows for filtering and searching based on various criteria (time range, user, role, warehouse, status) and is extremely valuable for identifying long-running queries or performance bottlenecks.

SELECT QUERY_ID, WAREHOUSE_SIZE, EXECUTION_TIME, CREDITS_USED
FROM TABLE(INFORMATION_SCHEMA.QUERY_HISTORY())
WHERE WAREHOUSE_NAME = 'DEMO_GEN2_WH'
ORDER BY START_TIME DESC
LIMIT 100;

Query Profile tool offers a comprehensive report and visual insight into query execution. It presents a Directed Acyclic Graph (DAG) of the query plan, detailing execution time, operator specifics, data flow, and resource usage (CPU, disk I/O).

6) Name Warehouses Descriptively

A general best practice includes generation and purpose in warehouse names. 

CREATE WAREHOUSE analytics_gen2_medium
WITH WAREHOUSE_SIZE = 'MEDIUM'
RESOURCE_CONSTRAINT = 'STANDARD_GEN_2';

7) Start with a Smaller Warehouse Size

When initially deploying or optimizing a workload, it is often recommended to start with a smaller warehouse size and incrementally increase it as needed based on performance observations.

9) Maximize Caching

Snowflake automatically caches query results for 24 hours. Identical queries executed within this period can return cached results without consuming additional Snowflake credits, offering a significant optimization opportunity. To maximize cache hits, standardize query patterns, avoid unnecessary columns in SELECT clauses, and maintain consistency in whitespace and capitalization.

10) Leverage Snowflake Materialized Views

Snowflake Materialized views can significantly improve query performance for frequently executed queries that involve complex computations or large datasets. They pre-compute and store results, reducing the need for repeated, resource-intensive operations.   

11) Utilize Search Optimization Service

For tables where specific rows are frequently accessed via equality conditions, Snowflake's search optimization service can provide substantial performance gains.

Put these practices into action and you'll unlock Gen2's full potential with minimal waste.

Workloads Benefiting Most From Snowflake Gen2 Warehouse?

Snowflake Gen2 Warehouses shine on compute-intensive analytical workloads. Workloads that benefit most include:

🔮 Large joins and aggregations. Complex joins between big tables or GROUP BY aggregations benefit from Gen2’s faster CPUs, SIMD, and memory bandwidth. The wider SIMD registers help crunch through millions of rows in parallel.

🔮 Wide table scans and filters. Queries that scan many rows (especially with filters on columns) run faster because Gen2 can prefetch and process large blocks quickly.

🔮 Sorting and window functions. Operations that require sorting large datasets (e.g. ORDER BY or window functions) take advantage of Gen2’s memory and compute speed.

🔮 Complex transformations. ETL-like transformations (heavy calculations, data type conversions, compression/decompression) run faster on Gen2 hardware.

🔮 High concurrency. Workloads with many concurrent queries or threads can keep more CPU cores busy. Gen2’s scheduler and multiple cores support higher concurrency before saturating.

🔮 Computationally expensive functions. Using CPU-intensive UDFs or complex functions (regexes, math functions, machine learning libraries) sees big gains thanks to the improved CPU architecture.

All in all, any CPU-bound, data-heavy query will run noticeably better on Snowflake Gen2 Warehouse. If a workload is mostly disk or I/O bound (small queries, metadata operations, etc), the speedup will be less dramatic.

Practical Examples of Snowflake Gen2 Warehouse

Understanding the theory is one thing; putting it into practice is another. Here are some practical SQL examples to help you create, modify, and manage Snowflake Gen2 Warehouses.

Example 1—Upgrading Snowflake Gen1 Warehouse to Snowflake Gen2 Warehouse

If you have an existing Gen1 standard warehouse and want to upgrade it to Gen2, you can do so using the Snowflake ALTER WAREHOUSE command. A crucial step here is to suspend the warehouse first, as this allows Snowflake to re-provision the underlying hardware to the new generation's specifications.

ALTER WAREHOUSE old_wh SUSPEND;
ALTER WAREHOUSE old_wh SET RESOURCE_CONSTRAINT = STANDARD_GEN_2;
ALTER WAREHOUSE old_wh RESUME;

Example 2—Setting Up a Default-Sized Snowflake Gen2 Warehouse

When creating a new warehouse, if you do not specify a WAREHOUSE_SIZE, it defaults to XSMALL. To create a Snowflake Gen2 Warehouse with this default size, you only need to specify the RESOURCE_CONSTRAINT.

CREATE OR REPLACE WAREHOUSE next_generation_default_size
  RESOURCE_CONSTRAINT = STANDARD_GEN_2;

Example 3—Creating a Custom-Sized Snowflake Gen2 Warehouse

You can specify a custom warehouse size (SMALL, MEDIUM, LARGE, etc) when creating a Snowflake Gen2 Warehouse, just as you would with a Gen1 Warehouse.

CREATE OR REPLACE WAREHOUSE demo_gen2_wh_size_small
  RESOURCE_CONSTRAINT = STANDARD_GEN_2
  WAREHOUSE_SIZE = SMALL;

Example 4—Converting Snowflake Gen2 Warehouse to Snowpark-Optimized Warehouse

While Gen2 is an enhancement to the standard warehouse, it is not compatible with Snowpark-Optimized Warehouse types. However, you can convert a Gen2 standard warehouse to a Snowpark-Optimized Warehouse by changing both the WAREHOUSE_TYPE and RESOURCE_CONSTRAINT. This also requires suspending the warehouse first.

Note that Snowpark-Optimized Warehouses have their own specific RESOURCE_CONSTRAINT values related to memory capacity (MEMORY_1X, MEMORY_16X).

CREATE OR REPLACE WAREHOUSE gen2_to_sp
  RESOURCE_CONSTRAINT = STANDARD_GEN_2;
ALTER WAREHOUSE gen2_to_sp SUSPEND;
ALTER WAREHOUSE gen2_to_sp
  SET WAREHOUSE_TYPE = 'SNOWPARK-OPTIMIZED',
      RESOURCE_CONSTRAINT = MEMORY_1X;
ALTER WAREHOUSE gen2_to_sp RESUME;

As you can see here, we first created a Snowflake Gen2 Warehouse named gen2_to_sp. Then, we suspended and altered it to the type SNOWPARK-OPTIMIZED with a compatible memory setting (MEMORY_1X). (Snowpark-Optimized Warehouses cannot use Gen2, so we must switch the type).

Save up to 30% on your Snowflake spend in a few minutes!

Request a Demo

Enter your work email

Enter your work email

Request a Demo

Conclusion

And that’s a wrap! Snowflake Gen2 Warehouses are a powerful upgrade for analytics and data engineering workloads. Snowflake Gen2 Warehouses can process numerous queries far quicker than their Gen1 counterparts by upgrading to faster ARM CPUs, DDR5 memory, and a tweaked query engine. In exchange, they burn more Snowflake credits per second. Deciding whether to use Gen2 depends on your workload: for large, compute-heavy queries, the speedups often outweigh the cost increase. But for smaller or highly concurrent workloads, it’s worth testing to ensure cost-effectiveness.

In this article, we have covered:

• What is a Snowflake Gen2 Warehouse?
• How do you create a Snowflake Gen2 Warehouse?
• Architecture overview of Snowflake Gen2 Warehouse
• What is the difference between Snowflake Gen1 and Snowflake Gen2 Warehouse?
• Performance breakdown of Snowflake Gen2 Warehouse
• Cost breakdown of Snowflake Gen2 Warehouse
• Drawbacks and limitations of Snowflake Gen2 Warehouse
• Optimizing your use of Snowflake Gen2 Warehouse
• Workloads that benefit most from Snowflake Gen2 Warehouse
• Practical examples of Snowflake Gen2 Warehouse

...and much more!

FAQs

What is Snowflake Gen2 Warehouse?

Snowflake Gen2 Warehouse is the next-generation standard virtual warehouse on Snowflake. It uses upgraded hardware (faster CPUs, memory, cache) and query-engine optimizations to accelerate analytics. Technically, it’s the same “STANDARD” warehouse type but running on new hardware. It requires setting RESOURCE_CONSTRAINT = STANDARD_GEN_2 when creating the warehouse.

Which cloud providers and regions support Snowflake Gen2 Warehouses?

Snowflake Gen2 Warehouse is currently available only on AWS and Azure (in select regions):

• AWS us-west-2 (Oregon)
• AWS eu-central-1 (Frankfurt)
• Azure East US 2 (Virginia)
• Azure West Europe (Netherlands)

 It is not yet available on Google Cloud Platform.

Can I use Snowflake Gen2 Warehouses via the Snowflake web UI (Snowflake Snowsight)?

No. As of now, Snowflake Gen2 Warehouses must be created and managed via SQL commands. The Snowflake Snowsight interface does not yet expose the RESOURCE_CONSTRAINT setting.

How do I enable Gen2 on an existing warehouse?

Use the Snowflake ALTER WAREHOUSE command. For example:

ALTER WAREHOUSE my_demo_wh SUSPEND; 
ALTER WAREHOUSE my_demo_wh SET RESOURCE_CONSTRAINT = STANDARD_GEN_2; 
ALTER WAREHOUSE my_demo_wh RESUME;

Always suspend the warehouse before changing the resource constraint.

Do Snowflake Gen2 Warehouses cost more?

Yes, Snowflake Gen2 Warehouse runs at a premium rate per second. Roughly, Gen2 costs 1.35× the Snowflake credits of Gen1 on AWS and 1.25× on Azure. However, since queries run faster, many workloads end up using the same or fewer total Snowflake credits. Always benchmark your specific jobs.

Can I resize a Snowflake Gen2 Warehouse to any size?

Snowflake Gen2 Warehouse supports all the usual sizes except the two largest tiers. You can resize from XSMALL up to 4XL. X5LARGE and X6LARGE sizes are not supported for Gen2. Trying to set those sizes with STANDARD_GEN_2 will fail.

Is the Gen2 status visible in INFORMATION_SCHEMA?

No, the INFORMATION_SCHEMA views do not show whether a warehouse is Gen2. The warehouse’s RESOURCE_CONSTRAINT (Gen1 vs Gen2) only appears in the output of SHOW WAREHOUSES. You’ll need to use SHOW WAREHOUSES or query SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METRICS for that info.

Can I use Gen2 with multi-cluster (multi-cluster warehouses)?

Yes. Snowflake Gen2 Warehouse applies per cluster, so you can have a multi-cluster Snowflake Gen2 Warehouse just like Gen1. For example:

ALTER WAREHOUSE wc1 SET
RESOURCE_CONSTRAINT = 'STANDARD_GEN_2',
MIN_CLUSTER_COUNT = 1,
MAX_CLUSTER_COUNT = 10;

Each cluster in that warehouse will be Gen2. (Auto-scaling works the same way).

Does Gen2 change how storage or virtual warehouse billing works?

No, nothing about storage is different. Snowflake Gen2 Warehouse only affects the compute (warehouse) side. Your tables, databases, and cloud storage continue as usual. Billing still separates compute (warehouses) and storage in the same way; Gen2 just changes the compute rate.

What workloads shouldn’t use Gen2?

If your workloads are very light (tiny lookups, simple point queries) or extremely short-lived, the benefit of Snowflake Gen2 Warehouse might not justify the higher cost. Also, if you rely on functionality not yet supported (e.g. Snowpark-Optimized Warehouse or GCP), you can’t use Gen2. For all normal heavy analytics and ETL workloads, Gen2 is recommended.

How do I check if a warehouse is Gen1 or Gen2?

Run SHOW WAREHOUSES LIKE '<name>'. In the result, look at the RESOURCE_CONSTRAINT column – it will say either STANDARD_GEN_1 or STANDARD_GEN_2 for each warehouse. As noted, the standard views in INFORMATION_SCHEMA won’t show this.

Will Snowflake keep Gen1 Warehouses around?

Yes. Gen1 Warehouses still exist and can be used indefinitely. Gen2 is optional. Some customers may run a mix of Gen1 and Gen2 in their account. Snowflake has not removed Gen1; it’s more like having a Gen2 toggle.

Are there any transaction or query limitations on Gen2?

Functionally, no. Snowflake Gen2 Warehouse behaves like a normal warehouse for all supported SQL. There are no special SQL restrictions. All transactions, concurrency levels, and features work the same, except where noted (e.g. no Snowpark-Optimized Warehouse support).

If I use cross-region replication, do I need to worry about Gen2?

Yes. If you replicate databases across regions, make sure Gen2 is supported in the target region as well. Otherwise, a Snowflake Gen2 Warehouse might fail to resume after a failover. Always test your DR setup if you use Gen2.