Snowflake Multi-Cluster Warehouses: Scaling Policies, Queuing and Cost (2026)

A Snowflake multi-cluster warehouse runs extra clusters of the same size when many queries arrive at once, so they do not have to queue. Each running cluster bills at the full rate for its size, so a multi-cluster warehouse can cost two, three or ten times as much as a single cluster while the extra clusters run. This guide explains how multi-cluster warehouses scale, what the Standard and Economy policies do, how to tell whether queuing calls for more clusters or a bigger warehouse, and how to keep the cost in check. Every fact and figure in this guide was checked against Snowflake’s documentation.

This article is part of our guide to Snowflake warehouse optimization.

What is a multi-cluster warehouse?

A multi-cluster warehouse is a warehouse that can run more than one cluster of compute at the same time. All clusters are the same size. Snowflake starts extra clusters when queries start to queue and stops them when the load drops. Multi-cluster warehouses need Enterprise Edition or higher.

Two settings decide how many clusters can run:

• MIN_CLUSTER_COUNT: the clusters that run whenever the warehouse runs.
• MAX_CLUSTER_COUNT: the most clusters the warehouse can run at once.

Both default to 1, which is a normal single-cluster warehouse. When the two are equal and above 1, the warehouse runs in Maximized mode: all clusters run whenever it runs. When they differ, it runs in Auto-scale mode: Snowflake adds and removes clusters between the two as load changes. Snowflake suggests starting small, in Auto-scale mode with a minimum of 1 and a maximum of 2 or 3.

The highest allowed maximum depends on size: 300 clusters for X-Small to Medium, 160 for Large, 80 for X-Large, 40 for 2X-Large, 20 for 3X-Large and 10 for 4X-Large and above. Snowsight lets you choose up to 10; higher values need SQL.

By default, Snowflake aims for about 8 concurrent statements per cluster (MAX_CONCURRENCY_LEVEL); the real number depends on how heavy the queries are. When that level is reached, a single-cluster or Maximized warehouse queues the extra queries, while an Auto-scale warehouse starts another cluster.

How much does a multi-cluster warehouse cost?

Each running cluster bills at the full rate for its size, for every second it runs. A Large warehouse uses 8 credits per hour on Gen1, so:

$3.00 is the Enterprise Edition on-demand price in AWS US East; Enterprise is the lowest edition with multi-cluster warehouses.

Snowflake’s own example: a 3X-Large warehouse (64 credits per hour) that runs one cluster for an hour and two clusters for the next hour uses 64 + 128 = 192 credits.

Because the extra clusters only run while there is load, the real cost depends on how long they stay up, and that is mostly decided by the scaling policy.

Standard vs Economy: which scaling policy should you use?

The scaling policy decides how eagerly Snowflake starts extra clusters and how quickly it stops them.

With a maximum of 10 clusters or fewer, clusters start and stop one at a time.

Use Standard where queuing hurts: user-facing dashboards and interactive work. Use Economy where some queuing is acceptable and cost matters more: batch jobs and background workloads.

My queries are queuing: should I resize or add clusters?

It depends on why they queue.

• Many queries at once, each reasonably fast: add clusters. More clusters let more queries run at the same time. Snowflake’s guidance is that resizing is not intended for handling concurrency; use a multi-cluster warehouse or more warehouses instead.
• A few big queries that run slowly or spill to disk: resize. A bigger warehouse gives each query more compute and memory; more clusters would not make a single query faster.

To tell them apart, look at how much time queries spend waiting and why:

-- Queuing and run time per warehouse, last 7 days
SELECT warehouse_name,
       COUNT(*)                            AS queries,
       COUNT_IF(queued_overload_time > 0)  AS queued_queries,
       AVG(queued_overload_time) / 1000    AS avg_queued_seconds,
       AVG(execution_time) / 1000          AS avg_execution_seconds
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
  AND warehouse_name IS NOT NULL
GROUP BY 1
ORDER BY avg_queued_seconds DESC;

QUEUED_OVERLOAD_TIME is time spent waiting because the warehouse was busy, which more clusters fix. QUEUED_PROVISIONING_TIME is time spent waiting for the warehouse to start or resize. Both are in milliseconds. For a warehouse-level view, WAREHOUSE_LOAD_HISTORY shows average running and queued load (AVG_RUNNING, AVG_QUEUED_LOAD) in 5-minute intervals.

Snowflake does not charge per queued query. A queued query adds no charge of its own, but the warehouse keeps billing while it runs, whether or not it is doing work. If queries should not wait forever, STATEMENT_QUEUED_TIMEOUT_IN_SECONDS cancels statements that queue too long; it is 0, meaning no timeout, by default.

How do you control multi-cluster costs?

• Set MAX_CLUSTER_COUNT from real demand. Look at how many clusters actually run at peak, and cap the warehouse there rather than at a round number.
• Keep MIN_CLUSTER_COUNT at 1 unless you need guaranteed capacity. Every cluster in the minimum runs whenever the warehouse runs.
• Use Economy for workloads that can wait.
• Split workloads that do not belong together. A dashboard warehouse and a batch warehouse have different needs; one multi-cluster warehouse serving both is usually sized for the worse case.
• Check Query Acceleration. New multi-cluster warehouses get it turned on by default, and it bills whenever it is used.
• Watch the tail of each burst. Clusters that stay up after the load has gone are the main waste in multi-cluster warehouses.

-- A multi-cluster warehouse with a cost-conscious setup
CREATE WAREHOUSE batch_wh
  WAREHOUSE_SIZE = MEDIUM
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 3
  SCALING_POLICY = 'ECONOMY'
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE;

-- Change the policy or the cap on an existing warehouse
ALTER WAREHOUSE batch_wh SET SCALING_POLICY = 'STANDARD' MAX_CLUSTER_COUNT = 4;

How Seemore keeps extra clusters from idling

Snowflake’s scaling policies are built to protect performance, not cost, so extra clusters can keep running after the load that justified them is gone. Seemore’s Auto-Scaler watches multi-cluster warehouses in real time and scales cluster count down the moment extra clusters stop contributing meaningful performance. It pauses scaling while queries are actively running, considers a cluster for scale-in only after it has been up for at least a minute, and never goes below the minimum or above the maximum you set. SmartPulse plans each warehouse’s size hour by hour, so concurrency and size are handled together.