Explanation
Why the waste happens and who it affects.
When its minimum and maximum cluster counts are set to the same value greater than 1, it runs in Maximized mode: Snowflake starts all clusters whenever the warehouse starts and keeps them running while the warehouse runs, regardless of how many queries are actually waiting. Every cluster bills at the full rate for the warehouse size, so a three-cluster Maximized warehouse costs three times a single cluster for every hour it is up.
Min and max are often pinned together to avoid any queuing during a known peak, such as a morning dashboard rush, and then never revisit it, so the extra clusters also run through quiet hours, weekends and batch windows when one cluster would serve the load. Snowflake's own Optimization insights flag this configuration as 'Inefficient usage of multi-cluster warehouses' and recommend lowering the minimum cluster count. Maximized mode is still reasonable for workloads with steady, high concurrency throughout the time the warehouse runs.
Billing model
The pricing dimensions that drive this cost.
- Per-cluster credits
- Each running cluster consumes credits at the hourly rate of the warehouse size, so total credits are the size rate multiplied by the number of clusters running
- Maximized mode
- Minimum equals maximum cluster count; all clusters start with the warehouse and bill for as long as it runs
- Auto-scale mode
- Maximum is higher than minimum; clusters start and stop with query load, so credits track actual concurrency
- Economy scaling policy
- In Auto-scale mode, starts an extra cluster only if Snowflake estimates enough load to keep it busy for at least 6 minutes
How to detect
5 checks to find it in your estate.
- Review the Optimization insight 'Inefficient usage of multi-cluster warehouses' in Snowsight Admin > Cost management > Account Overview, which flags warehouses with identical minimum and maximum cluster counts
- Run SHOW WAREHOUSES and list warehouses where min_cluster_count equals max_cluster_count and both are greater than 1
- Query WAREHOUSE_LOAD_HISTORY for those warehouses and compare AVG_RUNNING and AVG_QUEUED_LOAD by hour; low running load and no queuing outside peak hours means the extra clusters are idle
- Check CLUSTER_NUMBER in QUERY_HISTORY to see how many clusters actually received queries per hour; hours where queries land on only one cluster indicate the others were running without work
- Use WAREHOUSE_METERING_HISTORY to quantify credits for the warehouse and estimate the share attributable to clusters beyond the first
How to fix
5 ways to remove the waste.
- Switch to Auto-scale mode by lowering the minimum, for example ALTER WAREHOUSE <name> SET MIN_CLUSTER_COUNT = 1, keeping MAX_CLUSTER_COUNT at the level peak concurrency requires
- Set MAX_CLUSTER_COUNT to observed peak concurrency rather than a generous default; Snowflake suggests starting Auto-scale with a small maximum such as 2 or 3 and adjusting from observed load
- Use SCALING_POLICY = 'ECONOMY' for latency-tolerant workloads such as batch and reporting, accepting some queuing in exchange for fewer cluster starts; keep STANDARD where users need fast response under bursts
- If a peak really requires all clusters, raise MIN_CLUSTER_COUNT only for that window with a scheduled task and lower it afterwards, instead of pinning it permanently
- Confirm the change with WAREHOUSE_LOAD_HISTORY queuing metrics after rollout, and revisit whether the warehouse size itself can shrink once concurrency is handled by scaling out
Documentation
Vendor references for pricing and configuration.