Snowflake cost management: how billing works and how to cut the bill

Snowflake separates storage from compute and charges for what you use. That flexibility is its great advantage and also the source of surprises on the invoice: nobody buys a server, but anyone can leave a large warehouse running or launch a query that scans the whole table. Managing Snowflake cost is not about switching things off. It is about understanding what is billed, measuring who consumes it and deciding with data.

This article explains how Snowflake bills, where the money usually goes and the strategies we apply to reduce and optimise spend without slowing teams down. The prices quoted are those of Snowflake's consumption table as of November 2026.

How Snowflake bills

The invoice has three parts: compute, storage and data transfer. All three are settled monthly, either On Demand or against an amount purchased up front (Capacity).

The credit: the unit of compute

All compute is paid in credits. The price of a credit depends on three things: the Snowflake edition (Standard, Enterprise, Business Critical or VPS), the cloud provider and the region. In the usual European regions (AWS Frankfurt, Azure West Europe, GCP Netherlands) the on-demand price today is USD 2.60 for Standard, USD 3.90 for Enterprise and USD 5.20 for Business Critical. A Capacity contract applies a discount to that price in exchange for an annual consumption commitment.

The first cost decision therefore comes before any query: edition and region. Enterprise costs 50% more per credit than Standard and adds features such as multi-cluster warehouses, 90 days of Time Travel or data masking. If they are not used, you are paying for them.

Virtual warehouses: per second, with a one-minute minimum

A warehouse is the engine that runs queries and loads. It consumes credits per hour according to its size, and each size doubles the previous one:

Size	XS	S	M	L	XL	2XL	3XL	4XL
Credits per hour	1	2	4	8	16	32	64	128

Three rules shape the bill:

• Billing is per second while the warehouse is running, with a 60-second minimum every time it starts. A two-second query on a warehouse that wakes up for it costs a full minute.
• Suspended means zero. That is why auto-suspend and auto-resume are the first setting to fix.
• A multi-cluster warehouse multiplies consumption by the number of clusters active at any moment.

Second-generation (Gen 2) warehouses run on newer hardware and cost 1.35 times more per hour on AWS and GCP and 1.25 times more on Azure. Because queries finish sooner, they can be cheaper per unit of work, but not always: measure it with the real workload. Snowpark-optimised warehouses, with more memory, have their own price table as well.

Cloud services: the coordinating layer

The cloud services layer handles authentication, query optimisation, metadata and transactions. Its use is metered at 4.4 credits per hour, but each day an amount equal to 10% of what the warehouses consumed is exempt: only what exceeds that 10% is billed. In most accounts it never shows up. It appears when there are huge numbers of small metadata queries, mass cloning, tools that run SHOW or DESCRIBE in a loop, or many queries answered entirely from the result cache.

Serverless features: compute that never suspends

Some features use compute managed by Snowflake, with no warehouse. Some are billed in "compute-hours" equivalent to an XS, multiplied by a factor specific to each feature; others, by data volume:

• Materialised view maintenance and Search Optimization Service: factor 2.
• Serverless tasks: factor 0.9 (0.5 in Flex mode).
• Query Acceleration Service: factor 1.
• Snowpipe: 0.0037 credits per GB ingested.
• Snowpipe Streaming: 0.0037 credits per uncompressed GB on the high-performance architecture. The classic architecture is billed on compute (factor 1) plus 0.01 credits per client per hour.
• Automatic clustering: factor 2 in the classic mode; with Optima Clustering, 0.007 credits per uncompressed GB, which can be lower depending on how much the data overlaps.

These charges are switched on once and keep consuming until someone switches them off. Classic resource monitors do not cover them either; for those you need budgets, which we cover below.

AI features

Cortex functions (summaries, classification, embeddings, Cortex Analyst, Cortex Search) are billed per tokens processed or per unit, with their own "AI credits". These credits have a price and a capacity discount scale separate from platform credits: the discount negotiated for platform credits does not apply to them. If they are added to a daily pipeline, measure their cost per operation from day one.

Storage

A flat rate per terabyte per month, calculated on the daily average of bytes stored after compression. In the European regions mentioned it is between USD 20 and 24.50 per TB per month on demand (20 in GCP Netherlands, 23 in Azure West Europe and 24.50 in AWS Frankfurt), with tiered discounts under Capacity. What many forget is what that average includes:

• The active data in tables.
• Time Travel: previous versions of the data during the configured retention period (0 to 90 days in Enterprise).
• Fail-safe: 7 additional days of backup on permanent tables, which cannot be disabled.
• Clones only pay for the data that changes relative to the original, but tables copied with CREATE TABLE AS pay in full.

Data transfer

Bringing data into Snowflake is free. Moving it out to another region, another cloud or the internet is charged per TB. This affects cross-region replication, COPY INTO unloads to buckets on another cloud and connections from outside the region.

A sample invoice

A mid-sized company on Snowflake Enterprise in Azure West Europe:

Workload	Warehouse	Usage	Credits per month
Nightly ELT loads	L (8 cr/h)	2 h a day, 30 days	480
Reports and Power BI	M (4 cr/h)	8 h a day, 22 days	704
Ad hoc analytics	S (2 cr/h)	4 h a day, 22 days	176
Total compute			1,360

At USD 3.90 per credit, compute comes to USD 5,304 a month. With 10 TB of compressed data, storage adds about USD 230. Compute is more than 95% of the invoice, which is why almost all optimisation focuses there. Note too that the reporting warehouse costs half as much per hour as the loading one and is still the most expensive per month: hours running matter more than size.

Where the money goes

When we review an account, the same symptoms keep coming up:

• Warehouses running with no queries, with auto-suspend set to 10 minutes or disabled "so it doesn't take long to start".
• Sizes chosen by eye: an XL for queries that fit in an S, because someone bumped it up one day for a one-off load and nobody brought it back down.
• Queries with no pruning: SELECT * on huge tables, filters wrapped in functions, joins without a condition and queries that spill to disk for lack of memory.
• Pipelines that run too often: a load every five minutes when the business looks at the report once a day.
• Development and test environments with no limits, sized like production.
• Forgotten serverless features: search optimisation on tables nobody queries that way any more, materialised views from a closed project.
• Table copies and 90-day Time Travel on staging data that is rebuilt every night.

Eight strategies to reduce and optimise cost

1. Measure and attribute before touching anything

You cannot manage what you do not measure. Snowflake exposes everything you need in the ACCOUNT_USAGE schema:

• WAREHOUSE_METERING_HISTORY: credits per warehouse and hour, including idle time.
• QUERY_HISTORY: detail of each query (user, role, warehouse, duration, bytes scanned, spilling).
• QUERY_ATTRIBUTION_HISTORY: compute credits attributed to each query. It does not include the warehouse's idle time; that cost is obtained by difference against WAREHOUSE_METERING_HISTORY and has to be apportioned with a rule of your own.
• METERING_DAILY_HISTORY: compute, cloud services and serverless per day.
• STORAGE_USAGE and TABLE_STORAGE_METRICS: active storage, Time Travel and Fail-safe per table.

From these you build a cost dashboard per team, application and query. Attributing it properly takes two habits: query tags in every tool and pipeline, and object tags on warehouses and databases with the cost centre or responsible domain. Snowsight also includes a cost management view with the most expensive queries.

2. Configure warehouses deliberately

• Short auto-suspend: 60 seconds is a good starting point for batch workloads. Interactive BI may justify a little more, because the warehouse's local cache is lost on suspend and the next query takes longer.
• Auto-resume on, always.
• One warehouse per workload type (loads, reporting, data science), not one giant shared one. It lets you size, measure and cap each separately.
• Start small and scale up with evidence. Going up a size doubles the hourly cost; it only pays off if the query finishes in less than half the time. The signals to scale up are remote disk spilling and queueing; without them, scale down.
• Multi-cluster for user concurrency, with a sensible maximum cluster count, instead of a bigger warehouse. The Standard policy starts clusters as soon as queries queue and suits interactive BI; the Economy policy saves credits by letting queries wait, and suits workloads that tolerate that wait.
• Timeouts: STATEMENT_TIMEOUT_IN_SECONDS and STATEMENT_QUEUED_TIMEOUT_IN_SECONDS per warehouse stop a forgotten query from running all night.
• Evaluate Gen 2 with the real workload: on heavy loads it usually lowers cost per job; on small queries it does not.

3. Set limits that warn and limits that cut

• Resource monitors: a monthly credit quota per account or per warehouse, with up to five thresholds that notify and, optionally, a threshold that suspends the warehouse (at 100% or at whatever percentage you choose). Aggressive thresholds for development and test; for production, notify at 75% and 90% and suspend only if there is a response plan.
• Budgets: a monthly spending limit that also covers serverless features and lets you group objects. They notify by email or webhook when the forecast exceeds the limit, but they do not cut consumption.
• Permissions: who can create warehouses, resize them or enable serverless features. Most runaway spend comes from everyone being able to.

4. Optimise queries and the data model

• Use partition pruning: Snowflake reads only the micro-partitions it needs when filters hit columns whose data is well ordered. Load large tables ordered by date and add clustering keys only when the table is very large and always filtered on the same columns.
• Select only the columns you need: storage is columnar and every extra column is read from disk.
• Avoid functions on filtered columns and type conversions in joins, which prevent pruning.
• Incremental loads instead of recalculating everything every night; dynamic tables with a target lag that matches the business, not the minimum.
• Result cache: an identical query on unchanged data is answered from cache for 24 hours without spending warehouse credits. Dashboards with stable queries benefit a lot, as long as nobody adds CURRENT_TIMESTAMP or changing parameters.
• Review the execution plan of the 20 most expensive queries every month. There are usually one or two that, rewritten, pay for the whole optimisation effort.

5. Review workloads and frequencies

• Match pipeline frequency to when the data is used. A daily report does not need a load every five minutes.
• Group small tasks on the same warehouse and in the same window to amortise the 60-second minimum and the cache.
• Choose between Snowpipe (continuous, small files) and batch COPY (large files at fixed times) case by case. Files of 100 to 250 MB compressed load better than thousands of tiny files.
• Switch off what is no longer used: tasks, streams, materialised views, search optimisation.

6. Keep storage under control

• Time Travel by data type: 1 day (or none) for staging and derived data that is rebuilt; more only where there is a recovery requirement.
• Transient tables for staging and intermediates: they have no Fail-safe and save the 7 extra days.
• Remove orphaned copies and clones and tables from closed projects. TABLE_STORAGE_METRICS shows how much of each table is Time Travel and Fail-safe.
• Move cold history to Iceberg or external tables in the lake. The per-TB price of standard cloud storage is similar to Snowflake's; the saving comes from not paying for Time Travel or Fail-safe and from being able to use the provider's cold storage tiers, and the data remains queryable.

7. Review the contract

• Move to Capacity when consumption is stable: the discount on the credit price is the highest-impact measure above a certain volume.
• Check that the edition matches the features actually used.
• Consider the region: credit and TB prices vary between European regions, and cross-region transfer is not free.

8. Make it a habit: FinOps for data

Technical measures unravel in six months if nobody sustains them. What works is simple: a cost owner per data domain, a dashboard everyone sees, a monthly review of the most expensive queries and warehouses, alerts that reach someone who can act, and cost per report or per process as one more KPI for the data team. It is the same logic we apply in data governance: owners, metrics and recorded decisions.

A 30-day plan

1. Week 1. Measure. Cost dashboard per warehouse, query and team from ACCOUNT_USAGE; tags on warehouses and query tags in tools.
2. Week 2. Quick wins. Auto-suspend at 60 seconds, one size down on warehouses with no spilling or queueing, resource monitors on development and test, per-query timeouts.
3. Week 3. Queries. Review and rewrite the 20 most expensive queries; adjust pipeline frequencies; disable unused serverless features.
4. Week 4. Governance. Budgets per domain, permissions on warehouses, Time Travel and transient tables in staging, contract review and a monthly review calendar.

At Bidatia we design and operate data platforms on Snowflake, Microsoft Fabric and Databricks, and one of the first things we do when we take over an existing account is exactly this plan: measure, fix the obvious and leave behind a control system the team can maintain. If you would like us to review your account, let's talk.