Snowflake pricing explained: credits, warehouse sizes and storage costs

How Snowflake pricing works

Snowflake is consumption-based: there is no licence fee and no charge for an idle account. You pay for what runs and what is stored, and the unit for everything that runs is the credit.

What a credit costs

The price of a credit depends on your edition, your cloud provider and region, and whether you buy on demand or commit to capacity up front. Snowflake publishes the on-demand prices on its pricing page and in the Service Consumption Table.

These are on-demand list prices per credit from the consumption table effective 30 September 2026. The same warehouse doing the same work costs 30% more in Frankfurt than in Virginia, and twice as much on Business Critical as on Standard. Edition is a feature decision (Time Travel length, multi-cluster warehouses, compliance controls) that is also a price multiplier on every query you will ever run.

On demand or capacity

On demand means you pay the list price monthly in arrears. Capacity means you commit to a dollar amount for a term and get a discount on the credit price in return. The discount is in your order form, not on a public page, so the list price above is the ceiling, not what a larger customer pays.

One detail in the current table matters if you use Snowflake’s AI features: the capacity discount applies to platform credits and does not apply to AI credits, which are priced separately.

Compute: credits per hour by warehouse size

A virtual warehouse is the compute that runs your queries. Its size sets how many credits it uses per hour, and it uses them for every second it is running, whether or not a query is executing.

Credits per hour, from Snowflake’s consumption table. Standard warehouses continue to 5X-Large (256) and 6X-Large (512). Gen2 warehouses use newer hardware and cost 35% more credits per hour on AWS and GCP, and 25% more on Azure (1.25 for X-Small, up to 160 for 4X-Large). They are worth it only where the query finishes proportionally faster.

Per-second billing and the 60-second minimum

Snowflake bills warehouses per second, with a 60-second minimum each time a warehouse starts or resumes. A query that takes four seconds on a suspended warehouse costs a full minute. Fifty such queries spread across an hour, each waking the warehouse, cost fifty minutes.

The cost of a single run is simple arithmetic:

credits = credits per hour
          × seconds running ÷ 3,600

A Medium warehouse running for 15 minutes uses 4 × 900 ÷ 3,600 = 1 credit. The same 15 minutes on an X-Small uses 0.25. Whether the Medium is worth four times the price depends on whether it finishes the work four times faster, and for many reporting queries it does not.

Auto-suspend, auto-resume and multi-cluster

Auto-suspend is how long a warehouse stays up with nothing to do before it stops billing. Auto-resume restarts it on the next query. Both are on by default. A warehouse with a 10-minute auto-suspend that receives one dashboard query every 8 minutes never suspends at all.

A multi-cluster warehouse adds clusters of the same size when queries start to queue. The rate is the warehouse’s rate multiplied by the number of clusters running, so a Medium that scales to three clusters during the morning rush is using 12 credits per hour for as long as it stays scaled.

Storage and data transfer

Storage is the predictable part of the bill. It is charged on the average compressed terabytes you hold across the month, and it does not move because somebody opened a dashboard.

On demand, storage on AWS US East costs $23 per TB per month ($24.50 in Frankfurt). On capacity it steps down with contract size, from $23 to $13.80 per TB at the largest tier. What is counted is more than your live tables:

• Table data, in permanent, transient and temporary tables.
• Time Travel: earlier versions of changed data, kept for up to 1 day on Standard and up to 90 days on Enterprise and above.
• Fail-safe: a further 7 days for permanent tables. Transient and temporary tables have none.
• Staged files held in internal stages.

Time Travel and Fail-safe are charged on the data that changed, so a large table that is fully rewritten every night carries several copies of itself. Long retention on tables like that is where storage grows without anyone deciding it should.

Data transfer within the same cloud region is free. Moving data out is not: from AWS US East it costs $20 per TB to another AWS region and $90 per TB to another cloud or the internet.

What bills outside your warehouses

Not every credit comes from a warehouse you sized. Three other lines appear on a statement, and the current price list adds two newer warehouse types alongside them.

Cloud services is the layer that handles authentication, metadata and query compilation. It is charged at 4.4 credits per hour of use, but only for the part of the day’s usage that exceeds 10% of that day’s warehouse credits. Most accounts never pay for it. Accounts that run very large numbers of tiny queries sometimes do.

Serverless features run on compute Snowflake manages, billed per compute-hour with a multiplier per feature. Serverless tasks are multiplied by 0.9, materialized view maintenance and the search optimization service by 2, and Snowpipe is charged at 0.0037 credits per GB loaded. None of this is capped by the size of your warehouses.

AI features (Cortex functions, agents and the rest) bill in AI credits, a separate unit priced at $2.00 on demand for global and $2.20 for regional processing, mostly per million tokens. They do not draw on the warehouse you gave your analysts, so they will not show up in a warehouse-level report. If you are weighing Cortex Analyst against other ways to let people ask Snowflake in a chat, governed AI analytics on Snowflake compares them.

The same table lists interactive warehouses, which cost fewer credits per hour (0.6 for X-Small) but carry a 60-minute minimum every time they resume, and adaptive warehouses, where Snowflake sizes compute to the workload and credits follow the queries that ran.

A worked example: one month, one team

Take a team on Enterprise edition in AWS US East, paying on demand at $3.00 per credit, with three warehouses and 2 TB of data.

That is 768 credits, or $2,304 of compute. Storage adds 2 × $23 = $46, and cloud services stay under the 10% threshold, so the month comes to about $2,350. On Standard edition the same usage would be $1,536 of compute; in Frankfurt on Enterprise, $2,995.

Now look at which line is largest. The reporting warehouse is half the size of the transformation one and it is 57% of the compute bill, because it is up for the whole working day. Nobody chose ten hours. Dashboards refreshing on a timer chose it.

How to see what you are spending

Snowflake records its own consumption in the ACCOUNT_USAGE schema of the shared SNOWFLAKE database. Three views answer most questions, and all of them are plain SQL.

By default only ACCOUNTADMIN can read them. An administrator can grant another role access with GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE <role>, or more narrowly with the USAGE_VIEWER database role. Expect the data to lag real time: up to three hours for the metering views and up to eight for query attribution.

Credits by warehouse

SELECT
  warehouse_name,
  ROUND(SUM(credits_used_compute), 1)
    AS compute_credits
FROM snowflake.account_usage
  .warehouse_metering_history
WHERE start_time >=
  DATEADD(day, -30, CURRENT_TIMESTAMP())
GROUP BY warehouse_name
ORDER BY compute_credits DESC;

This is the first query to run. It tells you which warehouse is the bill.

When a warehouse is awake

SELECT
  HOUR(start_time) AS hour_of_day,
  ROUND(SUM(credits_used_compute), 1)
    AS credits
FROM snowflake.account_usage
  .warehouse_metering_history
WHERE warehouse_name = 'REPORTING_WH'
  AND start_time >=
    DATEADD(day, -30, CURRENT_TIMESTAMP())
GROUP BY hour_of_day
ORDER BY hour_of_day;

A warehouse that serves people should look like a working day with a lunch dip. A flat line from 08:00 to 20:00 means something is refreshing on a timer and keeping it awake.

The queries that repeat

SELECT
  query_parameterized_hash,
  COUNT(*) AS runs,
  ROUND(SUM(credits_attributed_compute), 2)
    AS credits,
  ANY_VALUE(query_id) AS sample_query_id
FROM snowflake.account_usage
  .query_attribution_history
WHERE start_time >=
  DATEADD(day, -30, CURRENT_TIMESTAMP())
GROUP BY query_parameterized_hash
ORDER BY credits DESC
LIMIT 20;

QUERY_ATTRIBUTION_HISTORY assigns warehouse credits to individual queries, and the parameterized hash groups queries that differ only in their literal values. The top of this list is rarely one heavy query. It is one ordinary query, run four thousand times. The view excludes idle time, so its total will be lower than the warehouse’s: the gap is what you paid for a warehouse that was up and waiting.

What was actually billed

SELECT
  usage_date,
  service_type,
  ROUND(SUM(credits_billed), 1)
    AS credits_billed
FROM snowflake.account_usage
  .metering_daily_history
WHERE usage_date >=
  DATEADD(day, -30, CURRENT_DATE())
GROUP BY usage_date, service_type
ORDER BY usage_date, credits_billed DESC;

METERING_DAILY_HISTORY is the one that matches the invoice, because it applies the cloud services adjustment and lists serverless and AI services as their own service types.

Controls that cap the bill

Seeing the spend is half of it. Snowflake gives you four controls that limit it, and they are worth setting before anything is tuned.

Auto-suspend at 60 seconds for warehouses that serve reports and ad hoc work. Anything shorter fights the 60-second minimum; anything much longer pays for idle time.

ALTER WAREHOUSE reporting_wh
  SET AUTO_SUSPEND = 60;

A resource monitor sets a credit quota for a warehouse and can notify, suspend, or suspend immediately when it is reached. It needs the ACCOUNTADMIN role to create.

CREATE OR REPLACE RESOURCE MONITOR
  reporting_limit
  WITH CREDIT_QUOTA = 500
  TRIGGERS ON 100 PERCENT DO SUSPEND;

ALTER WAREHOUSE reporting_wh
  SET RESOURCE_MONITOR = reporting_limit;

A statement timeout stops a runaway query instead of letting it run for hours: ALTER WAREHOUSE reporting_wh SET STATEMENT_TIMEOUT_IN_SECONDS = 600.

A budget covers what resource monitors cannot. Resource monitors track warehouses only; Snowflake’s own documentation sends you to budgets for serverless features and AI services.

Finally, one warehouse per kind of work. Loading, transformation, reporting and ad hoc analysis on separate warehouses means each can be sized and suspended for what it does, and the first query in this guide tells you which one to look at.

Why reporting is the part you cannot predict

Transformations run on a schedule you wrote. Storage grows with data. Reporting is different: its cost is set by how many people and tools ask the same question, and how often.

Four patterns account for most of it:

• The same logic in several places. Customer lifetime value is calculated in the marketing dashboard, again in the finance sheet and again in a notebook. Each copy scans the same base tables.
• Live connections to raw tables. A BI tool on a live connection sends a query for every chart, on every open and every filter change. Pointed at event-level tables, each of those is a full scan.
• Refresh on a timer. A dashboard set to refresh every ten minutes from 08:00 to 20:00 runs its queries 72 times a day whether or not anyone is looking, and keeps the warehouse from suspending between runs.
• Several tools, one fact table. Marketing in one BI tool, product in another, finance in spreadsheets: three sets of near-identical aggregates built independently.

None of these is a pricing problem, and none is fixed by a larger warehouse. The third query above will show them to you as a short list of statements with very high run counts. If you want the background on how Snowflake separates storage from compute in the first place, the Snowflake explainer covers it, and Databricks pricing shows the same pattern under a different billing unit.

The fix is structural: work out the heavy logic once, store the result as a table in Snowflake, and have every report read that table. A join across orders, sessions and customers that runs once a night on the transformation warehouse costs a few credits. The same join run by every dashboard refresh costs that many credits, many times a day.

One definition, many readers

Building the table is the analyst’s job, in SQL, in Snowflake. Keeping it as the one place everyone reads from is the harder half, and that is the part OWOX Data Marts is for. It does not transform your data or make a query cheaper. It gives the query one home, a schedule and a list of who reads it.

You connect Snowflake as a storage, naming the warehouse that OWOX Data Marts should run on. The setup guide recommends a dedicated warehouse, which fits everything above: reporting gets its own warehouse, its own auto-suspend and its own line in the first query.

A Data Mart is a SQL query, a table or a view that an analyst publishes under a business name. The SQL stays the analyst’s: written once, validated against Snowflake, and kept in one place instead of copied into each dashboard.

From that one definition, the same Data Mart goes to each place the team already reads: Google Sheets, Data Studio, Slack or email. A Google Sheets report writes the rows into the sheet on each run, so the twenty people who open that sheet during the day are reading a spreadsheet, not querying a warehouse. Runs happen on the schedule you set, and each one is recorded in Run History.

That turns the unpredictable part of the bill into arithmetic. A report that runs at 07:00 every weekday is 22 runs a month on a warehouse you sized, whatever the number of readers. Business users get the numbers without warehouse credentials, and the analyst can answer “what does this report cost us” from the first query in this guide.

The walk-throughs for this setup are Snowflake as a reusable reporting layer and Snowflake reports in Google Sheets. If you are still choosing a warehouse, Snowflake vs BigQuery compares the two pricing models side by side, and how to choose a data warehouse adds Redshift, Athena and Databricks.

SnowflakeHow to Turn Snowflake into a Self-Service Marketing Analytics EngineOctober 1, 2026→SnowflakeWhat is Snowflake? A Beginner's Guide to the Cloud Data WarehouseOctober 1, 2026→Google BigQuerySnowflake vs BigQuery: A Detailed ComparisonOctober 13, 2026→

See all articles →