Warehouse size cost doubles, every step
Snowflake's ten warehouse sizes -- X-Small through 6X-Large -- each roughly double the compute and the credits billed per hour of the size below them: X-Small is 1 credit/hour, Small 2, Medium 4, Large 8, X-Large 16, 2X-Large 32, all the way to 512 at 6X-Large. Billing is per-second after a 60-second minimum each time the warehouse starts or resumes, and a warehouse costs nothing while suspended -- but every hour it runs at a given size costs exactly that size's rate, independent of what the SQL running on it looks like.
Credit calculator
Pick a warehouse size
Assumption: the warehouse runs 4 active hours/day, 22 working days/month -- adjust the assumption to your own pattern, the doubling relationship stays the same either way.
Credit rates shown are Snowflake's documented per-size multipliers; your actual $/credit depends on your edition and cloud region contract.
Bigger doesn't always mean faster
The instinct behind sizing up is understandable -- more compute should mean faster queries. But Snowflake's own guidance is explicit that "larger is not necessarily faster for small, basic queries." A query that's bottlenecked on something other than raw compute -- queuing on a busy warehouse, cold-start provisioning time, a query plan that doesn't parallelize well -- can see little to no improvement from a bigger warehouse, while the credit cost doubles regardless. Sizing up is the right fix specifically for queries that are memory-bound (see spilling) or genuinely compute-bound at scale, not a general-purpose "make it faster" lever.
The other hidden cost: idle time
Warehouse cost doesn't only come from being oversized -- it also comes from running when nothing is actually happening. WAREHOUSE_METERING_HISTORY has a column, CREDITS_ATTRIBUTED_COMPUTE_QUERIES, that counts only the credits tied to an actual query execution. The gap between that and CREDITS_USED_COMPUTE is compute time the warehouse burned while sitting idle, waiting for its auto-suspend timeout to hit. A warehouse with a generous idle timeout, running many small on-and-off workloads throughout the day, can rack up a surprising amount of this "nobody's SQL asked for this" cost before a single query is ever examined.
Key takeaways
- Every warehouse size step roughly doubles the credit cost -- 1, 2, 4, 8, 16, 32 credits/hour from X-Small to 2X-Large.
- That doubling happens independent of how well-written the SQL running on the warehouse is.
- A bigger warehouse doesn't proportionally speed up every query -- it mainly helps memory- and compute-bound work.
- Idle time between queries, driven by auto-suspend settings, is a separate and often-overlooked cost driver from sizing.
The actual cost levers, in order
1. Warehouse size
The single biggest lever, and a doubling relationship. Check whether the workload actually needs the current size before touching the SQL.
2. Auto-suspend timeout
A short timeout costs more start/resume minimums on bursty workloads; a long one pays for idle time between queries. Tune it to the actual query arrival pattern.
3. Multi-cluster vs single, bigger warehouse
Scale out for concurrency (more queries at once), scale up for a single query's speed -- using the wrong one for the problem wastes credits either way.
4. The SQL itself
Real, but usually the smallest lever of the four -- pruning, spilling, and join efficiency matter, but rarely by a full warehouse-size multiple.
Find your real cost driver
The download below starts with total credits per warehouse, then breaks out idle overhead specifically, then checks whether each warehouse's size actually matches what it typically scans -- in roughly the order worth checking, before opening a single query's execution plan.