What Is a Virtual Warehouse?
A virtual warehouse in Snowflake is a named cluster of compute resources (CPU, memory, and temporary storage) that executes SQL queries, loads data, and performs DML operations. It is entirely separate from the database storage layer, which lives in Snowflake's centralized, cloud-hosted storage. You can spin up a warehouse, use it, suspend it, and even drop it, without ever touching the underlying tables it queries.
Cricket analogy: Think of a virtual warehouse like a stadium's floodlight rig rented for a day-night match at Eden Gardens: the pitch and outfield (storage) stay exactly as they are, but you bring in exactly the lighting capacity (compute) you need for that fixture and send it back afterward.
Sizing and Credit Consumption
Warehouses come in T-shirt sizes: X-Small, Small, Medium, Large, X-Large, up through 6X-Large. Each step up roughly doubles the number of compute servers in the cluster and doubles the credits consumed per hour, going from 1 credit/hour at X-Small to 512 credits/hour at 6X-Large. Larger warehouses do not automatically make every query faster; they help most with queries that can be parallelized across many partitions, such as large scans, joins, or aggregations, while a small, low-concurrency lookup may run identically on an X-Small and a Large warehouse.
Cricket analogy: Doubling warehouse size is like adding extra bowlers to an attack: bringing on a fourth quick against a settled batting lineup on a flat MCG pitch speeds up the innings, but adding bowlers doesn't help when you only need one over to finish a tail-ender.
Compute-Storage Separation and Isolation
Because compute and storage are decoupled, multiple virtual warehouses can query the exact same tables simultaneously without competing for resources or blocking one another. A finance team's reporting warehouse and a data science team's model-training warehouse can both hit the SALES table at the same time, each with its own dedicated compute, and neither will slow the other down or see lock contention from the other's reads.
Cricket analogy: It's like two separate commentary boxes, one for the English broadcast and one for the Hindi broadcast, both watching the same live match feed from Lord's independently, with neither commentary team's workload affecting the other's.
Common Usage Patterns
A common best practice is to assign separate, appropriately-sized warehouses per workload: a small warehouse for scheduled ETL jobs, a medium warehouse for BI dashboard queries, and a large warehouse for ad hoc data science exploration. This isolates workloads so a heavy nightly load job never competes with, or slows down, an analyst's dashboard refresh during business hours, and it makes cost attribution straightforward since credit usage is tracked per warehouse.
Cricket analogy: It's like a franchise having separate net-practice pitches for pace bowlers, spinners, and batters at IPL training camp, each group working independently so a batting drill never gets interrupted by a bowling session on the same strip.
-- Create a warehouse sized for ETL, auto-suspending after 60 seconds idle
CREATE WAREHOUSE etl_wh
WAREHOUSE_SIZE = 'MEDIUM'
AUTO_SUSPEND = 60
AUTO_RESUME = TRUE
INITIALLY_SUSPENDED = TRUE;
-- Resize a warehouse up for a heavy batch job, then back down afterward
ALTER WAREHOUSE etl_wh SET WAREHOUSE_SIZE = 'LARGE';
-- ... run the heavy job ...
ALTER WAREHOUSE etl_wh SET WAREHOUSE_SIZE = 'MEDIUM';
-- Point a session at a specific warehouse for isolation
USE WAREHOUSE bi_dashboard_wh;
SELECT region, SUM(revenue) FROM sales GROUP BY region;Snowflake bills warehouse credits per-second with a 60-second minimum each time a warehouse resumes from suspension. An X-Small warehouse that runs for just 10 seconds is still billed for a full 60 seconds, so very short, frequent queries can benefit from a warehouse that stays running rather than one that suspends aggressively.
Resizing a running warehouse with ALTER WAREHOUSE does not speed up queries that are already executing; it only affects queries that start after the resize completes, and any queries already queued. If you need faster completion of an in-flight query, resizing won't help retroactively.
- A virtual warehouse is an independently scalable compute cluster, fully decoupled from Snowflake's storage layer.
- Warehouses use T-shirt sizing from X-Small to 6X-Large, with credit consumption roughly doubling at each size.
- Larger warehouses speed up highly parallelizable queries but don't help small, low-concurrency lookups.
- Multiple warehouses can query the same tables concurrently without resource contention or blocking.
- Best practice is to dedicate separate warehouses per workload (ETL, BI, ad hoc) for isolation and cost tracking.
- Billing uses per-second granularity with a 60-second minimum per resume event.
- Resizing a running warehouse only affects future queries, not ones already in flight.
Practice what you learned
1. What happens to storage when a virtual warehouse is dropped?
2. Going from a Small to a Medium warehouse roughly does what to credit consumption per hour?
3. What is the minimum billing increment when a warehouse resumes from suspension?
4. If two teams query the same table using two different warehouses at the same time, what happens?
5. Resizing a running warehouse to a larger size will do what to a query that is already executing?
Was this page helpful?
You May Also Like
Multi-Cluster Warehouses
Understand how multi-cluster warehouses handle high concurrency by automatically adding and removing compute clusters.
Auto-Scaling and Auto-Suspend
Learn how AUTO_SUSPEND and AUTO_RESUME, combined with multi-cluster auto-scaling, keep Snowflake compute cost-efficient without manual intervention.
Query Performance and Caching
Explore Snowflake's layered caching model, including result cache, local disk cache, and metadata cache, and how each speeds up repeated queries.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics
ProgrammingPowerShell Study Notes
Programming · 30 topics