Snowflake warehouse size: credits per hour, warehouse cost by size, and how to change it

Snowflake warehouse size sets how much compute one cluster gets, and it runs from X-Small to 6X-Large across ten steps. X-Small consumes one credit per hour, and every step up doubles both the compute and the credit burn: Small is 2, Medium 4, Large 8, X-Large 16, and so on to 512 credits an hour at 6X-Large. At the Standard edition US price of $2.00 a credit, that is $2.00 an hour for an X-Small and $1,024.00 an hour for a 6X-Large. The important part is that doubling the size does not necessarily double what a piece of work costs, because Snowflake bills for time, not for data scanned.

Every Snowflake warehouse size, with what it actually costs

Credits per hour come from Snowflake's own consumption table, read on 16 August 2026. The dollar columns are that figure multiplied by the on-demand credit price in US regions.

Those hourly numbers look frightening at the bottom of the table and rarely matter, because almost nobody runs a 4X-Large for a full hour. What you pay is the hourly rate multiplied by the seconds the warehouse is actually awake. The full breakdown of credit prices by edition and region sits on our Snowflake pricing page, including the storage rate and the serverless multipliers that quietly bill in the background.

Why doubling the size often does not double the bill

This is the single most useful thing to understand about Snowflake sizing, and it is genuinely counterintuitive if you have come from a warehouse that charges per byte scanned.

Snowflake bills warehouse time. A Medium costs $8.00 an hour and a Large costs $16.00. So if a query takes twenty minutes on the Medium and ten minutes on the Large, both runs cost exactly the same: $2.67. You got the answer twice as fast for the same money. When a query parallelizes cleanly, sizing up is close to free, and sizing down to save money is an illusion that just makes people wait.

The catch is that not everything parallelizes. Snowflake's documentation is blunt about it: larger is not necessarily faster for small, basic queries. A query that reads one micro-partition cannot use eight nodes any better than it uses one, so on a Large it finishes in the same ten seconds it took on an X-Small and costs eight times as much. Sizing up helps when a query is genuinely compute-bound, scanning and joining large volumes. It does nothing for a lookup.

So the rule is: size up until the runtime stops improving, then stop. The point where doubling the warehouse no longer roughly halves the runtime is the point where you have started burning money. You can see this directly in QUERY_HISTORY by running the same workload at two sizes and comparing elapsed time.

The 60-second minimum, and the trap it sets

Warehouses bill per second, but every time compute is provisioned Snowflake charges a minimum of 60 seconds. After that first minute, billing is genuinely per second until the warehouse shuts down.

Snowflake's own worked example makes the trap clear. A warehouse that runs for 61 seconds, shuts down, then restarts and runs for less than a minute is billed for 121 seconds, not 62. Each resume pays the minute again.

That is why setting auto-suspend to one or two minutes on a warehouse that receives frequent queries backfires. It spends its life suspending and resuming, and every resume triggers a fresh 60-second charge. Snowflake recommends five to ten minutes for most workloads, and suggests disabling auto-suspend entirely if you have a heavy, steady workload or need the warehouse available with no start-up lag.

The minimum charge scales with size, which is worth a moment's thought. A 5X-Large burns 256 credits an hour, so 60 seconds costs 4.27 credits, or $8.53 at the Standard rate. Starting a very large warehouse and immediately stopping it is not free.

Suspending also throws away the cache

Each warehouse keeps a cache of table data on its local SSDs, and the bigger the warehouse the bigger that cache. When the warehouse suspends, the cache is dropped. Queries after a resume are slower until it rebuilds.

This is the real trade-off behind auto-suspend settings, and it is not just about the 60-second minimum. Aggressive suspension saves credits and costs you warm cache. A warehouse serving a dashboard that ten people open every morning may well be cheaper to leave running through the working day than to suspend between each visitor, once you count the repeated cold reads.

Decreasing the size of a running warehouse has the same effect. Removing compute resources drops the cache attached to them, so downsizing mid-workload can slow the next few queries even though it looks like a pure saving.

How to change a Snowflake warehouse size

One statement, and it works while the warehouse is running:

ALTER WAREHOUSE analytics_wh SET WAREHOUSE_SIZE = LARGE;

You can also change it in Snowsight from the warehouse settings. Either way the behaviour is the same, and there are two details worth knowing.

First, the extra compute does not join queries that are already running. Those finish on the resources they started with. New compute becomes available only to queries that are queued or submitted after it is fully provisioned. So resizing to rescue a query that is currently crawling will not help that query.

Second, you are billed for the additional resources from the moment they are provisioned, not from the moment something uses them. Resizing up and forgetting to resize back down is one of the most common ways a Snowflake bill drifts.

Size or multi-cluster? They solve different problems

These get confused constantly, and picking the wrong one wastes money without fixing anything.

A warehouse reserves resources for each query as it arrives. If it does not have enough left, the query queues and waits. So there are two distinct failure modes, and they need opposite fixes.

• Each query is slow when run alone. The warehouse is too small for the work. Size up.
• Each query is fast alone but everything crawls when the team is working. You are out of concurrency, not out of horsepower. Add clusters.

Multi-cluster runs several same-size copies of the warehouse and spreads incoming queries across them. It requires Enterprise edition or above, and it bills the size rate multiplied by the number of clusters currently running. An Enterprise Medium scaled to four clusters bills 16 credits an hour, exactly the same as a single X-Large, but it serves four times the concurrent queries rather than making one query faster. Run it in auto-scale mode with a minimum of one cluster so extra clusters start only when they are needed.

The warehouse types that do not bill one credit at X-Small

The doubling table above describes standard warehouses. Snowflake now sells several variants that change the base rate before you touch the size, and this rarely comes up in sizing discussions.

A practical way to pick a size

Start smaller than feels right. Snowflake's per-second billing means the cost of being wrong is minutes, not months, and you can resize at any time without recreating anything.

Run your heaviest real query on an X-Small and note the elapsed time. Double the size and run it again. If the runtime roughly halves, the query is using the extra compute, so keep going. When the runtime stops improving proportionally, step back one size. That is your answer, and it took maybe fifteen minutes and a couple of dollars to find.

Then separate your workloads. A warehouse sized for a nightly transformation is the wrong warehouse for people poking at dashboards, because their traffic patterns are nothing alike. Two right-sized warehouses with sensible auto-suspend almost always cost less than one compromise warehouse big enough for the worst case and awake all day. Treating warehouse spend as something you measure rather than guess at is the same discipline that works on any cloud bill, where the fix is nearly always visibility into what each resource actually costs rather than a blanket cap that blocks real work.

Where the size question usually comes from

In practice, "should we resize the warehouse?" is often the wrong question. Warehouses cost money while they are awake, and a large share of that awake time is not query execution at all. It is somebody writing a query, running it, finding it wrong, and writing it again, with the warehouse burning credits through every iteration because auto-suspend never gets a chance to fire.

That is a workflow cost dressed as a compute cost. Agentsql connects read-only to Snowflake, turns a plain-English question into SQL, runs it and shows you the SQL every time, which collapses those iterations into one and lets people who cannot write SQL stop queuing behind the person who can. If you want the detail on how that works against a warehouse, we covered Snowflake natural language query separately, and if you are still choosing a platform, BigQuery vs Snowflake sets per-second warehouse billing against per-byte scanning, which is exactly the difference that makes sizing matter here and not there.