Snowflake Virtual Warehouses – Sizes, Credits, Gen 1 vs Gen 2
Week 2 starts with compute, the part of Snowflake that shows up on every monthly invoice. A virtual warehouse is the MPP cluster that runs your SQL, and three knobs (size, generation, and warehouse type) decide what you pay and how fast it runs.
| Term | Plain meaning |
|---|---|
| Virtual warehouse | The compute cluster that runs your SQL. “Virtual” because Snowflake hides the underlying VMs. You pick a size; Snowflake picks the machines. |
| Credit | Snowflake’s compute currency. One X-Small running for one hour burns one credit. Each size step doubles the burn rate. |
| Size step | XS → S → M → L → XL → 2XL → 3XL → 4XL → 5XL → 6XL. Each step doubles the compute and the credits per hour. |
| Gen 1 / Gen 2 | The hardware generation under the warehouse. Gen 2 uses newer chips and a smarter execution engine. Faster on most analytics workloads, but the credit rate per hour is also higher: roughly 1.35× on AWS and GCP, 1.25× on Azure. |
| Snowpark-Optimized | A warehouse type, not a size. Far more memory per node. Built for Python UDFs, ML training, and other memory-heavy code that runs inside Snowflake. |
| Auto-suspend | Idle timeout. Sit inactive for this many seconds and Snowflake powers the warehouse down. Billing stops the moment it suspends. |
| Per-second billing | You pay for the seconds the warehouse actually runs. One catch: every resume locks in a 60-second minimum, even if the query finished in two. |
Today’s Concept
Micro-Concept 1: The Size → Credit Table
Credits per hour double at every size step. The table below is fair game on the exam. You should be able to fill it from memory before Day 14.
| Size | Credits / hour | Relative compute |
|---|---|---|
| X-Small (XS) | 1 | 1× |
| Small (S) | 2 | 2× |
| Medium (M) | 4 | 4× |
| Large (L) | 8 | 8× |
| X-Large (XL) | 16 | 16× |
| 2X-Large (2XL) | 32 | 32× |
| 3X-Large (3XL) | 64 | 64× |
| 4X-Large (4XL) | 128 | 128× |
| 5X-Large (5XL) | 256 | 256× |
| 6X-Large (6XL) | 512 | 512× |
Memory trick: credits per hour = 2^N, where N is the number of steps above XS. XL is four steps up, so 2^4 = 16. Anchor on three numbers (XS=1, L=8, XL=16) and count from there. Three anchors beats ten.
Micro-Concept 2: Billing — Per-Second with a 60-Second Minimum
Two billing rules. The exam combines them in scenario questions.
- Per-second billing kicks in after the first minute. A warehouse that runs for 73 seconds is billed for 73 seconds.
- Every resume locks in a 60-second minimum. If the warehouse resumes, runs a 3-second query, and suspends, you pay for 60 seconds, not 3.
The trap this builds: an aggressively short auto-suspend can cost more than a longer one when traffic arrives in bursts. Each resume restarts the 60-second floor. On a recent client project, teams set AUTO_SUSPEND = 30 thinking they were saving money. They ended up paying back-to-back minimums every time their dashboards refreshed.
| Scenario | Actual run | Billed |
|---|---|---|
| Warehouse resumes, runs 30s, suspends | 30s | 60s (minimum) |
| Warehouse resumes, runs 61s, suspends | 61s | 61s (per-second after the 60s minimum) |
| Resumes, runs 61s, suspends, resumes again, runs 30s | 91s | 121s (60 + 1 + 60) |
Micro-Concept 3: Auto-Suspend & Auto-Resume
Both are on by default on every new warehouse. Default auto-suspend is 600 seconds (10 minutes). Auto-suspend trips when the warehouse has been idle for the configured number of seconds. Auto-resume fires the instant a statement needs it.
The docs flag one nuance that catches people out. The background process that checks for suspension runs roughly every 30 seconds. AUTO_SUSPEND = 5 is legal SQL, but you won’t see a five-second suspend in practice. The minimum effective resolution is around 30 seconds.
Tuning rules from production:
- Match auto-suspend to your query gaps. If queries arrive every 2–3 minutes and you suspend after 60 seconds, you pay a fresh 60-second minimum on each one. Set the timeout to bridge the gap.
- ETL, data loading, and task warehouses: suspend almost immediately (≤60s). No cache to keep warm.
- BI and interactive warehouses: 5–10 minutes keeps the SSD result cache warm for repeated dashboard refreshes.
- Heavy steady workloads: disable auto-suspend entirely. The warehouse is never idle long enough to benefit from suspending.
Micro-Concept 4: Gen 1 vs Gen 2 (New in C03)
Generation 2 standard warehouses became generally available on May 5, 2025. They run on AWS, Azure, and GCP, with a small set of regions still excluded. Check the live region list in the Gen 2 docs before committing. Today, Gen 2 is opt-in via either GENERATION or RESOURCE_CONSTRAINT. A behaviour change is queued (BCR-2250, bundle 2026_03) that will flip the default to Gen 2 for new standard warehouses in supported regions. Until that bundle is enabled, new warehouses still come up as Gen 1.
| Property | Gen 1 (current default) | Gen 2 (opt-in today) |
|---|---|---|
| Per-hour credit cost | Same as table above | Higher: ≈1.35× on AWS and GCP, ≈1.25× on Azure per the Service Consumption Table |
| Hardware | Original underlying instance family | Newer hardware (e.g., AWS Graviton-class instances) |
| Performance | Baseline | Faster on analytics, DML (DELETE/UPDATE/MERGE), and large scans for many workloads. Snowflake’s own TPC-DS benchmarks land in the 30–50% range. |
| Available sizes | XS through 6XL | XS through 4XL only. Not available on 5XL or 6XL. |
| Warehouse types | Standard + Snowpark-Optimized | Standard only. Snowpark-Optimized is unaffected. |
| How to specify | GENERATION = '1' or RESOURCE_CONSTRAINT = STANDARD_GEN_1 | GENERATION = '2' or RESOURCE_CONSTRAINT = STANDARD_GEN_2 |
The common Gen 2 trap: learners read “Gen 2 is faster” and assume that means cheaper. It does not, directly. Gen 2 burns more credits per hour. Net cost only goes down if the speedup beats the price uplift. Break-even on AWS sits at roughly a 26% speedup (1 − 1/1.35). For an analytics workload that scans a lot of data, that is usually achievable. For short ad-hoc queries, often not. Benchmark before flipping the switch.
Three more nuances worth holding on to:
- Existing Gen 1 warehouses stay on Gen 1 until you explicitly alter them. Snowflake does not auto-migrate.
- The
GENERATIONandRESOURCE_CONSTRAINTclauses are SQL-only today. Snowsight’s CREATE WAREHOUSE dialog does not expose them yet. - If you replicate accounts, every secondary region needs Gen 2 support too. Otherwise your Gen 2 warehouses may not resume after failover.
Micro-Concept 5: Snowpark-Optimized Warehouses
A separate warehouse type built around one constraint: memory per node. Standard warehouses are tuned for SQL throughput. Snowpark-Optimized warehouses are tuned for memory-hungry code: Snowpark Python and Java UDFs, ML training, in-memory feature engineering. If you have ever hit an out-of-memory error inside a Python UDF on a Large standard warehouse, this is the answer.
| Property | Standard warehouse | Snowpark-Optimized warehouse |
|---|---|---|
| Per-node memory | Standard | Substantially higher. Engineered for memory-heavy workloads. |
| Minimum size | X-Small | Medium |
| Credit cost | Standard rate per size | Higher per hour at the same size |
| Best for | SQL queries, dashboards, ETL | Snowpark Python / Java code, ML training, memory-heavy UDFs |
| Gen 2 applies? | Opt-in in supported regions; default change pending BCR-2250 | No. Gen 2 only applies to Standard warehouses. |
Decision rule. If the workload is code (not just SQL) and Standard hit memory errors at a reasonable size, switch to Snowpark-Optimized. For pure SQL, Standard is always cheaper at the same size. The exam tests whether you understand that “bigger Standard” and “Snowpark-Optimized” are not the same answer.
Micro-Concept 6: Auto-Resume Has Latency
Resuming a suspended warehouse usually takes one or two seconds, sometimes longer for larger sizes. It is not free. For latency-critical operational dashboards, any cold start is unacceptable. The right move there is to disable auto-suspend and absorb the cost of keeping the warehouse warm. Everywhere else, suspend.
Cheat Sheet
| Concept | What to remember |
|---|---|
| Credit doubling | XS=1, S=2, M=4, L=8, XL=16, 2XL=32, 3XL=64, 4XL=128, 5XL=256, 6XL=512 |
| Billing model | Per-second, with a 60-second minimum on every resume |
| Auto-suspend default | Enabled. Default 600s (10 minutes) in both Snowsight and SQL. Match it to your query gap. |
| Auto-resume | On by default. Fires when a statement needing the warehouse arrives. |
| Gen 1 vs Gen 2 | Gen 2 is opt-in today via GENERATION / RESOURCE_CONSTRAINT (BCR-2250 pending to make it default). Gen 2 costs more credits/hour (≈1.35× AWS and GCP, ≈1.25× Azure) but runs faster. Net cost is workload-dependent. Not on 5XL/6XL. Not for Snowpark-Optimized. |
| Specifying generation | GENERATION = '1'|'2' or RESOURCE_CONSTRAINT = STANDARD_GEN_1|STANDARD_GEN_2. SQL-only. Not in Snowsight UI yet. |
| Snowpark-Optimized | Warehouse type, not size. More memory per node. Minimum size Medium. Higher credit rate than Standard. Gen 2 does not apply. |
| Multi-cluster | Enterprise Edition or higher (covered in detail on Day 9) |
| Resizing | Does not move data. Micro-partitions stay in the storage layer. New compute nodes spin up; old ones drain. No service disruption. |
Three traps the exam dresses up around warehouses. (1) “An X-Large runs 16× faster than an X-Small.” Wrong framing. XL has 16× the compute and costs 16× the credits per hour. Actual speedup depends on the workload. Close to linear for large scans, much less for small queries. Watch for stems that conflate “compute” with “speed”. (2) “Set auto-suspend to 1 second to save money.” Wrong. Every resume hits a 60-second minimum, so aggressive cycling costs more, not less. When a question pairs short auto-suspend with bursty workloads, the answer is almost always “credits went up.” (3) “Snowpark-Optimized is just a bigger Standard.” Wrong. Different warehouse type, different per-hour rate, different minimum size (Medium), and Gen 2 does not apply to it. If the stem mentions Python UDFs out of memory or ML training, Snowpark-Optimized is the answer. Gen 2 is the distractor.
Hands-On Lab
lab_xs warehouse (created Day 1, still present per dependency map)Create an XS demo warehouse and inspect its default properties.
USE ROLE SYSADMIN;
CREATE WAREHOUSE wh_demo
WAREHOUSE_SIZE = 'XSMALL'
AUTO_SUSPEND = 60
AUTO_RESUME = TRUE;
SHOW WAREHOUSES LIKE 'wh_demo';
-- Inspect: size, type, auto_suspend, auto_resume,
-- generation/resource_constraint columnsGENERATION = '2' or RESOURCE_CONSTRAINT = STANDARD_GEN_2. Look at the type column (“STANDARD”) and the resource constraint / generation columns. Those confirm what you actually got. Once BCR-2250 is enabled by default, the generation column will read STANDARD_GEN_2 for new warehouses in supported regions.Run a query, resize the warehouse, run it again. The classic “size doubles, speed roughly doubles, cost per hour doubles” demo. Compare elapsed time at XS and Medium.
USE WAREHOUSE wh_demo;
-- Baseline on XS
SELECT COUNT(*), SUM(L_QUANTITY)
FROM SNOWFLAKE_SAMPLE_DATA.TPCH_SF10.LINEITEM;
-- Note the elapsed time in the result panel (≈ Xs)
-- Resize to MEDIUM (4× the credits, ~4× the compute)
ALTER WAREHOUSE wh_demo SET WAREHOUSE_SIZE = 'MEDIUM';
-- Same query
SELECT COUNT(*), SUM(L_QUANTITY)
FROM SNOWFLAKE_SAMPLE_DATA.TPCH_SF10.LINEITEM;
-- Compare elapsed timeVerify actual credit consumption from WAREHOUSE_METERING_HISTORY.
SELECT
START_TIME, END_TIME, WAREHOUSE_NAME,
CREDITS_USED, CREDITS_USED_COMPUTE, CREDITS_USED_CLOUD_SERVICES
FROM TABLE(INFORMATION_SCHEMA.WAREHOUSE_METERING_HISTORY(
DATEADD('hour', -1, CURRENT_TIMESTAMP())
))
WHERE WAREHOUSE_NAME = 'WH_DEMO'
ORDER BY START_TIME DESC;INFORMATION_SCHEMA returns near-real-time metering rows. ACCOUNT_USAGE lags up to three hours (that is a Day 27 distinction). The XS run and the Medium run should appear as separate rows. Look at how CREDITS_USED_COMPUTE behaves between them.Switch generation explicitly. Move the warehouse between Gen 1 and Gen 2 to see the column flip.
-- Force Gen 1 (if you want to A/B test the legacy hardware)
ALTER WAREHOUSE wh_demo SUSPEND;
ALTER WAREHOUSE wh_demo SET RESOURCE_CONSTRAINT = STANDARD_GEN_1;
ALTER WAREHOUSE wh_demo RESUME;
SHOW WAREHOUSES LIKE 'wh_demo';
-- Note the resource_constraint / generation column
-- Switch back to Gen 2 (opt-in today; will become default post-BCR-2250)
ALTER WAREHOUSE wh_demo SUSPEND;
ALTER WAREHOUSE wh_demo SET RESOURCE_CONSTRAINT = STANDARD_GEN_2;
ALTER WAREHOUSE wh_demo RESUME;STANDARD_GEN_2 set will error. That error itself is the lesson: Gen 2 is region-gated, and the exam can test you on knowing that.Create a Snowpark-Optimized warehouse. The minimum size is Medium. XS is not a legal value for this type.
CREATE WAREHOUSE wh_so
WAREHOUSE_SIZE = 'MEDIUM'
WAREHOUSE_TYPE = 'SNOWPARK-OPTIMIZED'
AUTO_SUSPEND = 60
AUTO_RESUME = TRUE;
SHOW WAREHOUSES LIKE 'wh_so';
-- type column = SNOWPARK-OPTIMIZED
-- Note: trying WAREHOUSE_SIZE = 'XSMALL' here would errortype column is what separates Standard from Snowpark-Optimized. Try the same statement with WAREHOUSE_SIZE = 'XSMALL'. Snowflake rejects it. That rejection is what the C03 question stem “what is the minimum size for Snowpark-Optimized” is testing.Cleanup.
DROP WAREHOUSE IF EXISTS wh_demo;
DROP WAREHOUSE IF EXISTS wh_so;
-- KEEP lab_xs — it's the persistent lab warehouse through Day 37lab_xs warehouse stays because it is referenced by labs running all the way to Day 37.Snowflake Documentation
External References
Sizing, billing, and Gen 2 deep-dive resources.
Practice Questions
Options:
A. 4
B. 8
C. 16
D. 32
Why C: Credits double per size step. XS=1, S=2, M=4, L=8, XL=16, 2XL=32. XL sits four steps above XS, so 2^4 = 16. This fact-recall pattern shows up almost word-for-word in published practice banks.
Why not A or B: 4 is Medium, 8 is Large. Classic off-by-one-size distractor. The question is testing whether you anchored memory on XS=1 or on M=4.
Why not D: 32 is 2X-Large. If you picked this, you counted one size too many. Re-read the cheat sheet table.
Options:
A. 5 seconds of compute, since billing is per-second
B. 60 seconds — every resume hits a 60-second minimum
C. 1 hour — warehouses are billed in hour increments
D. Zero — single queries under 10 seconds are free
Why B: Per-second billing applies after the 60-second minimum is satisfied. A 5-second query on a freshly resumed warehouse still costs 60 seconds. This is the rule the exam combines with auto-suspend tuning to build the “aggressive auto-suspend wastes credits” scenario.
Why not A: Per-second is correct only beyond the 60-second floor. The trap here is selecting the rule that is half-right.
Why not C: Snowflake has not billed in hour increments for years. If you see this option, it is an outdated-knowledge distractor.
Why not D: There is no per-query free allowance. Pure distractor.
Options:
A. Upgrade the warehouse to Generation 2 — Gen 2 has more memory per node
B. Switch to a Snowpark-Optimized warehouse at a Medium or larger size
C. Switch to an X-Small standard warehouse and let it spill to remote storage
D. Disable auto-suspend so memory accumulates across queries
Why B: Snowpark-Optimized warehouses are the standard answer for memory-bound Python or Java code inside Snowflake. They have substantially more memory per node, and Medium is the minimum legal size for this type. When the stem says “Python UDF” and “out of memory” in the same sentence, this is the answer pattern.
Why not A: Gen 2 is a performance and hardware story (faster scans, faster DML), not a memory uplift. Picking Gen 2 here is the classic “newer must be better” trap. It does not address the constraint in the question.
Why not C: Smaller is the wrong direction. OOM gets worse, not better.
Why not D: Memory does not persist between queries. Every query runs in its own execution context, so disabling auto-suspend changes nothing about per-query memory pressure.
Options:
A. Gen 2 is available at all standard warehouse sizes including 5X-Large and 6X-Large
B. Gen 2 generally finishes the same workload faster than Gen 1 at the same size
C. Gen 2 applies to both Standard and Snowpark-Optimized warehouse types
D. Gen 2 standard warehouses consume more credits per hour than Gen 1 at the same size
E. Gen 2 is specified using GENERATION = '2' or RESOURCE_CONSTRAINT = STANDARD_GEN_2
Why B: Newer hardware (Graviton-class on AWS) plus a smarter execution engine gives Gen 2 a real per-size speed advantage on most analytics workloads. Snowflake’s own TPC-DS numbers land in the 30–50% range.
Why D: Per the current Service Consumption Table, Gen 2 consumes more credits per hour than Gen 1 at the same size. The uplift is roughly 1.35× on AWS and GCP, 1.25× on Azure. Faster runtime can still produce a net win, but per-hour, Gen 2 costs more. This is the trap I see most often in the practice banks I review with trainees.
Why not A: Gen 2 is not available at 5X-Large or 6X-Large. Those sizes stay Gen 1. If the exam offers a “Gen 2 at any size” option, it is a distractor.
Why not C: Gen 2 applies only to Standard warehouses. Snowpark-Optimized is unaffected. This trap pairs two Domain 1.4 facts learners often blur together.
Note on E: E is factually true and is a legal pairing with B if D is not offered. The dirtier trap on this topic right now is “Gen 2 is the default.” It is not yet. BCR-2250 (bundle 2026_03) flips the default later. Until then, opt-in.
Options:
A. Credit usage decreases because the warehouse runs less time overall
B. Credit usage increases because every burst triggers a new 60-second minimum billing
C. The warehouse refuses to suspend below 60 seconds
D. AUTO_SUSPEND of 30 is invalid syntax and the CREATE WAREHOUSE fails
Why B: The 60-second minimum is per resume, not per day. With 30-second auto-suspend and bursts every 2 minutes, the warehouse suspends in the gap. It re-resumes for the next burst and pays a 60-second floor every cycle. A longer auto-suspend (say 120s) bridges the gap and avoids the repeated minimums. This is the scenario behind the common complaint that aggressive auto-suspend made the bill go up.
Why not A: The opposite is what happens here. The trap targets the intuition that “less idle time = less cost” while ignoring how minimum billing works.
Why not C: Snowflake accepts values below 60. It just rarely helps, and per the docs the background suspension checker only runs every ~30 seconds anyway.
Why not D: 30 is a valid AUTO_SUSPEND value. The CREATE does not fail. Pure syntax-trap distractor.
Today you learned: Virtual warehouses are MPP clusters sized XS through 6XL, with credits doubling at every step. Billing is per-second with a 60-second minimum on every resume. Aggressively short auto-suspend can increase cost, not reduce it. Generation 2 (Gen 2) is opt-in today via GENERATION or RESOURCE_CONSTRAINT, with BCR-2250 pending to make it the default. Gen 2 costs more credits per hour than Gen 1 (≈1.35× on AWS and GCP, ≈1.25× on Azure). It runs faster, so net cost depends on the workload. Gen 2 is unavailable at 5XL and 6XL, and does not apply to Snowpark-Optimized. Snowpark-Optimized is a separate warehouse type with substantially more memory per node and a minimum size of Medium. Reach for it when memory-heavy Python or Java code is the workload.
Key takeaway: Three knobs decide what a warehouse costs and how fast it runs. Those knobs are size (compute, doubles), type (Standard vs Snowpark-Optimized), and generation (Gen 1 vs Gen 2). Pick all three based on the workload, not on instinct.
Tomorrow (Day 9): Multi-Cluster Warehouses & Scaling Policies. The day covers scaling UP (size) versus scaling OUT (clusters), and the Standard vs Economy scaling policy difference. It also explains why multi-cluster needs Enterprise Edition or higher, with the BI-team-of-50 high-concurrency pattern as the worked example.
