How Much Does Snowflake Cost? Credits & Warehouses Explained

Snowflake doesn’t bill you in dollars — it bills you in credits. A credit is the unit of compute consumption, and a running virtual warehouse burns credits per second at a rate set by its size. To turn a Snowflake bill into dollars you need two numbers: how many credits you consumed, and what your contract charges per credit (a representative list rate is ~$2–4 per credit, but it varies by edition, region, and cloud — check your own contract). Everything else on this page is arithmetic on those two numbers.

Most “Snowflake pricing” confusion comes from looking for a sticker price that doesn’t exist. There is no per-seat fee and no flat monthly tier that decides your bill. Your bill is credits consumed × your per-credit rate, plus storage and a little overhead. Get those mechanics straight and the whole invoice stops being mysterious. Let’s build it up from the credit.

01 / THE UNITWhat is a credit in Snowflake?

A Snowflake credit is the unit of measure for compute. When a virtual warehouse is running, it consumes credits continuously — billed per second, with a 60-second minimum each time it resumes. The rate at which a warehouse burns credits is fixed by its size: an X-Small consumes 1 credit per hour, and every step up the size ladder doubles the rate.

Crucially, you are billed for wall-clock run-time, not for the work done. A warehouse that sits awake and idle for ten minutes after a query finishes still bills those ten minutes. This is the single most important fact about Snowflake cost, and we’ll come back to it.

02 / THE LADDERHow many credits does each warehouse size use?

Warehouse size is the dial that sets your burn rate. Each size doubles both the compute power and the credits-per-hour of the one below it. The table below maps every size to its credit rate, with an illustrative dollar figure at a representative $3/credit list rate so you can see the shape — your real number depends on your contract.

*Illustrative only. The $3/credit rate is a representative midpoint — your actual per-credit price varies by edition, region, and cloud. Check your contract or a recent invoice.

The doubling is the part teams underestimate. Jumping from Medium to Large to handle one slow report quietly doubles the per-second cost of every query that warehouse runs afterward — including the cheap dashboard refreshes that didn’t need the extra muscle. Size is a per-warehouse decision with account-wide consequences.

Every step up the warehouse ladder doubles your burn rate. A 4X-Large costs the same per hour as 128 X-Smalls.

— the credit ladder

03 / THE MATHWhat does a single query actually cost?

Cost per query is mechanical once you have the credit rate:

query cost = (execution seconds ÷ 3600) × credits/hour × $ per credit

Take a dashboard query that runs 20 seconds on a Large warehouse (8 credits/hour), at a representative $3/credit:

• 20 s ÷ 3600 = 0.00556 hours
• × 8 credits/hour = 0.0444 credits
• × $3 = ~$0.13 per run

Thirteen cents sounds trivial. But a BI dashboard that refreshes that query every 5 minutes for 30 users runs it thousands of times a day — and if each run also has to wake an idle warehouse, you pay the 60-second minimum, not the 20 seconds of actual work. Now the same logical answer costs $0.40+ per run, recomputed all day. Cost per query is small; cost per query pattern is where budgets go.

You can pull the raw ingredients straight from ACCOUNT_USAGE to do this for your own account:

-- Approximate credits & cost per query, last 7 days
select
  query_id,
  warehouse_name,
  warehouse_size,
  total_elapsed_time / 1000 / 3600       as elapsed_hours,
  case warehouse_size
    when 'X-Small'  then 1   when 'Small'    then 2
    when 'Medium'   then 4   when 'Large'    then 8
    when 'X-Large'  then 16  when '2X-Large' then 32
    when '3X-Large' then 64  when '4X-Large' then 128
  end                                     as credits_per_hour,
  elapsed_hours * credits_per_hour        as approx_credits,
  approx_credits * 3.00                   as approx_usd   -- swap in YOUR rate
from snowflake.account_usage.query_history
where start_time > dateadd('day', -7, current_timestamp())
order by approx_credits desc
limit 50;

04 / THE LEAKSThe hidden costs that inflate your bill

The headline credit math is the easy part. The line items that surprise finance are the ones that don’t map to a query you remember running:

• Idle time. A warehouse bills every second it’s awake, including the gap between the last query finishing and AUTO_SUSPEND firing. A 600-second idle timeout on a Large warehouse can quietly bill more idle credits than working ones on a lightly-used cluster.
• Auto-resume + the 60s minimum. Every time a suspended warehouse wakes for a query, you pay a minimum of 60 seconds, even for a 2-second query. Spiky, intermittent workloads pay this tax constantly.
• Cloud services. Metadata operations, query compilation, and result-cache lookups run on Snowflake’s cloud-services layer. It’s free up to 10% of your daily compute credits, but heavy short-query or high-concurrency workloads can breach that 10% and start billing.
• Storage & Time Travel. Billed separately per TB/month. TIME TRAVEL and FAIL_SAFE retain historical versions of changed data, so high-churn tables with long retention quietly multiply storage.

This is why two teams querying the same data can pay wildly different amounts. The team whose warehouse auto-suspends aggressively and whose repeat reads come from a cache pays for ~20 seconds of work. The team on a 600-second timeout, waking the warehouse for every refresh, pays for minutes. Same SQL, very different invoice.

05 / YOUR NUMBERSHow do you see your own cost per query?

The SQL above gets you started, but stitching ACCOUNT_USAGE views into a per-team, per-query cost picture is its own project — and the views lag, sample, and don’t attribute cost to the app or dbt model that caused it. For a durable view of where credits actually go, see Snowflake cost monitoring, which covers building (or buying) attribution you can trust.

The cleaner approach is to attribute cost at the wire, where every query passes anyway. chukei — the open-source, Apache-2.0 Snowflake cost optimization engine — is a transparent proxy that sits in your own VPC; drivers change one hostname and nothing else, and it stamps every query with the user, app, team, BI tool, or dbt model that owns the credits. No query tags to maintain, no view to babysit.

06 / NEXTFrom understanding cost to cutting it

Once you can read your bill in credits, the levers to cut it are concrete: right-size warehouses, suspend idle compute sooner, and stop recomputing the same reads. That’s the subject of how to reduce Snowflake costs, and the full strategic picture lives in our cornerstone guide to Snowflake cost optimization.

chukei’s role is the in-path automation: it serves deterministic repeat reads from a verified cache (continuously double-checked against live Snowflake — in soak testing, ~120k queries / ~60k cache hits with 0 mismatches), models idle windows with a Poisson process to recommend safe early suspend, and adds ~2 ms p99 overhead on the hot path. Any uncertainty — writes, non-deterministic SQL, large results — fails open to a byte-identical passthrough to Snowflake. It never breaks a query, and the savings (a target in the 15–30% range, never a guarantee) are projected by a replay simulator and backed by Ed25519-signed evidence before anything touches your path.

Want to turn “how much does Snowflake cost?” into “how much should it cost?” Export a month of QUERY_HISTORY and run it through chukei’s replay simulator — it projects, offline and signed, what each lever could conservatively recover before you change a single connection string.