A 4X-Large warehouse consumes 128 credits for every hour it remains provisioned, including periods without queries. Snowflake charges credits per second with a 60-second minimum on each start. Warehouse size and idle time account for much of the excess compute cost in accounts spending six or seven figures a year.
A warehouse continues to consume credits while active, including the intervals between queries. Snowflake's 60-second minimum and local data cache make repeated stop-and-start cycles more expensive for some workloads. WAREHOUSE_METERING_HISTORY reports credits per warehouse per hour and identifies consumption outside working hours:
-- warehouses ranked by credits, last 30 days
select warehouse_name, sum(credits_used) as credits
from snowflake.account_usage.warehouse_metering_history
where start_time >= dateadd('day', -30, current_date)
group by warehouse_name
order by credits desc;
Snowflake warehouse sizes follow a geometric scale. An X-Small bills 1 credit per hour, and each step up roughly doubles compute and credit consumption, reaching 128 credits per hour for a 4X-Large. Small queries may not use the additional capacity of a Large or X-Large warehouse. Testing a representative query across sizes identifies the smallest option that meets the latency requirement. Because billing is per second, a warehouse twice the size can remain cost-neutral if it halves runtime.
When ETL, ad hoc analysis, and BI dashboards share a warehouse, its size must accommodate the heaviest job. Separate warehouses allow independent sizing and suspend schedules. A nightly transform can use a large warehouse for 18 minutes, while a BI warehouse remains small during business hours. This structure also attributes spending by workload.
Resource monitors compare credit consumption with a quota and can issue notifications or suspend warehouses at defined thresholds. They do not reduce usage directly, but can identify a five-figure overrun on day three of the month. Monitors can be configured for individual high-consumption warehouses and at the account level.
Compute consumption increases with the amount of data scanned. Filters on clustered or naturally ordered columns allow Snowflake to prune micro-partitions, and sargable predicates avoid functions that force full scans. Selecting required columns rather than SELECT * reduces reads from columnar storage. QUERY_HISTORY reports bytes and partitions scanned for each query.
The 60-second minimum remains relevant when these queries repeatedly resume a suspended warehouse.
An aggregation that runs hundreds of times a day can be precomputed with a materialized view or dynamic table. Both add storage and background refresh compute. They reduce total cost when queries are expensive and frequent while source data changes slowly; frequent source changes can make refresh cost exceed the savings from reads.
Snowpipe, automatic clustering, search optimization, dynamic table refreshes, and Cortex AI functions have serverless meters separate from warehouses. They do not appear in WAREHOUSE_METERING_HISTORY and must be measured through the relevant service usage views.
QUERY_TAG can identify a team, job, or pipeline. Joining QUERY_HISTORY with metering views aggregates credits by tag and can show, for example, that one team's dbt run accounts for 31% of the bill.
For accounts spending under roughly $50K a year on Snowflake, manual optimization can cost more in engineering time than it saves. The work becomes more economical as spending increases.
How much can a Snowflake bill realistically come down?It depends on how tuned you already are. A team that has never addressed idle compute or warehouse sizing commonly finds 30% to 50% in idle and oversized warehouses alone, and query-level and precompute work adds more on top.
Can a bigger warehouse ever save money?Sometimes. Because billing runs per second, a warehouse twice the size that finishes a large query in half the time costs about the same, and it can win when it avoids queuing. It loses on small queries that leave the extra compute idle. Test it on your own queries rather than assuming either way.
Which views show the warehouses and queries that cost the most?Start with ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY for credits per warehouse over time, then ACCOUNT_USAGE.QUERY_HISTORY for bytes scanned, partitions scanned, and runtime per query. Those two cover most of the diagnosis.