WAREHOUSE SIZING: A CONTINUOUS OPTIMIZATION PRACTICE

If you've spent any time around Snowflake, you might have come across the following situations: a BI dashboard that fifty people hit every morning at 9am, an ELT job that runs every fifteen minutes, an ad-hoc analytics team that spikes unpredictably, the result: the warehouse is unable to handle such loads. In these cases, just picking a warehouse size that will solve everything stops being a one-time decision. It becomes an ongoing balancing act between performance and cost, one you'll revisit again and again as your workload evolves.

In this article we discuss about some good practices to decide between scaling up (a bigger single warehouse) and scaling out (multi-cluster warehouses)

First, the basics you need before the decision makes sense

Before we get into the tuning exercise, let's align on a few core concepts.

• Virtual warehouse: A virtual warehouse is just a cluster of compute resources. It reads data from Snowflake's shared storage layer, does the work, and gives you the result. Warehouses come in T-shirt sizes (X-Small up through 6X-Large), and each size step roughly doubles both the compute power and the credits consumed per hour. Snowflake bills per-second (with a 60-second minimum), so a warehouse that's suspended costs you nothing.

• 
  

There are two fundamentally different ways to give a warehouse more power, and this is the distinction the rest of this article hinges on:

• Scaling up (vertical scaling): Resize a warehouse. This gives each individual query more compute resources, so complex, heavy queries run faster.

• Scaling out (horizontal scaling): Add more clusters of the same size, running side by side. This lets more queries run at the same time without queuing. This is called a multi-cluster warehouse.

• 
  

Resizing a warehouse generally improves query performance, especially for complex queries, and it can also help reduce queuing that occurs when a warehouse lacks the compute resources to process all concurrently submitted queries. But warehouse resizing is not intended for handling concurrency issues; instead, additional warehouses or a multi-cluster warehouse should be used for that.

Concurrency problems and complexity problems are different problems, and they have different fixes. Let's dig into how to tell them apart.

The dashboard scenario: why "just make it bigger" is the wrong instinct

Picture a common scenario: a dashboard sits on top of Snowflake, used by an entire

department. Most of the day, usage is light. But every morning at 9am, half the company logs in at once to check the same dashboard, and every query fires within the same two-minute window.

The natural first instinct is: "queries are slow, let's bump the warehouse from Medium to Large." Sometimes that helps. Often it doesn't, because the underlying problem was never that each query was too slow to compute, it's that too many queries were arriving at once and queuing up behind each other waiting for compute resources to free up.

In this case, the best approach is horizontal scaling via a multi-cluster warehouse, tuning the scaling policy based on the workload's time sensitivity.

If, instead, a single complex query is slow even when running alone, that's a vertical scaling problem, and the first thing to check is whether the query is spilling to disk before testing it on a larger warehouse.

So before touching warehouse size, ask which symptom you actually have:

Symptom	Likely cause	Right lever
Queries queue up during peak hours, but individually run fast once they start	Concurrency	Scale out (multi-cluster)
A single query is slow even when it's the only thing running	Complexity / data volume	Scale up (bigger warehouse)

Multi-cluster warehouses: how the scaling actually works

A multi-cluster warehouse has a minimum and maximum number of clusters. It can run in one of two modes:

• Maximized mode: minimum = maximum, so all clusters run all the time. Predictable, but you're paying for peak capacity even during quiet periods.

• Auto-scale mode: minimum < maximum, so Snowflake starts and stops clusters automatically as load changes. This is what you want for a bursty dashboard: quiet periods run on one cluster, and the 9am spike triggers additional clusters that shut back down once the rush is over.

Within auto-scale mode, you also choose a scaling policy, which controls how eager Snowflake is to spin up (and shut down) extra clusters:

• Standard policy (the default) is performance-first. It starts additional clusters after approximately 20 seconds of sustained queuing or high cluster utilization, and shuts clusters down after 2-3 consecutive minutes of low utilization.

• Economy policy is cost-first. It's more conservative, requiring approximately 6 minutes of sustained load before starting additional clusters, meaning it tolerates some queuing rather than spinning up a cluster for what might just be a brief fluctuation.

Snowflake's Well-Architected Framework guidance indicates that Standard policy is ideal for time-sensitive, user-facing workloads such as BI dashboards and analytical applications, minimizing queuing by launching new clusters quickly, while Economy policy suits non-urgent background processes like ETL/ELT pipelines, where some queuing is an acceptable trade-off for lower credit consumption.

A sensible starting configuration, per Snowflake's own sizing guidance, is to start small, for example, maximum = 2 or 3, minimum = 1, and adjust from there. These settings can be increased or decreased at any time, even while the warehouse is running and executing statements. In SQL, it looks like this:

sql
CREATE WAREHOUSE dashboard_wh
  WAREHOUSE_SIZE = 'MEDIUM'
  MAX_CLUSTER_COUNT = 3
  MIN_CLUSTER_COUNT = 1
  SCALING_POLICY = 'STANDARD'
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE;

Notice the size is still only Medium. That's deliberate: we're not making each query more powerful; we're making room for more of them to run at once.

When a bigger single warehouse actually is the right call

None of this means scaling up is wrong, it's just solving a different problem. If your dashboard queries themselves are heavy (large aggregations, complex joins across big tables) and are slow even in isolation, resizing up is the correct move. The diagnostic sign is spilling: when a query needs more memory than the warehouse has, Snowflake spills intermediate results to local disk, or worse, to remote storage. One practical rule of thumb worth remembering: local spillage (to SSD) is a performance hit, but remote spillage (to cloud storage) is a much bigger one, and it's a strong signal that the warehouse is genuinely too small for the query.

A good habit is to check both dimensions before you touch anything: is the workload facing a queuing problem (concurrency) or a spilling/slow-in-isolation problem (capacity)? Sometimes it's both, in which case you may end up sizing up a bit and adding clusters (a Medium with 3 clusters instead of a Small with 3 clusters, for instance).

One more thing to consider, for data loading specifically: increasing the size of a warehouse does not always improve performance, since load performance is influenced more by the number and size of files being loaded than by warehouse size. Unless you're bulk loading hundreds or thousands of files concurrently, a smaller warehouse is generally sufficient.

Catching over-provisioning after the fact

Making a good decision on day one is only half the job. Workloads drift: dashboards get more users, then fewer; ETL jobs get optimized; teams forget to revisit a warehouse they sized generously "just to be safe" six months ago. Over-provisioning is rarely a single bad decision; it's usually a good decision nobody revisited.

Here's a practical, low-effort routine for catching it:

1. Check average warehouse load. Snowflake exposes warehouse load history (via WAREHOUSE_LOAD_HISTORY or the Snowsight warehouse activity view). If average utilization is consistently low, that's a strong sign you're paying for capacity you rarely need.

2. Look at how often you're actually hitting max clusters. If a warehouse configured for MAX_CLUSTER_COUNT = 5 almost never goes past 2, your maximum is set defensively rather than based on evidence. Bring it down, and watch query queuing before and after it's a fast, reversible experiment since, as noted above, these settings can be changed live without downtime.

3. Query the account's query history for spillage and queuing together. If you see very little disk spillage and very little queuing, but the warehouse has been sitting at a large size and multiple clusters for months, that's your over-provisioning red flag, plain and simple.

4. Set resource monitors. A resource monitor that alerts your team at 75% and 100% of a monthly credit quota isn't just a safety net it's a nudge to actually go look at why consumption crept up, rather than just reacting once the bill lands.

5. Revisit scaling policy choice periodically. A workload that started bursty and unpredictable (Standard policy) may have become steadier over time (better suited to Economy), or vice versa. This is easy to forget because, once set, scaling policy doesn't demand attention it just quietly keeps doing what it was told.

   
   

None of this needs to be a heavyweight process. A recurring 30-minute monthly check average load, max cluster hits, spillage, and current credit trend catches the vast majority of drift before it becomes a real cost problem.

Bringing it together

The mental model worth carrying forward is this: scale up when queries are individually slow, scale out when too many queries arrive at once, and revisit both regularly because workloads don't stay still. A single bigger warehouse and a multi-cluster warehouse are not competing philosophies — they're two different dials for two different problems. And the skill isn't memorizing which one to use; it's learning to read your workload's actual symptoms before reaching for either one.

If you're just starting out with Snowflake, don't worry about getting this perfect on the first try — nobody does. Start small, watch the load history, and let the warehouse's actual behavior tell you what it needs. And if you've been working with Snowflake for years, it's worth asking yourself honestly: when was the last time you looked at why a warehouse is sized the way it is, rather than just accepting that it's always been that way? That one question, asked regularly, is usually where the real savings can be made.