Skip to main content
πŸ“–

Key Terms β€” Virtual Warehouses

VW

Virtual Warehouse

A named cluster of compute resources (CPU, memory, local SSD cache) in Snowflake that executes SQL queries, DML statements, and data loading operations. Completely independent from storage; can be started and stopped without affecting data.

CR

Credit

Snowflake's unit of compute consumption. Credits are consumed only when a virtual warehouse is in the STARTED state and actively processing queries or maintaining a warm cache. An X-Small warehouse consumes 1 credit per hour.

AS

Auto-Suspend

A warehouse property (AUTO_SUSPEND, measured in seconds) that causes the warehouse to automatically suspend after a specified period of inactivity. Suspended warehouses consume zero credits.

AR

Auto-Resume

A warehouse property (AUTO_RESUME = TRUE) that causes a suspended warehouse to automatically resume when a query is submitted to it. Enables pay-per-use without manual intervention.

MCW

Multi-Cluster Warehouse

An Enterprise edition feature where a single warehouse can span multiple compute clusters. Clusters are automatically added or removed based on query queue depth, eliminating concurrency bottlenecks.

SP

Scaling Policy

Controls how a multi-cluster warehouse adds and removes clusters. STANDARD policy adds clusters aggressively when queues form; ECONOMY policy waits longer before adding clusters to optimise credit usage.

RM

Resource Monitor

An account-level or warehouse-level object that tracks credit usage and can trigger notifications or warehouse suspensions when a defined credit quota is reached within a specified time window.

QP

Query Profile

A visual execution plan available in Snowsight that shows how a query was processed across operator nodes, enabling identification of performance bottlenecks such as expensive joins, large spills, or partition pruning inefficiency.

WQ

Warehouse Queuing

When a single-cluster warehouse is processing the maximum number of concurrent queries, additional queries are placed in a queue and wait for resources. Multi-cluster warehouses eliminate queuing by adding clusters.

MCL

Maximum Concurrency Level

The MAX_CONCURRENCY_LEVEL parameter controls the maximum number of SQL statements a single warehouse cluster will execute concurrently before additional queries are queued.

Why This Topic Matters for the Exam

Virtual warehouses are Snowflake’s compute engine β€” understanding them thoroughly is essential for the COF-C02 exam. Questions on warehouses span multiple exam domains: Architecture (what they are and how they work), Performance Concepts (sizing, scaling, caching), and Account & Security (resource monitors, access control). The exam frequently tests auto-suspend/resume behaviour, the 60-second minimum billing rule, multi-cluster warehouse scaling policies, and the distinction between Standard and ECONOMY scaling policies.

Candidates who understand warehouses deeply can also answer questions on credit consumption, concurrency management, and cost optimisation strategies β€” areas that account for a significant portion of the exam.

🎯Exam Weight: Very High Priority

Virtual warehouses appear in questions across at least three exam domains. Expect 10–15 questions on warehouse sizing, credits, auto-suspend/resume, multi-cluster behaviour, scaling policies, resource monitors, and warehouse monitoring views. This is the single highest-weight topic on the COF-C02 exam.


What is a Virtual Warehouse?

A Virtual Warehouse is an MPP (Massively Parallel Processing) cluster of compute nodes that executes SQL queries in Snowflake. It is the compute layer of Snowflake’s three-layer architecture, sitting between the cloud services layer (query parsing, optimisation, metadata) and the storage layer (data in cloud object storage).

Snowflake Three-Layer Architecture: Warehouse Position

A three-tier architecture diagram showing Snowflake's separation of storage, compute, and services. The top layer is labelled 'Cloud Services Layer' and contains boxes for: Query Parser, Query Optimiser, Metadata Manager, Access Control, Transaction Manager, and Security. A two-headed arrow points downward to the middle layer labelled 'Compute Layer (Virtual Warehouses)'. This layer shows three separate warehouse icons β€” Warehouse A (X-Large, for ETL), Warehouse B (Small, for BI), and Warehouse C (Medium, for Data Science). Each warehouse is completely isolated from the others, indicated by thick borders. A second two-headed arrow points down to the bottom layer labelled 'Storage Layer', which shows columnar data files in compressed micro-partitions stored in cloud object storage (S3, Azure Blob, or GCS). Critically, there are no arrows between the three warehouse boxes β€” they share storage but do not share compute. A callout bubble reads: 'Warehouses can be started, stopped, and resized independently without affecting stored data.'

Snowflake three-layer architecture showing virtual warehouse independence from storage

Core Properties of Virtual Warehouses

  • Completely independent from storage: Starting, stopping, or resizing a warehouse has zero impact on the data stored in Snowflake
  • Multiple warehouses can read the same data simultaneously: Because storage is separate, different teams can run different warehouses against the same tables without interference
  • Credits are only consumed when running: A suspended warehouse costs nothing; you pay only for active compute time
  • Local SSD cache per warehouse: Each warehouse maintains a local cache of recently accessed micro-partitions, which is lost when the warehouse is suspended
πŸ”‘Warehouses Do Not Share Cache

Each virtual warehouse maintains its own local SSD data cache. If Warehouse A warms up its cache by scanning a large table, Warehouse B querying the same table will scan from cloud storage and build its own cache independently. This is why consistent warehouse usage improves performance β€” repeated queries benefit from the warm cache.


Warehouse States

A virtual warehouse transitions between four states throughout its lifecycle:

StateDescriptionCredits Consumed
STARTEDRunning and ready to process queriesYes β€” per-second billing
SUSPENDEDInactive; no compute resources allocatedNo β€” zero credits
STARTINGTransitioning from SUSPENDED to STARTEDNo β€” brief transition (typically seconds)
RESIZINGCluster is scaling up or down to a new sizeYes β€” billed at the new size once complete
πŸ’‘Resizing is Near-Instant for Scale-Up

When you resize a warehouse to a larger size, Snowflake provisions new nodes and begins routing queries to the expanded cluster almost immediately. Scaling down is also fast. Neither operation requires data movement or impacts running queries.


Warehouse Sizes and Credit Consumption

Snowflake offers a range of warehouse sizes, each doubling compute resources (and credit consumption) compared to the previous size. Understanding the credit-per-hour rates is essential for both the exam and real-world cost management.

Warehouse Sizes and Credit Consumption

A bar chart showing all Snowflake warehouse sizes on the X-axis from left to right: X-Small, Small, Medium, Large, X-Large, 2X-Large, 3X-Large, 4X-Large. The Y-axis shows credits per hour. Each bar doubles the previous: X-Small=1, Small=2, Medium=4, Large=8, X-Large=16, 2X-Large=32, 3X-Large=64, 4X-Large=128. A second overlaid line shows approximate query performance scaling β€” labelled 'relative performance' β€” which rises steeply at first and then flattens, illustrating diminishing returns from very large warehouses for most workloads. A callout box notes that per-second billing applies after the first 60 seconds. A shaded region on the right side of the chart is labelled 'Typically used for batch ETL, ML training, or very large data transformations' covering 2X-Large through 4X-Large. The region covering X-Small through Medium is labelled 'Typical for BI dashboards and ad-hoc analysis'.

Bar chart of Snowflake warehouse sizes and their credit consumption rates per hour
Warehouse SizeCredits / HourTypical Use Case
X-Small1Development, testing, low-concurrency dashboards
Small2Small team BI, light ETL
Medium4Mid-size ETL, moderate concurrency BI
Large8Heavy ETL, data science workloads
X-Large16Large batch transformations
2X-Large32Very large transformations, ML feature engineering
3X-Large64Massive batch processing
4X-Large128Extreme batch workloads, maximum parallelism
🎯Credit Rate Memorisation Tip

The exam expects you to know that X-Small = 1 credit/hour and that each size doubles the credits. You do not need to memorise every size, but knowing the X-Small baseline and the doubling pattern lets you calculate any size: Small=2, Medium=4, Large=8, X-Large=16, 2X-Large=32, 3X-Large=64, 4X-Large=128.


Auto-Suspend and Auto-Resume

These two parameters together enable the serverless pricing model that makes Snowflake cost-effective: you pay only when queries are running.

Auto-Suspend

The AUTO_SUSPEND parameter specifies the number of seconds of inactivity after which the warehouse automatically suspends itself.

  • Default value: 600 seconds (10 minutes)
  • Minimum value: 60 seconds
  • Set to NULL or 0 to disable auto-suspend (warehouse runs indefinitely until manually suspended)
  • When suspended, the warehouse’s local SSD cache is lost

Auto-Resume

The AUTO_RESUME parameter (boolean) determines whether the warehouse automatically resumes when a query is submitted to it.

  • Default value: TRUE
  • When TRUE: warehouse resumes automatically on query submission with no manual intervention
  • When FALSE: warehouse must be manually resumed with ALTER WAREHOUSE ... RESUME before queries will run
🎯60-Second Minimum Billing β€” Critically Tested

Every time a virtual warehouse resumes from a SUSPENDED state, Snowflake charges a minimum of 60 seconds of credit consumption, regardless of how quickly the query completes. If a query takes 5 seconds and the warehouse was suspended, you are still billed for 60 seconds. This is one of the most frequently tested facts about virtual warehouses on the COF-C02 exam. After the initial 60 seconds, billing is per-second.

Auto-Suspend and Auto-Resume Timeline

A horizontal timeline diagram illustrating warehouse state transitions. At the far left, a warehouse is shown in the STARTED state (green). A clock icon shows the AUTO_SUSPEND timer counting down from 600 seconds during a period of no query activity. When the timer reaches zero, the warehouse transitions to SUSPENDED state (grey icon, zero credits label). Time continues on the timeline. Then, a new query arrives (represented by a lightning bolt icon), triggering AUTO_RESUME. The warehouse transitions through STARTING state (yellow, brief) to STARTED state (green) again. A red rectangle underneath the STARTED state segment beginning at the resume point is labelled '60-second minimum billing window'. A callout explains: even if the query finishes in 10 seconds, the full 60-second minimum is billed. After the 60-second window, billing becomes per-second. A second scenario shows a short query (5 seconds) versus a long query (300 seconds), both billed at least 60 seconds on resume.

Timeline showing warehouse auto-suspend, auto-resume, and the 60-second minimum billing window

Creating and Configuring Warehouses

CREATE WAREHOUSE β€” Full Syntax with All Key Parameters
1-- Full CREATE WAREHOUSE with all key parameters
2CREATE WAREHOUSE etl_warehouse
3WAREHOUSE_SIZE = 'LARGE' -- compute size
4WAREHOUSE_TYPE = 'STANDARD' -- STANDARD or SNOWPARK-OPTIMIZED
5AUTO_SUSPEND = 300 -- suspend after 5 minutes idle
6AUTO_RESUME = TRUE -- auto-resume on query submission
7INITIALLY_SUSPENDED = TRUE -- start in suspended state
8MAX_CONCURRENCY_LEVEL = 8 -- max concurrent queries before queuing
9STATEMENT_TIMEOUT_IN_SECONDS = 3600 -- kill queries running > 1 hour
10STATEMENT_QUEUED_TIMEOUT_IN_SECONDS = 600 -- timeout queued queries after 10 min
11COMMENT = 'Nightly ETL warehouse β€” Large, auto-suspended';
12
13-- Create a minimal warehouse with sensible defaults
14CREATE WAREHOUSE reporting_wh
15WAREHOUSE_SIZE = 'SMALL'
16AUTO_SUSPEND = 120
17AUTO_RESUME = TRUE
18INITIALLY_SUSPENDED = TRUE;
19
20-- Verify warehouse was created
21SHOW WAREHOUSES LIKE 'etl_warehouse';
ALTER WAREHOUSE β€” Resize, Change Settings, Suspend & Resume
1-- Set the active warehouse for the current session
2USE WAREHOUSE reporting_wh;
3
4-- Resize a warehouse (takes effect near-instantly)
5ALTER WAREHOUSE etl_warehouse
6SET WAREHOUSE_SIZE = 'X-LARGE';
7
8-- Change auto-suspend interval
9ALTER WAREHOUSE reporting_wh
10SET AUTO_SUSPEND = 60;
11
12-- Disable auto-suspend (warehouse runs until manually stopped)
13ALTER WAREHOUSE etl_warehouse
14SET AUTO_SUSPEND = NULL;
15
16-- Manually suspend a warehouse immediately
17ALTER WAREHOUSE reporting_wh SUSPEND;
18
19-- Manually resume a suspended warehouse
20ALTER WAREHOUSE reporting_wh RESUME;
21
22-- Resize and change multiple settings in one ALTER
23ALTER WAREHOUSE etl_warehouse SET
24WAREHOUSE_SIZE = 'MEDIUM'
25AUTO_SUSPEND = 300
26MAX_CONCURRENCY_LEVEL = 4;
27
28-- Change the statement timeout
29ALTER WAREHOUSE reporting_wh
30SET STATEMENT_TIMEOUT_IN_SECONDS = 1800; -- 30 minutes
31
32-- Show current warehouse status
33SHOW WAREHOUSES;

Multi-Cluster Warehouses (Enterprise Edition)

Multi-cluster warehouses are an Enterprise edition feature that allows a single logical warehouse to span multiple independent compute clusters. This is the primary solution to concurrency bottlenecks in Snowflake.

When to Use Multi-Cluster Warehouses

A single warehouse cluster has a limited number of concurrent query slots. When that limit is reached, additional queries are queued and wait for resources. Multi-cluster warehouses automatically add clusters when queues form and remove them when load decreases.

Multi-Cluster Warehouse: Auto-Scale Mode

A dynamic diagram showing a multi-cluster warehouse operating in auto-scale mode. At the top is a label showing 'Warehouse: BI_WAREHOUSE β€” MIN_CLUSTER_COUNT=1, MAX_CLUSTER_COUNT=4, SCALING_POLICY=STANDARD'. Three time periods are shown left to right. Period 1 (Low load, 9am): A single cluster (Cluster 1) processes 8 queries shown as small arrows. No queue. Period 2 (Peak load, 12pm): Cluster 1 is at capacity with 8 queries. A queue of 12 additional queries forms to the right, shown as stacked icons. Snowflake's cloud services layer detects the queue and provisions Cluster 2 (shown appearing below Cluster 1) and Cluster 3. The queue drains as queries are distributed across all three clusters. Period 3 (Load decreasing, 2pm): Query volume drops. Cluster 3 finishes its current queries and idles for the consecutive-successful-queries threshold, then is shut down. Cluster 2 also shuts down. Only Cluster 1 remains active. The transition arrows between periods are labelled 'Scale Out' and 'Scale In'. A credit counter in the corner shows increasing credit consumption during peak and decreasing during scale-in.

Diagram of multi-cluster warehouse scaling out during peak load and scaling in as load decreases

Key Multi-Cluster Parameters

Creating a Multi-Cluster Warehouse
1-- Multi-cluster warehouse in Auto-scale mode (Enterprise edition required)
2CREATE WAREHOUSE bi_warehouse
3WAREHOUSE_SIZE = 'MEDIUM'
4MIN_CLUSTER_COUNT = 1 -- minimum clusters always running
5MAX_CLUSTER_COUNT = 4 -- maximum clusters allowed
6SCALING_POLICY = 'STANDARD' -- STANDARD or ECONOMY
7AUTO_SUSPEND = 300
8AUTO_RESUME = TRUE
9INITIALLY_SUSPENDED = FALSE
10COMMENT = 'BI warehouse β€” scales from 1 to 4 clusters automatically';
11
12-- Maximized mode: all clusters always running (fixed concurrency)
13-- Use when you have predictably high, sustained concurrency
14CREATE WAREHOUSE high_concurrency_wh
15WAREHOUSE_SIZE = 'SMALL'
16MIN_CLUSTER_COUNT = 3 -- always run exactly 3 clusters
17MAX_CLUSTER_COUNT = 3 -- same as min = Maximized mode
18SCALING_POLICY = 'STANDARD'
19AUTO_SUSPEND = 600
20AUTO_RESUME = TRUE;
21
22-- Convert existing single-cluster to multi-cluster
23ALTER WAREHOUSE reporting_wh SET
24MIN_CLUSTER_COUNT = 1
25MAX_CLUSTER_COUNT = 3
26SCALING_POLICY = 'ECONOMY';
27
28-- Check multi-cluster warehouse status
29SHOW WAREHOUSES LIKE 'bi_warehouse';

Scaling Policies: STANDARD vs ECONOMY

Multi-Cluster Scaling Policy: STANDARD vs ECONOMY

Feature
STANDARD Policy
ECONOMY Policy
Cluster addition trigger
Adds a cluster immediately when a query queue forms
Waits until the queue is large enough that adding a cluster would improve performance (conservative)
Primary goal
Minimise query wait time β€” prioritise performance
Minimise credit consumption β€” prioritise cost efficiency
Cluster removal trigger
Removes idle clusters after 2-3 consecutive successful query evaluations
Removes clusters only after a longer idle period, avoiding premature scale-in
Best for
BI dashboards, ad-hoc analysis, unpredictable spiky load
Batch workloads, predictable load, cost-sensitive environments
Response to sudden load spike
βœ“Fast scale-out β€” adds cluster almost immediately
Slower scale-out β€” evaluates load before committing to additional cluster
Cost optimisation
Higher cost β€” acts quickly, may add clusters for brief spikes
βœ“Lower cost β€” avoids adding clusters for brief queue formations
🎯STANDARD vs ECONOMY Scaling Policy

The exam distinguishes STANDARD from ECONOMY by their primary goal. STANDARD prioritises query performance (minimise wait time) by adding clusters quickly. ECONOMY prioritises cost (minimise credits) by waiting longer before adding clusters. If the exam asks which policy to choose to reduce costs at the risk of slightly higher latency, the answer is ECONOMY.

Maximized Mode vs Auto-Scale Mode

  • Auto-scale mode: MIN_CLUSTER_COUNT < MAX_CLUSTER_COUNT. Snowflake dynamically adds and removes clusters between the min and max. The default and most common mode.
  • Maximized mode: MIN_CLUSTER_COUNT = MAX_CLUSTER_COUNT. All clusters are always running. No dynamic scaling β€” provides fixed, predictable concurrency. Best for steady-state, very high concurrency environments.

Query Queuing and Concurrency

Understanding how Snowflake handles query concurrency is critical for both the exam and real-world troubleshooting.

When a warehouse is processing the maximum number of concurrent queries (MAX_CONCURRENCY_LEVEL), additional queries are placed in a queue. Queued queries wait until a slot opens up (when a running query completes) or until the queue timeout is reached.

Managing Query Queuing and Timeouts
1-- Set the maximum concurrent queries before queuing begins
2ALTER WAREHOUSE reporting_wh
3SET MAX_CONCURRENCY_LEVEL = 8;
4
5-- Set timeout for queued queries (seconds)
6-- If a query waits longer than this in the queue, it fails with an error
7ALTER WAREHOUSE reporting_wh
8SET STATEMENT_QUEUED_TIMEOUT_IN_SECONDS = 300; -- 5 minutes
9
10-- Set timeout for running statements
11-- Queries running longer than this are automatically killed
12ALTER WAREHOUSE reporting_wh
13SET STATEMENT_TIMEOUT_IN_SECONDS = 7200; -- 2 hours
14
15-- Check current queue depth and active queries
16SELECT *
17FROM TABLE(INFORMATION_SCHEMA.WAREHOUSE_LOAD_HISTORY(
18DATE_RANGE_START => DATEADD('hour', -1, CURRENT_TIMESTAMP()),
19DATE_RANGE_END => CURRENT_TIMESTAMP(),
20WAREHOUSE_NAME => 'REPORTING_WH'
21));
22
23-- View current and recently queued queries
24SELECT
25query_id,
26user_name,
27warehouse_name,
28execution_status,
29queued_provisioning_time / 1000 AS queued_seconds,
30execution_time / 1000 AS execution_seconds,
31LEFT(query_text, 100) AS query_preview
32FROM snowflake.account_usage.query_history
33WHERE warehouse_name = 'REPORTING_WH'
34AND start_time >= DATEADD('hour', -1, CURRENT_TIMESTAMP())
35ORDER BY start_time DESC;
πŸ’‘Multi-Cluster is the Right Fix for Queuing Problems

If users are experiencing query queuing, the correct solution is to enable multi-cluster mode (Enterprise edition) rather than simply resizing the warehouse. Resizing improves individual query performance but does not increase concurrency. Multi-cluster warehouses add entire clusters to handle more concurrent queries simultaneously.


Warehouse Monitoring

Snowflake provides multiple views for monitoring warehouse performance and credit consumption.

Warehouse Monitoring Queries
1-- 1. Credit consumption by warehouse over the last 7 days (ACCOUNT_USAGE)
2SELECT
3warehouse_name,
4SUM(credits_used) AS total_credits,
5SUM(credits_used_compute) AS compute_credits,
6SUM(credits_used_cloud_services) AS cloud_service_credits,
7COUNT(*) AS billing_periods
8FROM snowflake.account_usage.warehouse_metering_history
9WHERE start_time >= DATEADD('day', -7, CURRENT_TIMESTAMP())
10GROUP BY warehouse_name
11ORDER BY total_credits DESC;
12
13-- 2. Warehouse load over time (INFORMATION_SCHEMA β€” current DB, near real-time)
14SELECT
15start_time,
16end_time,
17warehouse_name,
18avg_running, -- average concurrent queries running
19avg_queued_load -- average queries in the queue
20FROM TABLE(INFORMATION_SCHEMA.WAREHOUSE_LOAD_HISTORY(
21DATE_RANGE_START => DATEADD('hour', -4, CURRENT_TIMESTAMP()),
22WAREHOUSE_NAME => 'REPORTING_WH'
23))
24ORDER BY start_time DESC;
25
26-- 3. Recent query performance on a specific warehouse
27SELECT
28query_id,
29user_name,
30query_type,
31execution_status,
32ROUND(execution_time / 1000, 2) AS exec_seconds,
33ROUND(bytes_scanned / POWER(1024,3), 4) AS gb_scanned,
34partitions_scanned,
35partitions_total,
36ROUND(partitions_scanned / NULLIF(partitions_total, 0) * 100, 1) AS pct_scanned,
37LEFT(query_text, 200) AS query_preview
38FROM snowflake.account_usage.query_history
39WHERE warehouse_name = 'ETL_WAREHOUSE'
40AND start_time >= DATEADD('day', -1, CURRENT_TIMESTAMP())
41AND execution_status = 'SUCCESS'
42ORDER BY execution_time DESC
43LIMIT 50;
44
45-- 4. Identify warehouses with high queuing
46SELECT
47warehouse_name,
48AVG(avg_queued_load) AS avg_queue_depth,
49MAX(avg_queued_load) AS max_queue_depth
50FROM snowflake.account_usage.warehouse_load_history
51WHERE start_time >= DATEADD('day', -7, CURRENT_TIMESTAMP())
52GROUP BY warehouse_name
53HAVING avg_queue_depth > 0.5
54ORDER BY avg_queue_depth DESC;

Resource Monitors

Resource monitors allow administrators to track credit usage and automatically take action (notify, suspend, or force-suspend warehouses) when a defined credit quota is reached within a specified time window.

Resource Monitor Architecture

A layered diagram showing the resource monitor architecture. At the top is an 'Account Resource Monitor' box labelled 'Account-level β€” controls all warehouses'. Below it are three 'Warehouse Resource Monitor' boxes, each labelled with a warehouse name: ETL_WAREHOUSE, REPORTING_WH, BI_WAREHOUSE. Each warehouse monitor box has a credit quota dial showing a percentage used. On the right side is an 'Actions' panel showing four possible triggers: 1) NOTIFY β€” sends an email alert at the specified threshold (e.g., 75% of quota); 2) NOTIFY & SUSPEND β€” sends alert and suspends the warehouse after current queries finish (at e.g., 90%); 3) NOTIFY & SUSPEND_IMMEDIATE β€” sends alert and kills all running queries immediately (at e.g., 100%); 4) Multiple thresholds can be set β€” shown as a graduated scale from 75% to 100%. A callout explains that resource monitors reset at the start of each time window (DAILY, WEEKLY, MONTHLY, YEARLY, or NEVER). Arrows show that account-level monitors affect all warehouses unless overridden by a warehouse-level monitor.

Architecture diagram of Snowflake resource monitors showing account and warehouse level monitoring with notification and suspension actions
Creating and Assigning Resource Monitors
1-- Create an account-level resource monitor
2-- Monitors all credit usage in the account per month
3CREATE RESOURCE MONITOR account_monthly_monitor
4WITH CREDIT_QUOTA = 5000 -- 5,000 credits per period
5FREQUENCY = MONTHLY -- reset at start of each month
6START_TIMESTAMP = IMMEDIATELY
7TRIGGERS
8 ON 75 PERCENT DO NOTIFY -- email alert at 75%
9 ON 90 PERCENT DO NOTIFY -- email alert at 90%
10 ON 100 PERCENT DO SUSPEND -- suspend warehouses gracefully at 100%
11 ON 110 PERCENT DO SUSPEND_IMMEDIATE; -- force-kill at 110% (overage protection)
12
13-- Apply the resource monitor at the account level
14ALTER ACCOUNT SET RESOURCE_MONITOR = account_monthly_monitor;
15
16-- Create a warehouse-specific resource monitor
17CREATE RESOURCE MONITOR etl_weekly_monitor
18WITH CREDIT_QUOTA = 200 -- 200 credits per week
19FREQUENCY = WEEKLY
20START_TIMESTAMP = IMMEDIATELY
21TRIGGERS
22 ON 80 PERCENT DO NOTIFY
23 ON 100 PERCENT DO SUSPEND_IMMEDIATE;
24
25-- Assign resource monitor to a specific warehouse
26ALTER WAREHOUSE etl_warehouse
27SET RESOURCE_MONITOR = etl_weekly_monitor;
28
29-- View all resource monitors and their current usage
30SHOW RESOURCE MONITORS;
31
32-- View credit usage for resource monitors
33SELECT *
34FROM snowflake.account_usage.resource_monitors
35ORDER BY created_on DESC;
⚠️SUSPEND vs SUSPEND_IMMEDIATE

The SUSPEND action waits for currently running queries to finish before suspending the warehouse. SUSPEND_IMMEDIATE kills all running queries immediately and suspends the warehouse. Using SUSPEND_IMMEDIATE at 100% prevents any additional credits from being consumed but will abort in-flight queries β€” use it carefully in production environments.


Step-by-Step: Configuring a Cost-Optimised Warehouse Setup

Setting Up a Multi-Warehouse Architecture with Resource Monitors

1
Design the Warehouse Topology

Separate workloads onto dedicated warehouses to prevent ETL from competing with BI queries. This is a fundamental Snowflake best practice and a common exam topic.

πŸ’‘Use separate warehouses for ETL, BI reporting, data science, and loading. Each warehouse can be sized and auto-suspended independently, preventing any single workload from starving others of resources.
2
Create the ETL Warehouse

Create a large warehouse for nightly ETL runs. It should auto-suspend quickly after batch completion to avoid wasting credits during idle hours.

SQL
-- ETL warehouse: Large for bulk transforms, quick auto-suspend
CREATE WAREHOUSE etl_nightly_wh
WAREHOUSE_SIZE         = 'LARGE'
AUTO_SUSPEND           = 120           -- suspend 2 minutes after last query
AUTO_RESUME            = TRUE
INITIALLY_SUSPENDED    = TRUE          -- don't charge until first use
MAX_CONCURRENCY_LEVEL  = 4
STATEMENT_TIMEOUT_IN_SECONDS = 14400   -- kill runaway queries after 4hrs
COMMENT = 'Nightly ETL β€” Large, 2-min auto-suspend';
πŸ’‘Setting INITIALLY_SUSPENDED = TRUE means you don't pay credits just for creating the warehouse. It resumes on first use via AUTO_RESUME.
3
Create the BI Reporting Warehouse with Multi-Cluster

Create a Medium multi-cluster warehouse for BI dashboards. Multiple analysts hit this warehouse simultaneously during business hours, so multi-cluster prevents queuing.

SQL
-- BI warehouse: Medium with multi-cluster for concurrent analysts
-- Requires Enterprise edition or higher
CREATE WAREHOUSE bi_reporting_wh
WAREHOUSE_SIZE      = 'MEDIUM'
MIN_CLUSTER_COUNT   = 1
MAX_CLUSTER_COUNT   = 3
SCALING_POLICY      = 'STANDARD'       -- fast scale-out for BI
AUTO_SUSPEND        = 300              -- 5-minute auto-suspend
AUTO_RESUME         = TRUE
INITIALLY_SUSPENDED = TRUE
COMMENT = 'BI reporting β€” Medium, 1-3 clusters, Standard scaling';
4
Create the Resource Monitor

Protect the account from unexpected credit overruns by creating a monthly resource monitor with tiered notification and suspension triggers.

SQL
-- Monthly resource monitor with tiered actions
CREATE RESOURCE MONITOR monthly_cost_guard
WITH CREDIT_QUOTA = 3000
FREQUENCY        = MONTHLY
START_TIMESTAMP  = IMMEDIATELY
TRIGGERS
  ON 50  PERCENT DO NOTIFY
  ON 75  PERCENT DO NOTIFY
  ON 90  PERCENT DO NOTIFY
  ON 100 PERCENT DO SUSPEND
  ON 110 PERCENT DO SUSPEND_IMMEDIATE;

-- Apply to all warehouses at account level
ALTER ACCOUNT SET RESOURCE_MONITOR = monthly_cost_guard;

-- Apply stricter individual monitor to ETL warehouse
CREATE RESOURCE MONITOR etl_weekly_budget
WITH CREDIT_QUOTA = 500
FREQUENCY        = WEEKLY
START_TIMESTAMP  = IMMEDIATELY
TRIGGERS
  ON 80  PERCENT DO NOTIFY
  ON 100 PERCENT DO SUSPEND_IMMEDIATE;

ALTER WAREHOUSE etl_nightly_wh
SET RESOURCE_MONITOR = etl_weekly_budget;
πŸ’‘Individual warehouse monitors override the account-level monitor for that specific warehouse. Assign stricter budgets to high-cost warehouses.
5
Verify the Configuration

Use SHOW commands and account usage views to confirm the warehouse and resource monitor configuration is correct.

SQL
-- Confirm warehouse settings
SHOW WAREHOUSES;

-- Confirm resource monitors
SHOW RESOURCE MONITORS;

-- Test auto-resume by submitting a query to the suspended warehouse
USE WAREHOUSE bi_reporting_wh;
SELECT CURRENT_WAREHOUSE(), CURRENT_TIMESTAMP();

-- Monitor credit consumption after a few hours
SELECT
warehouse_name,
SUM(credits_used) AS total_credits
FROM snowflake.account_usage.warehouse_metering_history
WHERE start_time >= CURRENT_DATE()
GROUP BY warehouse_name
ORDER BY total_credits DESC;

Snowpark-Optimised Warehouses

Snowflake also offers a SNOWPARK-OPTIMIZED warehouse type designed for Python, Scala, and Java workloads that require large amounts of memory per node (e.g., ML model training, pandas DataFrames).

Snowpark-Optimised Warehouse
1-- Create a Snowpark-Optimized warehouse for ML workloads
2-- These warehouses have ~16x more memory per node than STANDARD warehouses
3CREATE WAREHOUSE ml_training_wh
4WAREHOUSE_SIZE = 'MEDIUM'
5WAREHOUSE_TYPE = 'SNOWPARK-OPTIMIZED'
6AUTO_SUSPEND = 600
7AUTO_RESUME = TRUE
8INITIALLY_SUSPENDED = TRUE
9COMMENT = 'Snowpark ML training β€” high memory per node';
10
11-- Standard warehouses for regular SQL and Python UDFs
12CREATE WAREHOUSE analytics_wh
13WAREHOUSE_SIZE = 'SMALL'
14WAREHOUSE_TYPE = 'STANDARD' -- default type
15AUTO_SUSPEND = 180
16AUTO_RESUME = TRUE;
πŸ“When to Use Snowpark-Optimised Warehouses

Use SNOWPARK-OPTIMIZED warehouses when your Python or Scala workloads are memory-intensive β€” for example, training large machine learning models, working with large pandas DataFrames in Snowpark, or running complex Python UDTFs. For regular SQL and lightweight Python UDFs, a STANDARD warehouse is more cost-effective.


Quick Reference Cheat Sheet

πŸ“‹
Quick Reference

Virtual Warehouses β€” COF-C02 Cheat Sheet

C
Credit Consumption by Size
X-Small
1 credit/hrβ€” Dev, testing, low-concurrency
Small
2 credits/hrβ€” Small team BI, light ETL
Medium
4 credits/hrβ€” Standard BI and ETL
Large
8 credits/hrβ€” Heavy ETL, data science
X-Large
16 credits/hrβ€” Large batch transforms
2X-Large
32 credits/hrβ€” Very large workloads
3X-Large
64 credits/hrβ€” Massive batch processing
4X-Large
128 credits/hrβ€” Maximum parallelism
P
Key Parameters
AUTO_SUSPEND
Seconds of idle before suspendβ€” Default: 600s (10 min), min 60s
AUTO_RESUME
TRUE / FALSEβ€” Default: TRUE β€” auto-resume on query
INITIALLY_SUSPENDED
TRUE / FALSEβ€” Start suspended to avoid immediate billing
MAX_CONCURRENCY_LEVEL
Integerβ€” Max concurrent queries before queuing
STATEMENT_TIMEOUT_IN_SECONDS
Integer (seconds)β€” Kill long-running queries automatically
WAREHOUSE_TYPE
STANDARD or SNOWPARK-OPTIMIZEDβ€” High-memory for ML workloads
M
Multi-Cluster Parameters
MIN_CLUSTER_COUNT
Integer >= 1β€” Minimum clusters always running
MAX_CLUSTER_COUNT
Integer >= MINβ€” Upper bound on cluster count
SCALING_POLICY
STANDARD or ECONOMYβ€” STANDARD = fast; ECONOMY = cost-efficient
Auto-scale mode
MIN < MAXβ€” Dynamic scaling between min and max
Maximized mode
MIN = MAXβ€” All clusters always running
Edition required
Enterprise or higherβ€” Not available on Standard edition
R
Resource Monitor Actions
NOTIFY
Send email alertβ€” No impact on warehouse operation
SUSPEND
Graceful suspendβ€” Waits for running queries to complete
SUSPEND_IMMEDIATE
Force suspendβ€” Kills running queries immediately
Frequency options
DAILY, WEEKLY, MONTHLY, YEARLY, NEVERβ€” Controls quota reset period
B
Billing Rules
Minimum billing on resume
60 secondsβ€” Even if query takes 1 second
After first 60 seconds
Per-second billingβ€” Granular billing after minimum
Suspended state
Zero creditsβ€” No compute cost when suspended
Cloud services
Separate credit poolβ€” Billed only above 10% of compute

Practice Quiz

Virtual Warehouses

A Snowflake warehouse is suspended. A user submits a query that takes exactly 8 seconds to complete. The warehouse then idles and auto-suspends after 2 minutes. How many seconds of compute credits are charged for this activity?

Virtual Warehouses

A company runs Snowflake Standard edition and wants to configure a multi-cluster warehouse with MIN_CLUSTER_COUNT=1 and MAX_CLUSTER_COUNT=4 to handle peak concurrency. What will happen when they attempt to create this warehouse?

Virtual Warehouses

A resource monitor is configured with CREDIT_QUOTA=1000, FREQUENCY=MONTHLY, and the following triggers: ON 75 PERCENT DO NOTIFY, ON 100 PERCENT DO SUSPEND, ON 110 PERCENT DO SUSPEND_IMMEDIATE. The warehouse has consumed 1,050 credits this month. What is the current state of the warehouse?


Flashcard Exam Prep

Virtual Warehouses
QUESTION

What is the minimum number of seconds billed each time a virtual warehouse resumes from a SUSPENDED state?

Click to reveal answer
ANSWER

60 seconds. Every time a warehouse resumes, Snowflake charges a minimum of 60 seconds of credit consumption regardless of how quickly the query completes. After the first 60 seconds, billing is per-second. This applies even if the query runs for only 1-2 seconds.

Click to see question
Virtual Warehouses
QUESTION

What Snowflake edition is required to use multi-cluster warehouses?

Click to reveal answer
ANSWER

Enterprise edition or higher (Business Critical or Virtual Private Snowflake). Multi-cluster warehouses are NOT available on the Standard edition. They are configured with MIN_CLUSTER_COUNT and MAX_CLUSTER_COUNT parameters.

Click to see question
Virtual Warehouses
QUESTION

What is the difference between SCALING_POLICY STANDARD and ECONOMY in a multi-cluster warehouse?

Click to reveal answer
ANSWER

STANDARD adds clusters immediately when a query queue forms, prioritising performance and minimising wait times. ECONOMY waits longer before adding clusters to minimise credit consumption, prioritising cost efficiency at the cost of potentially higher query latency during spikes.

Click to see question
Virtual Warehouses
QUESTION

What is the default AUTO_SUSPEND value for a newly created Snowflake warehouse?

Click to reveal answer
ANSWER

600 seconds (10 minutes). After 10 minutes of inactivity, the warehouse automatically suspends and stops consuming credits. This value can be changed with ALTER WAREHOUSE ... SET AUTO_SUSPEND = <seconds>. Setting it to NULL or 0 disables auto-suspend.

Click to see question
Virtual Warehouses
QUESTION

What is the difference between SUSPEND and SUSPEND_IMMEDIATE actions in a resource monitor?

Click to reveal answer
ANSWER

SUSPEND gracefully suspends the warehouse after all currently running queries have completed β€” no queries are killed. SUSPEND_IMMEDIATE kills all currently running queries immediately and suspends the warehouse right away. Use SUSPEND_IMMEDIATE for hard cost enforcement; use SUSPEND to avoid disrupting in-flight work.

Click to see question
Virtual Warehouses
QUESTION

A single-cluster warehouse is experiencing query queuing at peak times. What is the recommended solution?

Click to reveal answer
ANSWER

Enable multi-cluster mode by setting MAX_CLUSTER_COUNT > MIN_CLUSTER_COUNT (requires Enterprise edition). Multi-cluster warehouses add entire compute clusters when queuing is detected, allowing more queries to run concurrently. Simply resizing the warehouse makes individual queries faster but does NOT increase the number of concurrent queries that can run simultaneously.

Click to see question

Additional Resources


Next Steps

Reinforce what you just read

Study the All flashcards with spaced repetition to lock it in.

Study flashcards β†’