2.2 Core Workflows and Decision Points

Virtual Warehouses: The Compute Engine

A virtual warehouse is a named cluster of compute resources (CPU, memory, and temporary local SSD) that executes SQL — queries, DML such as INSERT/UPDATE/DELETE/MERGE, and data loading with COPY. Warehouses are the only objects that consume Snowflake credits for compute, and they can be started, stopped, and resized at any time, even while running.

Warehouse sizes follow a t-shirt scale, and each step up roughly doubles the compute power per hour — and therefore the credit consumption:

Billing is per-second with a 60-second minimum every time a warehouse resumes. If you start a warehouse and suspend it 10 seconds later, you are still billed for the full 60 seconds; after that first minute, billing is by the second.

Scaling Up vs. Scaling Out

A core exam decision is choosing scale up versus scale out:

• Scale up (resize) — Change a warehouse to a larger size (e.g., Medium to Large). This adds compute to make a single, complex, slow query faster, or to process larger data volumes. Use it for performance of an individual heavy workload.
• Scale out (multi-cluster) — Add more clusters of the same size to a multi-cluster warehouse. This handles concurrency: many users or queries arriving at once that would otherwise queue. Use it when queries are queuing, not when one query is slow.

Multi-cluster warehouses require Enterprise Edition or higher. You set a MIN and MAX number of clusters. In Auto-scale mode, Snowflake starts additional clusters (up to MAX) as concurrency rises and shuts them down as it falls, governed by a scaling policy of Standard (favors starting clusters to minimize queuing) or Economy (favors fully loading running clusters to save credits). In Maximized mode, you set MIN equal to MAX so all clusters run continuously.

Auto-Suspend, Auto-Resume, and Caching

Warehouses can be configured to manage their own cost:

• Auto-suspend — After a period of inactivity (the AUTO_SUSPEND parameter, default 600 seconds / 10 minutes in SQL; the web UI default is 5 minutes), the warehouse suspends and stops consuming credits.
• Auto-resume — When a new query is submitted to a suspended warehouse, it automatically resumes. Combined with auto-suspend, you pay only for active compute.

A running warehouse maintains a local disk (SSD) cache of table data it has read. Subsequent queries that hit the same data can be served from this warm cache instead of re-reading from remote storage, which is faster. Critically, when a warehouse suspends, its local cache is dropped — so a freshly resumed warehouse starts "cold" and must repopulate the cache. This is the classic trade-off: aggressive auto-suspend saves credits but loses the cache; a longer suspend keeps the cache warm at the cost of idle credits.

Creating and Managing Warehouses

The command to create one is CREATE WAREHOUSE, specifying WAREHOUSE_SIZE, AUTO_SUSPEND, AUTO_RESUME, MIN_CLUSTER_COUNT, MAX_CLUSTER_COUNT, and SCALING_POLICY. Resizing uses ALTER WAREHOUSE ... SET WAREHOUSE_SIZE = .... A resize affects only queries that start after the change — running queries finish on the old size. Warehouses are independent: suspending or resizing one never affects another, and several can read the same tables concurrently.

Standard vs. Snowpark-Optimized Warehouses

Beyond the t-shirt sizes, Snowflake offers Snowpark-optimized warehouses with 16× more memory per node (and more local cache), built for memory-intensive workloads such as ML training and large UDFs running through Snowpark. Standard warehouses cover ordinary SQL analytics. Knowing the two types exist — and that you pick Snowpark-optimized only for memory-bound work — is a likely exam distinction.

Credit Consumption in Practice

Credits are the unit of compute billing, and only a few things consume them:

• Virtual warehouses while they are running (the dominant cost).
• Serverless features that run on Snowflake-managed compute: Automatic Clustering, Materialized View maintenance, Snowpipe, Search Optimization, and replication.
• Cloud services, but only the portion that exceeds 10% of daily warehouse credits.

Because billing is per-second after the 60-second minimum, the levers for controlling cost are right-sizing the warehouse, aggressive auto-suspend, and consolidating bursty workloads onto multi-cluster warehouses rather than many idle dedicated ones.

A Worked Decision

A nightly batch job transforms billions of rows and currently runs on a Small warehouse for four hours. Resizing to Large (8 credits/hour vs. 2) often finishes faster than 4×, because more nodes process partitions in parallel — so the total credits can be similar or lower while the job completes far sooner. This "bigger but shorter" reasoning is exactly the trade-off SnowPro Core wants you to apply, rather than assuming a larger warehouse always costs more in total.