Warehouse size determines the rate of Snowflake compute consumption.
A Medium warehouse consumes 4 credits an hour whether it runs one query or forty. Snowflake bills per second, with a 60-second minimum each time the warehouse resumes. For workloads with excess capacity, right-sizing can halve warehouse cost without changing SQL.
Every named size doubles the credits per hour of the one beneath it. X-Small costs 1 credit per hour, Small 2, Medium 4, Large 8, X-Large 16, 2X-Large 32, 3X-Large 64, and 4X-Large 128. A larger warehouse provides additional compute, memory, and local SSD without requiring SQL changes.
Because billing is per second after the 60-second minimum, a larger size reduces cost only when its runtime improvement exceeds its higher rate.
A larger warehouse can accelerate queries limited by memory or disk. Additional RAM and SSD reduce runtime when a query scans large volumes or spills because its working set does not fit in memory. The query profile reports bytes spilled to local and remote storage; spilling indicates that the workload may be undersized.
Small queries may not use the additional resources. A point lookup or light aggregation can have the same runtime on X-Small and 2X-Large, making the larger warehouse more expensive. Representative queries are used to measure the workload's response to scaling.
Doubling warehouse size doubles the rate, so the larger warehouse reduces credit consumption only when it cuts runtime by more than half.
A query that runs 120 seconds on a Medium warehouse costs 4 credits per hour times 120/3600 hours, or 0.133 credits. On a Large at 8 credits per hour, break-even occurs at exactly 60 seconds, where 8 times 60/3600 also equals 0.133 credits. A runtime of 45 seconds consumes 8 times 45/3600, or 0.100 credits, while a runtime of 80 seconds consumes 0.178 credits, which is 33 percent more. A service-level agreement (SLA) may still justify the higher cost.
Increasing warehouse size is scaling up and can accelerate individual queries, but it does not directly address queuing. When ten users submit queries simultaneously, a larger single cluster may still process them sequentially.
Multi-cluster warehouses scale out to address concurrency. MIN and MAX settings control the number of equal-sized clusters added as load changes. The STANDARD policy adds clusters more aggressively to reduce queues, while ECONOMY waits longer to reduce credit consumption. Multi-cluster warehouses require Enterprise edition or above.
WAREHOUSE_METERING_HISTORY reports credits consumed per warehouse per hour. QUERY_HISTORY reports execution time, queue time, and bytes spilled per query. Joining the views identifies warehouses that may require resizing.
-- warehouses spilling to remote storage, last 7 days
select warehouse_name,
count(*) as queries,
sum(bytes_spilled_to_remote_storage) as remote_spill_bytes
from snowflake.account_usage.query_history
where start_time >= dateadd('day', -7, current_timestamp())
and bytes_spilled_to_remote_storage > 0
group by 1
order by remote_spill_bytes desc;
No. It speeds up queries bound by memory or disk, where the extra RAM and SSD cut spilling. Small or lightweight queries do not use the added resources, so a bigger size costs more and returns the same runtime.
Reach for multi-cluster when queries are queuing under concurrent load, since it adds clusters to run more at once. Reach for a bigger size when individual queries are slow. Multi-cluster requires Enterprise edition or above.