Virtual Warehouses: Types, Sizing, and Scaling

1. Virtual Warehouses: Types, Sizing, and Scaling

In this video we're going deep on virtual warehouses — what types exist, how they're configured, how sizing affects your costs and how to match the right scaling strategy to the right workload. Get this wrong and you're either overpaying or watching queries crawl. Get it right, and Snowflake works the way it's supposed to.

2. One Warehouse, Many Workloads

Picture a single warehouse handling everything — a BI team refreshing dashboards, a data engineer running an overnight batch load, an analyst firing off ad-hoc queries, and an ML team processing a large dataset. They're all competing for the same compute.

3. One Warehouse, Too Many Workloads

This means that queries start to queue, dashboards will slow down and batch jobs start running late. The instinct is to reach for a bigger warehouse - but that's not the real fix. The answer is separate warehouses - one for each team. That way there is no contention, no scheduling conflicts and no one workload blocking another. Because Snowflake separates compute from storage, spinning up additional warehouses doesn't duplicate your data. Each warehouse reads from the same storage layer independently.

4. Standard vs Snowpark Optimized

Within each warehouse, you have two types to choose from. Standard covers the vast majority of use cases: SQL queries, data loading, and BI reporting. There is a newer Gen2 option with improved performance; whether it uses fewer credits than Gen1 depends on the workload, so test both if cost matters. Snowpark-optimized warehouses are built for memory-intensive and Snowpark workloads. You can configure memory and CPU more flexibly for those jobs. They are available from Medium size upward and cost more than a standard warehouse, so use them when the workload actually needs the extra headroom.

5. Warehouse Sizing

There are a lot of different warehouse size options, and you can create them from SQL. XS handles light queries and development, Large often fits production analytics, and XL and above is for very large or complex work. The chart on the right is the same sweet spot idea you will see on the next slide: the same query on Small, Medium, and Large can cost about the same total credits because a larger warehouse finishes faster. Snowflake also bills per second with a 60-second minimum when a warehouse starts, which matters for cost. That is what makes “right-sizing” a habit, not “always go bigger.”

6. The Sweet Spot

Here's what the credits-per-hour table doesn't tell you. Run the same query on a Small, a Medium, and a Large warehouse — all three consume roughly the same total credits, because the larger warehouse finishes the job in less time. Query time halves with each size up, but the credit spend barely moves. It only starts climbing at XL and above, where performance gains begin to flatten out. That's the sweet spot — the smallest warehouse size where adding more compute stops delivering proportional returns. Bigger isn't always cheaper when you factor in how long it actually runs.

7. Cost Control: Auto-Suspend and Auto-Resume

Two settings that directly control your costs, and they should be set on every warehouse from the start. AUTO_SUSPEND defines how many seconds of inactivity before the warehouse suspends automatically. Three hundred seconds aka five minutes is a common default. AUTO_RESUME = TRUE means it wakes up the moment a query arrives, with no manual intervention needed. A warehouse left running with no active workload burns credits continuously. These two settings are the simplest cost control Snowflake gives you, don't skip them.

8. Multi-cluster Warehouse

Multi-cluster is Snowflake's answer to high-concurrency workloads. When demand spikes, additional clusters spin up automatically. When demand drops, they suspend. You set the minimum and maximum cluster count, Snowflake handles the rest. Multi-cluster is an Enterprise edition feature,and thus not available on Standard edition.

9. Scaling Up vs Scaling Out

Scaling up and scaling out solve different problems, and confusing them is a common mistake. If a single heavy query is slow, you usually scale up (a larger warehouse gives that query more resources). If many sessions are queued at the same time, a bigger single cluster may not be the fix, you should instead scale out with more clusters so that work runs in parallel. Multi-cluster, which you just saw, is how Snowflake adds clusters for that concurrency case.

10. Economy vs Standard Scaling Policy

Once multi-cluster is enabled, you choose a scaling policy. Standard spins up a new cluster the moment anything gets queued — it prioritizes throughput over credit savings. Economy is more conservative: it only adds a cluster if the current load will keep it busy for more than six minutes. Short spikes resolve on their own, without the extra cost. You want to utilize Standard for unpredictable workloads, whereas Economy is for steady and predictable concurrency. Make sure you have a good concept of your traffic patterns before you choose the policy.

11. Let's practice!

Let's put your knowledge to the test.

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.