Snowflake Pricing: How It Works and How to Control Your Costs

The quick answer

Snowflake pricing is based on compute credits and storage. You pay for the virtual warehouse compute you use (by the second when it is running) and the storage your data occupies (compressed). Data transfer out of Snowflake adds a third cost component. There is no fixed monthly fee for a Snowflake deployment — costs scale with usage.

The implication: Snowflake costs are entirely under your control, but only if you actively manage them. Warehouses that do not auto-suspend, queries that scan more data than necessary, and storage that accumulates without governance are the three primary sources of unexpected Snowflake cost growth. This guide explains how pricing works and what controls make costs predictable.

How Snowflake credits work

Snowflake bills compute in **credits**. One credit per hour per cluster of compute (one node). The price per credit depends on your Snowflake edition and cloud region:

- Standard edition: approximately $2–$3 per credit (US regions)

- Enterprise edition: approximately $3–$4 per credit (US regions)

- Business Critical edition: approximately $4–$6 per credit (US regions)

Regional pricing varies. Azure and GCP regions may differ from AWS pricing. Actual prices are governed by your Snowflake contract; on-demand pricing is significantly higher than committed contract pricing.

A small (X-Small) warehouse uses 1 credit per hour. Each size tier doubles the credit consumption: X-Small (1), Small (2), Medium (4), Large (8), X-Large (16), 2X-Large (32), 3X-Large (64), 4X-Large (128). Larger warehouses execute single queries faster but cost more per hour — the right size depends on your query patterns.

Warehouses are billed by the second with a **minimum of 60 seconds per start**. A query that takes 5 seconds still charges for 60 seconds of warehouse time. For high-frequency, short queries, this minimum has cost implications — multi-cluster warehouses and query queueing can be more economical than starting many small warehouses for individual queries.

Virtual warehouse sizing

**Auto-suspend** is the most important cost control: configure every warehouse to auto-suspend after a period of inactivity. The default should be 1–5 minutes for most workloads. A warehouse that is left running overnight when no queries are executing wastes money at the rate of its hourly credit consumption.

**Auto-resume** allows Snowflake to start a suspended warehouse automatically when a query arrives. For most analytics workloads, the cold-start latency (a few seconds) is acceptable and auto-resume should always be enabled alongside auto-suspend.

**Warehouse sizing** should match the workload. For ad-hoc queries by individual analysts, an X-Small or Small warehouse is appropriate — larger warehouses add cost without proportional benefit for simple queries. For heavy transformation workloads (dbt runs, large aggregations), a larger warehouse (Medium to Large) reduces execution time but increases cost per run.

The correct question is not "which size runs my queries fastest?" but "which size minimises total cost for my performance requirements?" A Large warehouse that runs a dbt job in 10 minutes may cost the same as a Medium warehouse that runs the same job in 18 minutes — same total credits, different run time. For time-sensitive refreshes, the larger warehouse is worth it; for batch jobs with flexible windows, the smaller warehouse reduces peak cost.

**Multi-cluster warehouses** scale out horizontally (add cluster nodes) when query concurrency is high. They prevent query queueing when many concurrent users hit the same warehouse. Multi-cluster adds cost during peak periods but prevents the performance degradation that forces warehouse size increases to compensate for concurrency. For BI tools with many concurrent dashboard users, multi-cluster warehouses are often more economical than oversizing a single-cluster warehouse.

**Separate warehouses by workload type.** A common pattern: one warehouse for scheduled dbt transformation jobs, one for interactive analytics queries, one for data loading. This allows different auto-suspend settings per workload (dbt warehouses can suspend immediately after a job completes; analytics warehouses might stay warm for 5–10 minutes) and prevents one workload's resource consumption from impacting others.

Storage pricing

Snowflake storage is priced per TB per month of compressed storage used. Pricing varies by region and edition: approximately $23–$40 per TB/month on a capacity contract, higher for on-demand.

Storage accumulates from: current table data, **Time Travel** data (historical data retained for 0–90 days depending on edition), and **Fail-safe** data (7 days of data retained by Snowflake for disaster recovery, not modifiable by users).

**Time Travel** is Snowflake's ability to query historical data states (SELECT * FROM my_table AT (OFFSET => -3600) queries the table as it was one hour ago). Time Travel data adds to storage cost. The default retention period is 1 day for Standard edition and up to 90 days for Enterprise. For large tables, a long Time Travel retention significantly increases storage cost. Set Time Travel retention to the minimum appropriate for your recovery requirements — most organisations need 7–14 days for large tables, not 90.

**Table clustering** — if tables are clustered on specific columns for query performance — adds **clustering maintenance cost** from the background re-clustering service. Clustering is valuable for large tables with selective filter predicates on a specific column, but the maintenance credits can be significant for very large tables. Monitor clustering credits separately.

**Zero-copy cloning** creates table and database clones without copying data — only new or modified data creates new storage. Useful for development and testing environments (clone production to dev without duplicating storage cost). Clones accumulate storage over time as they diverge from the source.

Query cost optimisation

Snowflake bills for compute time, so queries that run longer or scan more data cost more (because they use the warehouse for longer). Key query optimisations:

**Avoid SELECT ***: Snowflake's columnar storage reads only the columns referenced in a query. SELECT * on a wide table reads all columns even if only a few are needed. Always SELECT only the columns needed.

**Use clustering keys on large tables**: For tables frequently filtered by a specific column (date, region, customer_id), clustering reduces the micro-partitions scanned per query. Less scanning = faster query = shorter warehouse runtime = lower cost. For tables under 100GB, clustering adds cost without meaningful benefit — only cluster large, frequently-queried tables.

**Materialise intermediate results**: If multiple queries repeatedly scan and join the same large tables, materialising the intermediate result as a new table (or a Snowflake dynamic table) reduces redundant scanning. The storage cost of the materialised table is often lower than the repeated compute cost of the underlying scans.

**Avoid unnecessary DISTINCT**: DISTINCT forces a full scan and deduplication. If your data model guarantees uniqueness, drop the DISTINCT. If it does not, address the upstream data quality issue rather than papering over it with DISTINCT everywhere.

**Partition filter pushdown**: Snowflake's micro-partition pruning works when filter predicates reference the partition structure. If a table is clustered on DATE, a WHERE clause that filters on DATE prunes micro-partitions efficiently. Queries that cannot filter on clustering keys scan the full table.

Monitoring and governance

**Snowflake Resource Monitors** are the primary cost governance control. A resource monitor sets a credit limit for a warehouse or an account over a defined period (daily, weekly, monthly). When the limit is reached, the monitor can notify, suspend the warehouse, or suspend and notify. Every production warehouse should have a resource monitor.

**Account Usage views** in the SNOWFLAKE.ACCOUNT_USAGE schema provide detailed query history, warehouse metering, storage usage, and data transfer metrics. Key views: QUERY_HISTORY (query-level cost attribution), WAREHOUSE_METERING_HISTORY (warehouse-level credits by hour), STORAGE_USAGE (daily storage), TABLE_STORAGE_METRICS (per-table storage including Time Travel and Fail-safe).

Regular cost attribution queries — crediting compute cost back to the team, project, or workload that generated it — are the foundation of Snowflake cost governance. Without attribution, there is no accountability; without accountability, costs grow without visibility.

**Snowflake Budgets** (Enterprise and above) allow budget monitoring at the organisation, account, or custom resource group level, with alerts via email or Slack when budget thresholds are approached.

Snowflake pricing tiers: Standard vs Enterprise vs Business Critical

**Standard** — base DML, DDL, Time Travel (1 day), Fail-safe, basic security. Appropriate for most mid-market analytics workloads. Limited to 90-day Time Travel; no multi-cluster warehouses at the Standard tier in some configurations. Confirm your exact entitlements with Snowflake.

**Enterprise** — adds multi-cluster warehouses, up to 90-day Time Travel, materialized view maintenance, column-level security, dynamic data masking, and higher concurrency. The right tier for most production enterprise analytics environments where multi-cluster concurrency or data masking is required.

**Business Critical** — adds enhanced security (HIPAA, PCI-DSS, FedRAMP), Tri-Secret Secure (customer-managed keys), database failover/failback, and private connectivity with higher SLAs. Required for organisations in regulated industries with strict data residency or security requirements.

On-demand vs contract pricing

Snowflake on-demand pricing is pay-as-you-go with no commitment. Credits are more expensive than on contract: roughly 2–3× the contracted rate depending on edition.

Snowflake capacity contracts (pre-purchased credits) provide significant discounts over on-demand at the cost of commitment. If your Snowflake usage is consistent and predictable, a capacity contract reduces unit cost substantially. The risk: unused pre-purchased credits are lost at the contract end.

For organisations with variable or growing usage, on-demand pricing plus careful cost controls is often the right starting point. As usage stabilises and consumption becomes predictable, contract pricing provides material savings.

Frequently asked questions

Our Snowflake bill is higher than expected. What is usually the cause?

The three most common causes: warehouses not auto-suspending (leaving compute running overnight or over weekends), large dbt transformation jobs using oversized warehouses, and storage growth from long Time Travel retention on large tables. Start with WAREHOUSE_METERING_HISTORY to identify the highest-credit warehouses and check their auto-suspend settings. Then check TABLE_STORAGE_METRICS for tables with disproportionate Time Travel storage.

Should we use Snowflake serverless features or virtual warehouses?

Snowflake serverless compute (used for background services like automatic clustering, materialized view refresh, and Snowpipe) uses credits separately from virtual warehouses. For workloads with highly variable query volumes, serverless features can be more economical — but costs can be opaque. For predictable analytics workloads, virtual warehouses with resource monitors are easier to govern.

How do we allocate Snowflake costs to teams?

Create separate warehouses per team or workload type and use WAREHOUSE_METERING_HISTORY to attribute credits by warehouse. Apply warehouse naming conventions that map to teams or projects. For more granular attribution, query-level cost attribution via QUERY_HISTORY and tag-based cost allocation (Snowflake Enterprise) provide finer granularity.

For Snowflake architecture design, cost governance, and cloud data platform builds on Azure, AWS, or GCP, our cloud engineering practice handles this work daily. If your Snowflake costs are growing faster than expected or you are designing a new Snowflake environment, book a free 30-minute audit and we will identify the specific controls your environment needs.

A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.