Sizing, scaling, and auto-suspending a virtual warehouse
Virtual warehouses are the compute clusters that execute Snowflake queries, DML, and data loading, and can be sized, scaled, and scheduled independently of storage. Configuring them correctly balances query performance against credit consumption, since compute is billed per-second (minimum 60 seconds) whenever a warehouse is running.
1 · Learn the must-know
- Warehouse size (X-Small up to 6X-Large) determines the number of servers/compute resources in a cluster, and doubling size roughly doubles credits consumed per hour while potentially improving performance for large or complex queries.
- Multi-cluster warehouses (Enterprise edition and above) add or remove clusters automatically to handle concurrency, using Auto-scale mode with configurable minimum and maximum cluster counts and a scaling policy of Standard or Economy.
- Auto-suspend and auto-resume let a warehouse suspend after a period of inactivity to save credits and automatically resume when a new query is submitted, and both should be tuned to balance cost versus warm-cache performance.
- Each warehouse maintains its own dedicated cache of recently accessed data; suspending a warehouse can eventually clear this cache, so overly aggressive auto-suspend can hurt performance on repeated queries.
- Resizing a warehouse can be done at any time and applies immediately to queries submitted after the change, but running queries continue on the original size until they complete.
- Warehouses can be created and managed via SQL (CREATE WAREHOUSE, ALTER WAREHOUSE), Snowsight, or SnowSQL, and access to use or manage a warehouse is controlled through role-based privileges such as USAGE, MONITOR, MODIFY, and OPERATE.
2 · Check your understanding
A Snowflake Practitioner sets AUTO_SUSPEND = 60 on warehouse REPORTING_WH to reduce idle credit consumption. After each suspension, the first query submitted once the warehouse resumes runs noticeably slower than later queries, even though the query text and underlying table data have not changed. The team wants to understand the cause before deciding whether to change the suspend interval. What explains this behavior?
What you have tried across SnowPro Core's objectives, not a readiness score.
Snowflake AI Data Cloud Features and Architecture31% of the exam0 of 6 tried
Account Management and Data Governance20% of the exam0 of 3 tried
Data Loading, Unloading, and Connectivity18% of the exam0 of 3 tried
Performance Optimization, Querying, and Transformation21% of the exam0 of 4 tried
3 · Keep going
Ready for more? Take a weighted mock or try free practice questions.