Snowflake costs can scale unexpectedly if warehouse sizing, auto-suspend, query patterns, and storage are not actively managed. This guide covers the primary cost levers and the monitoring approach that keeps Snowflake spend predictable.
Snowflake costs can scale unexpectedly. Organisations regularly receive Snowflake invoices 2–3x higher than anticipated — not because of platform flaws, but because of unmanaged warehouse configurations, runaway queries, and unmonitored storage growth. This guide covers the primary cost drivers and the management approach that keeps Snowflake spend predictable.
Snowflake's cost model
Snowflake charges for three distinct things:
**Compute (virtual warehouse credits)**: The primary cost driver. Charged per second while a virtual warehouse is running — a credit per second per cluster, with XS warehouses consuming 1 credit/hour and each size tier doubling consumption. A Large warehouse (8 credits/hour) running 10 hours per day costs 80 credits/day. At $3/credit on Business Critical tier, that is $240/day from one warehouse.
**Storage**: Charged per TB per month — approximately $23/TB for on-demand, $40/TB for Snowflake-managed compression. Storage is typically a small fraction of total cost for analytical workloads, but it grows linearly with data volume and time travel retention settings.
**Cloud services**: Metadata operations, query compilation, authentication, and other background operations are charged when they exceed 10% of daily compute credits (which is uncommon for typical workloads).
Compute is almost always the dominant cost. Storage and cloud services are secondary.
The auto-suspend configuration
The most impactful cost control setting is auto-suspend — the number of seconds of inactivity after which a warehouse is automatically paused. When paused, no credits are consumed.
Default auto-suspend is 10 minutes (600 seconds). A warehouse that runs one query per hour sits idle for 50 minutes per hour. With 10-minute auto-suspend, it runs for 1 minute (query) + 10 minutes (idle before suspend) = 11 minutes of credit consumption per hour. Without auto-suspend, it runs 60 minutes/hour — a 5.5x cost difference.
Configure auto-suspend aggressively:
- Interactive/ad-hoc query warehouses: 60 seconds (queries are infrequent)
- BI tool warehouses: 5 minutes (users typically run several queries in succession)
- ETL/pipeline warehouses: 60 seconds if jobs are discrete; longer if pipelines run continuously
Auto-resume is instantaneous from the user's perspective — a query against a suspended warehouse resumes it in under 3 seconds. The cold-start penalty is negligible for most workloads.
Warehouse sizing
Every warehouse size increase doubles credit consumption. A Medium warehouse is 2x the cost of an XS warehouse per hour. Oversized warehouses are one of the most common Snowflake cost problems.
The correct sizing approach: start at XS and increase size only if query performance is inadequate. For most analytical queries against a well-designed schema, XS or Small handles interactive loads. Large warehouses are appropriate for complex multi-join queries across large datasets, not for routine dashboard queries.
**Resource monitors**: Snowflake Resource Monitors set credit consumption alerts and limits at the account or warehouse level. Configure a monthly credit quota for each warehouse. When consumption reaches 75% of the quota, trigger a notification. When it reaches 100%, suspend the warehouse (preventing runaway spend). Resource monitors do not prevent work — they trigger review at thresholds you define.
**Warehouse per workload**: Create separate warehouses for different workload types — a BI tool warehouse (small, frequent queries, short auto-suspend), an ETL warehouse (larger, batch jobs, auto-suspend at job completion), and an ad-hoc query warehouse (interactive, variable size, aggressive auto-suspend). This prevents batch ETL loads from competing with interactive queries and enables accurate cost attribution per workload.
Query cost analysis
SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY (or INFORMATION_SCHEMA.QUERY_HISTORY for the last 7 days) contains every query executed, with bytes scanned, compilation time, execution time, and credits used. Regularly reviewing the highest-cost queries reveals optimisation opportunities.
Queries to look for:
- Queries with very high bytes scanned against large tables without partition filters — missing WHERE clauses on clustered keys
- Queries with long compilation time — overly complex SQL or missing statistics
- Queries from BI tools that run the same query repeatedly without result caching — investigate whether warehouse result cache is working or being bypassed
- Ad-hoc queries from analytics tools without query limits
Snowflake's result cache automatically caches query results for 24 hours. Identical queries from any user hitting the same result set are served from cache — zero compute cost. BI tools that parameterise queries with timestamps (SELECT ... WHERE event_time > CURRENT_TIMESTAMP - INTERVAL 30 DAYS) bypass cache because each run generates a slightly different query. Rewrite parameterised filters to use fixed date boundaries where possible.
Storage cost control
**Time travel retention**: Snowflake's time travel feature retains historical table states for querying with FOR SYSTEM_TIME AS OF syntax. The default retention period is 1 day for Standard edition, up to 90 days for Enterprise. Storage for time travel data counts toward billing. For large, frequently-modified tables, 90-day time travel stores up to 90x the table's size in time travel blocks.
Set time travel retention to the minimum required for your use case. For most tables, 7 days is sufficient. For compliance or audit-sensitive tables where historical state queries are required, set longer retention explicitly rather than globally.
**Fail-safe storage**: Snowflake stores an additional 7 days of fail-safe data (used by Snowflake support for disaster recovery). This is not configurable and always consumes storage.
**Transient and temporary tables**: Transient tables have a maximum 1-day time travel period and no fail-safe period. Use transient tables for intermediate ETL staging tables, work tables, and any table where historical state is not needed. The storage cost savings over the ETL lifecycle can be significant.
Monitoring dashboards
Build a Snowflake cost monitoring dashboard from SNOWFLAKE.ACCOUNT_USAGE views. Key metrics to track:
- Daily credit consumption by warehouse (trend over time, compare to baseline)
- Credit consumption by user for ad-hoc query warehouses (identify high-consume users)
- Storage growth rate by database (project storage costs forward)
- Query credit distribution (top N queries by credit consumption)
- Cache hit rate for each warehouse (low cache hit rate on a BI warehouse indicates missed optimisation)
Review this dashboard weekly. Cost spikes are much easier to investigate when caught within days, not at month-end.
For the broader Snowflake architecture context, see snowflake architecture guide and snowflake pricing guide. Our cloud engineering practice audits and optimises Snowflake environments — book a free cost review if your Snowflake spend is higher than expected.
A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.
Book a Call →