Snowflake warehouse sizes and what each one costs in credits

Snowflake warehouse size is the one setting that decides how fast your credits burn. An X-Small warehouse uses 1 credit an hour. Each size up doubles that, all the way to 512 credits an hour for a 6X-Large. Most people learn this from the first bill.

But size is only half of the sum. The other half is how many hours the warehouse is awake, and that is where most Snowflake bills go wrong. This post gives you the full size table, what a credit costs, worked monthly figures, and a way to check your own account before you change anything.

A note on sources. I have no live Snowflake account to write this from. Every rate below is from Snowflake's own documentation or its Service Consumption Table, the version effective 30 September 2026, which I read on 1 October 2026. Prices change, and contracts differ. Check the current table and your order form.

Snowflake warehouse sizes and credits per hour

From Snowflake's warehouse overview, for a standard Gen1 warehouse:

Size	Credits / hour	At $3.00 / credit
X-Small	1	$3 / hr
Small	2	$6 / hr
Medium	4	$12 / hr
Large	8	$24 / hr
X-Large	16	$48 / hr
2X-Large	32	$96 / hr
3X-Large	64	$192 / hr
4X-Large	128	$384 / hr
5X-Large	256	$768 / hr
6X-Large	512	$1,536 / hr

The $3.00 column is the Enterprise on-demand list price in AWS US East, used here only so the doubling is easy to see.

Three billing rules sit under that table:

• Per second, with a 60-second minimum each time the warehouse starts or resumes. A 5-second query that wakes a warehouse bills a full minute.
• Suspended warehouses use no credits. The meter runs while the warehouse is awake, not while queries run.
• 5X-Large and 6X-Large are not in every region. The consumption table says they "may not be GA in all Regions".

Gen2 warehouses cost more per hour

This one catches people out. Snowflake's Gen2 documentation says that if you create a standard warehouse without a GENERATION clause, you get Gen2, unless Gen2 is not available in your region. The consumption table prices Gen2 at a higher rate:

Size	Gen1	Gen2 on AWS / GCP	Gen2 on Azure
X-Small	1	1.35	1.25
Medium	4	5.4	5
Large	8	10.8	10

Gen2 is meant to finish analytics and data engineering work faster, so per query it may cost less. I can't verify how much faster on your workload, and neither can a table. What I can say: if your bill moved and you did not change a size, check which generation your newer warehouses are on.

SHOW WAREHOUSES;   -- the size, auto_suspend and generation columns are the ones to read

How much is a Snowflake credit in dollars?

It depends on four things: your edition, your cloud, your region, and whether you pay on demand or by capacity contract. Snowflake's pricing page does not print a single number for this reason. It points to the consumption table.

On-demand prices from the table effective 30 September 2026:

Region	Standard	Enterprise	Business Critical
AWS US East (N. Virginia)	$2.00	$3.00	$4.00
AWS US West (Oregon)	$2.00	$3.00	$4.00
AWS EU Dublin	$2.60	$3.90	$5.20
AWS EU Frankfurt	$2.60	$3.90	$5.20
AWS AP Sydney	$2.75	$4.05	$5.50

Capacity contracts, paid up front, can bring the price down. The discount is in your order form, not in any public table. If you are on capacity, use your contracted rate in every sum below.

There is one more line most people never see: cloud services. The table charges it at 4.4 credits an hour, but only for the part of a day's cloud services use that exceeds 10% of that day's warehouse credits. For most accounts it is zero or close to it. If it is not, something unusual is running: very many tiny queries, or heavy metadata work.

What a month costs: worked arithmetic

These are illustrations, not quotes. All use $3.00 a credit and Gen1 rates. Change the price for your edition and the answer scales with it.

A small team, one X-Small, office hours. 1 credit × 8 hours × 22 days = 176 credits, about $528 a month.

The same team on Medium. 4 credits × 8 hours × 22 days = 704 credits, about $2,112 a month. Same queries, four times the bill, unless they finish four times faster.

The same team on Gen2 X-Small, AWS. 1.35 × 8 × 22 = 237.6 credits, about $713.

One X-Small that never suspends. 1 credit × 24 hours × 30 days = 720 credits, about $2,160 a month. That is more than the Medium in office hours, on the smallest size Snowflake sells.

Storage. On demand in AWS US East it is $23 per terabyte per month, on compressed data. One terabyte is $23. For most small teams, storage is the small part of the bill.

So the size matters, but the hours matter more. Which brings us to the most common reason a small warehouse runs 24 hours a day.

Why a small warehouse runs all day

Here is the finding I keep coming back to on this site:

A warehouse set to auto-suspend after 10 minutes but queried every 4 never suspends. It is billed as if it ran all day, and nothing in the settings looks wrong.

A BI tool refreshing a dashboard, a health check, a scheduled job polling for new rows. Each query is tiny. Each one resets the idle timer. The warehouse never reaches ten idle minutes, so it never sleeps. The default auto-suspend for a new warehouse is 600 seconds, which is ten minutes, according to CREATE WAREHOUSE.

Snowflake's own guidance suggests a low auto-suspend, "for example, 5 or 10 minutes or less". A shorter timeout helps. It does not help if something queries more often than the timeout. Then the fix is the query schedule, not the setting.

Bigger warehouse or multi-cluster warehouse?

They solve different problems.

• A bigger size gives each query more compute. It helps one heavy query finish sooner.
• A multi-cluster warehouse runs several clusters of the same size side by side, so many queries at once do not wait in a queue.

Snowflake's multi-cluster docs say resizing is the better way to speed up individual queries, while multi-cluster is for concurrency. Multi-cluster needs Enterprise Edition or higher. It bills the size's rate times the number of running clusters: three Medium clusters running together use 4 × 3 = 12 credits an hour.

The default scaling policy, Standard, starts clusters to avoid queuing. The Economy policy keeps clusters full and starts a new one only when it estimates at least six minutes of work. If queuing for a few minutes is acceptable, Economy is cheaper. If your concurrency problem is fifty analysts at 9 a.m., multi-cluster is the right tool. If it is one slow nightly job, it is not.

Which Snowflake warehouse size to pick

My rule of thumb, in order:

1. Start at X-Small. It is the default for a reason.
2. Size up only when a measured query gets close to twice as fast. Each step doubles the hourly rate. If Medium finishes a job in 60% of Small's time, you are paying 2 × 0.6 = 1.2 times as much for the same job.
3. Split by workload, not by team. One warehouse for loading, one for BI, one for ad hoc work, each sized for its own job. A single Large serving all three runs at Large for the lightest of them.
4. Set auto-suspend low, then check that it actually suspends. The setting is not the evidence. The metering history is.
5. Use multi-cluster for queues, not for speed.

Check your own account first

Before you resize anything, look at where the credits already go. Snowflake documents this view, SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY. It keeps 365 days and can lag by up to three hours.

Credits by warehouse over the last 30 days:

SELECT warehouse_name,
       SUM(credits_used)              AS credits,
       COUNT(DISTINCT start_time)     AS metered_hours
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE start_time >= DATEADD('day', -30, CURRENT_DATE())
GROUP BY warehouse_name
ORDER BY credits DESC;

A warehouse with close to 720 metered hours in 30 days was awake almost all the time. If nobody uses it at night, that is the finding above.

Idle cost, adapted from the example in Snowflake's own docs for that view: compute credits minus the credits attributed to queries.

SELECT warehouse_name,
       SUM(credits_used_compute)
         - SUM(credits_attributed_compute_queries) AS idle_credits
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE start_time >= DATEADD('day', -10, CURRENT_DATE())
  AND end_time < CURRENT_DATE()
GROUP BY warehouse_name
ORDER BY idle_credits DESC;

If you would rather not write SQL, the Snowflake cost calculator on this site takes size, hours and storage and shows the monthly figure, with the same doubling table. No email needed.

If the numbers look strange and you cannot see why, send me the cost export. I'll write back with the two or three things I'd look at first, within three business days, no call attached. And if you would rather talk it through, the call link is under this post. It comes last for a reason.

So: what does Snowflake cost?

Credits per hour for your size, times the hours the warehouse is awake, times your price per credit. Plus storage, which is usually small. The size table is fixed and public. The hours are where the money goes, and they are the part you control.

If the honest answer is that your data fits on one machine, the warehouse may be the wrong tool altogether. That case is in your Snowflake bill is mostly overhead, with the comparisons in DuckDB vs Snowflake and ClickHouse vs Snowflake. Local-First Analytics covers the one-machine path with DuckDB and Parquet; chapter 1 is free to read, the rest is on Amazon.

If you run a few hundred dollars a month of Snowflake and it is doing its job, you do not need me. Leave it alone.