What you will be able to do
- Configure a multi-cluster warehouse in Maximized or Auto-scale mode
- Choose between the Standard and Economy scaling policies and know which one is the default
- Calculate credits for a multi-cluster warehouse
- Decide whether to scale up or scale out, and configure warehouses for ad-hoc, data loading, BI, multi-team, high-concurrency and complex-query workloads
1.Scaling out with multi-cluster warehouses
By default a warehouse has one cluster. When that cluster has no spare resources, new queries wait in a queue. A multi-cluster warehouse adds clusters of the same size to give a larger pool of compute, so more users and queries can run at once. This is scaling out, and removing clusters is scaling in. Multi-cluster warehouses are an Enterprise Edition feature. You set them up with two properties: a maximum cluster count greater than 1 and a minimum cluster count no higher than the maximum.
How those two numbers relate sets the mode. If minimum equals maximum, the warehouse runs in Maximized mode: every cluster starts with the warehouse. That suits large concurrency that stays steady. If minimum is below maximum, it runs in Auto-scale mode: Snowflake starts clusters as queries begin to queue and shuts them down as load drops. Snowflake suggests starting with Auto-scale and small numbers, such as maximum 2 or 3 and minimum 1, and then adjusting as you observe the load.
| Warehouse size | Allowed maximum cluster count |
|---|---|
| XSMALL to MEDIUM | 300 |
| LARGE | 160 |
| XLARGE | 80 |
| 2XLARGE | 40 |
| 3XLARGE | 20 |
| 4XLARGE to 6XLARGE | 10 |
Size and suspend settings work at the warehouse level. A resize applies to every cluster, including the ones already running. Auto-suspend happens only when the warehouse is down to its minimum cluster count and has been idle for the set period. Auto-resume happens only when the whole warehouse is suspended.
Checkpoint 1 of 7· Match them up
Match each configuration to its behaviour
Tap a term, then the definition that fits it.
Equal minimum and maximum (greater than 1) gives Maximized mode. A minimum below the maximum gives Auto-scale mode. A maximum of 1 is an ordinary single-cluster warehouse.
“For maximized mode, the maximum number of clusters must be equal to the minimum number of clusters.”Source: docs.snowflake.com
2.Scaling policies: Standard and Economy
In Auto-scale mode, Snowflake has to decide when to add a cluster and when to remove one. The SCALING_POLICY property controls that decision and accepts STANDARD or ECONOMY. The policy only matters in Auto-scale mode. In Maximized mode every cluster is always running, so there is nothing to start or stop.
Standard is the default policy. It aims to prevent or minimize queuing and will start clusters rather than save credits. It adds a cluster when a query queues, or when Snowflake estimates the running clusters cannot take more work. With a MAX_CLUSTER_COUNT of 10 or less it adds one cluster at a time. Above 10 it can start several at once to handle a sudden surge. Economy is the alternative for when cost matters more than responsiveness. The material available here does not describe Economy's exact start and shut-down triggers, so for this lesson remember only its purpose: it minimizes cost instead of minimizing queuing.
Checkpoint 2 of 7· Exam question
A data engineering team routinely loads a handful of large files per batch using COPY INTO and wants to reduce load times. They are considering resizing their warehouse from Small to X-Large. What should they know before doing so?
Correct answer: A — Increasing warehouse size mainly adds parallel file-processing capacity, so it speeds up loads only when many files are processed concurrently, not when just a few large files are loaded.
- A. COPY INTO parallelizes work across files, so a bigger warehouse helps most when hundreds or thousands of files load concurrently; a handful of large files will not see proportional speedup from a bigger warehouse.
- B. A single large file is not split across additional compute nodes just because the warehouse got bigger, so doubling size does not proportionally speed up parsing of one file.
- C. Warehouse size does affect load throughput once file counts are high, and Snowpark-optimized warehouses target memory-intensive ML workloads rather than general COPY INTO performance.
- D. Warehouse sizing considerations for parallelism apply to batch COPY INTO loading as well, not only to Snowpipe Streaming, so file count and size still matter for a standard warehouse.
Checkpoint 3 of 7· Check yourself
A warehouse has MIN_CLUSTER_COUNT = 4 and MAX_CLUSTER_COUNT = 4, and an admin sets SCALING_POLICY = ECONOMY to save credits. What is the effect?
Equal minimum and maximum means Maximized mode, where all clusters always run. A scaling policy only affects warehouses in Auto-scale mode.
“The scaling policy for a multi-cluster warehouse only applies if it is running in Auto-scale mode.”Source: docs.snowflake.com
3.Credit consumption with multiple clusters
A multi-cluster warehouse is billed for its size multiplied by the clusters running during each period. The worst case is size times maximum clusters. For example, a Medium warehouse (4 credits per hour) with 3 clusters costs at most 12 credits per hour. In Auto-scale mode you usually pay less than that, because the extra clusters only run while they are needed.
| Mode | Cluster 1 | Cluster 2 | Cluster 3 | Total credits |
|---|---|---|---|---|
| Maximized (all clusters both hours) | 8 | 8 | 8 | 24 |
| Auto-scale (cluster 2 runs hour 2 only; cluster 3 runs 30 min) | 8 | 4 | 2 | 14 |
Resizing a multi-cluster warehouse also multiplies across clusters. In Snowflake's fourth example, the warehouse goes from Medium to Large at 1.5 hours. Each running cluster then costs 8 credits per hour instead of 4, and the 3-hour total reaches 34 credits.
Checkpoint 4 of 7· Check yourself
A 3X-Large multi-cluster warehouse (64 credits/hour per cluster) runs 1 cluster for one full hour, then 2 clusters for the next full hour. How many credits are billed?
Hour 1 costs 64 × 1 and hour 2 costs 64 × 2, for a total of 64 + 128 = 192.
“the total number of credits billed would be 192 (i.e. 64 + 128)”Source: docs.snowflake.com
4.Scale up or scale out?
Size and cluster count solve different problems. A larger size gives each query more compute, so it is the tool for slow and complex queries and for heavy loads. More clusters let more queries run at once, so they are the tool for queuing caused by concurrency. Resizing can relieve queuing a little, but that is not its main purpose. Without multi-cluster, the only fix for concurrency is to start extra warehouses, route users to them by hand, and shrink or suspend them later. A multi-cluster warehouse in Auto-scale mode does this automatically.
| Symptom | Lever | Direction |
|---|---|---|
| Individual queries run slowly | Warehouse size | Scale up (resize larger) |
| Queries queue only during user bursts | Cluster count (Auto-scale) | Scale out, then back in automatically |
| Steady, high, non-fluctuating concurrency | Cluster count (Maximized) | Fixed number of clusters |
| Workload shrank and finishes well inside its window | Warehouse size | Scale down (resize smaller) |
Checkpoint 5 of 7· Exam question
A BI team's Snowsight dashboards are used by 150 people during the 9am refresh window, causing queries to queue on a single-cluster Large warehouse. Which change directly addresses the queuing without changing query complexity?
Correct answer: A — Convert the warehouse to multi-cluster with MAX_CLUSTER_COUNT above one and Standard scaling, so Snowflake starts additional clusters as soon as queries begin queuing at 9am.
- A. Concurrency-driven queuing from many simultaneous dashboard users is exactly what multi-cluster warehouses solve, and the Standard policy starts a new cluster within roughly 20 seconds of sustained queuing.
- B. A longer auto-suspend interval keeps a single cluster resumed but does not add any additional compute, so the same fixed capacity still queues once 150 people hit it at once.
- C. Resizing gives each query more compute per node but still only one cluster serving all sessions, which provides limited relief for a concurrency problem caused by many simultaneous users rather than one slow query.
- D. Snowpark-optimized warehouses add memory for ML and UDF workloads, not additional query concurrency slots, so it does not resolve queuing caused by many simultaneous dashboard sessions.
Checkpoint 6 of 7· Check yourself
An application sends bursts of many short concurrent queries to a single-cluster Small warehouse. Queries queue only during the bursts, and the warehouse is otherwise quiet. What is the best fix?
The problem is concurrency, not query speed. Auto-scale adds clusters during bursts and removes them afterwards, so you do not pay permanently for idle capacity.
“Multi-cluster warehouses are best utilized for scaling resources to improve concurrency for users/queries.”Source: docs.snowflake.com
5.Configuring warehouses per workload
The documentation describes workloads by their shape, such as testing versus production, file counts and concurrency patterns. It does not use the exam's labels "ad-hoc" or "BI". The guidance below applies the documented rules to those labels.
Ad-hoc queries are usually small, exploratory and varied. Small-scale testing environments can often use X-Small to Medium, because larger is not necessarily faster for simple queries. With no steady stream of work, auto-suspend keeps the idle time cheap. Data loading is limited mainly by the number and size of files, not by warehouse size. Unless you are loading hundreds or thousands of files concurrently, Small to Large is generally enough, and a bigger warehouse may just cost more. BI and reporting is production querying, often by many users at once. Larger sizes may be more cost-effective in large-scale production, and multi-cluster handles the user concurrency. For dashboards it is also worth weighing the cache: a warehouse kept running keeps its cached data warm.
Three workload rules cover the rest. For different teams, run similar queries on the same warehouse. Mixing very different workloads makes the load harder to analyse and the warehouse harder to size, so separate warehouses per team or workload make sense. For high concurrency, scale out with multi-cluster: Auto-scale when the load fluctuates, Maximized when it is large and steady. For complex queries, scale up, because large, complex queries scale roughly linearly with size. Total table size affects processing more than row count, as do joins and filter predicates.
| Workload | Documented guidance |
|---|---|
| Small-scale testing | Smaller sizes (X-Small, Small, Medium) may be sufficient |
| Large-scale production | Larger sizes (Large, X-Large, 2X-Large, etc.) may be more cost effective |
| Data loading | Size should match the number of files and the data in each file |
| Mixed teams/queries | Run relatively homogeneous queries on the same warehouse |
Checkpoint 7 of 7· Check yourself
The finance team's heavy month-end aggregations share one warehouse with the marketing team's light lookups. Sizing the shared warehouse has become guesswork. What does Snowflake's guidance suggest?
Mixing queries of very different complexity on one warehouse makes it hard to analyse the load and pick a size. Separate warehouses for different workloads let each one be sized on its own.
“try to execute relatively homogeneous queries (complexity, data sets, etc.) on the same warehouse”Source: docs.snowflake.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Adding clusters to a warehouse makes slow queries and data loads finish faster.Why is that wrong?
Extra clusters improve concurrency. Slow queries and loads benefit from resizing instead.
Covered in Scale up or scale out?
2.A bigger warehouse always speeds up data loading.Why is that wrong?
Loading performance depends mainly on the number and size of files, not on warehouse size.
Covered in Configuring warehouses per workload
3.Each cluster of a multi-cluster warehouse auto-suspends independently when it goes idle.Why is that wrong?
Auto-suspend and auto-resume act on the whole warehouse. Individual clusters are started and stopped by auto-scaling.
Covered in Scaling out with multi-cluster warehouses
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Multi-cluster warehouses enable you to scale compute resources to manage your user and query concurrency needs”
↩︎ Scaling out with multi-cluster warehouses“start with Auto-scale mode and start small (for example, maximum = 2 or 3, minimum = 1)”
↩︎ Scaling out with multi-cluster warehouses“Standard (default) | Prevents/minimizes queuing by favoring starting additional clusters over conserving credits.”
↩︎ Scaling policies: Standard and Economy“prioritize responsiveness and throughput for the queries in that warehouse, or to minimize costs for that warehouse”
↩︎ Scaling policies: Standard and Economy“For warehouses with a MAX_CLUSTER_COUNT of 10 or less, Snowflake starts one additional cluster.”
↩︎ Scaling policies: Standard and Economy“the maximum number of credits consumed per hour for a Medium-size multi-cluster warehouse with 3 clusters is 12 credits”
↩︎ Credit consumption with multiple clusters“You must either increase the size of the warehouse or start additional warehouses and explicitly redirect the additional users/queries to these warehouses.”
↩︎ Scale up or scale out?“particularly if you have large numbers of concurrent user sessions and/or queries and the numbers do not fluctuate significantly”
↩︎ Configuring warehouses per workload“For these types of operations, resizing the warehouse provides more benefits.”
↩︎ Exam trap 1“For maximized mode, the maximum number of clusters must be equal to the minimum number of clusters.”
↩︎ Checkpoint“The scaling policy for a multi-cluster warehouse only applies if it is running in Auto-scale mode.”
↩︎ Checkpoint“They are not as beneficial for improving the performance of slow-running queries or data loading.”
↩︎ Prediction“Multi-cluster warehouses are best utilized for scaling resources to improve concurrency for users/queries.”
↩︎ Checkpoint - 2.
“Multi-cluster warehouses are an Enterprise Edition feature.”
↩︎ Scaling out with multi-cluster warehouses“the number of credits billed is calculated based on the warehouse size and the number of clusters that run within the time period”
↩︎ Credit consumption with multiple clusters“warehouse resizing is primarily intended for improving query performance”
↩︎ Scale up or scale out?“Data loading performance is influenced more by the number of files being loaded”
↩︎ Configuring warehouses per workload“a smaller warehouse (Small, Medium, Large) is generally sufficient”
↩︎ Configuring warehouses per workload“Increasing the size of a warehouse does not always improve data loading performance.”
↩︎ Exam trap 2“Auto-suspend and auto-resume apply only to the entire warehouse and not to the individual clusters in the warehouse.”
↩︎ Exam trap 3“the total number of credits billed would be 192 (i.e. 64 + 128)”
↩︎ Checkpoint - 3.
“SCALING_POLICY = { STANDARD | ECONOMY }”
↩︎ Scaling policies: Standard and Economy - 4.
“For queries in small-scale testing environments, smaller warehouses sizes (X-Small, Small, Medium) may be sufficient.”
↩︎ Configuring warehouses per workload“For queries in large-scale production environments, larger warehouse sizes (Large, X-Large, 2X-Large, etc.) may be more cost effective.”
↩︎ Configuring warehouses per workload“The overall size of the tables being queried has more impact than the number of rows.”
↩︎ Configuring warehouses per workload“try to execute relatively homogeneous queries (complexity, data sets, etc.) on the same warehouse”
↩︎ Checkpoint