Causes of Increased Snowflake Costs

Snowflake ACCOUNT_USAGE views can identify changes in warehouse, query, serverless, and storage consumption.

Increases can be traced to usage records in ACCOUNT_USAGE.

Idle warehouses

A warehouse consumes credits while it remains active, including periods without queries. Across thirty-odd starts a day, idle intervals can become a material part of consumption.

WAREHOUSE_METERING_HISTORY reports total compute credits, while QUERY_ATTRIBUTION_HISTORY reports credits assigned to queries. The difference approximates idle consumption for each warehouse.

Warehouse size

Each warehouse size doubles the credit rate. An X-Small burns 1 credit per hour, a Small 2, a Medium 4, a Large 8, and the progression continues for larger sizes. A Large warehouse used for one slow dashboard also charges 8 credits an hour for other workloads assigned to it.

Joining WAREHOUSE_METERING_HISTORY with warehouse size produces daily cost by warehouse. QUERY_HISTORY reports queue times and spill to local or remote storage. A warehouse with no queues or spilling may be oversized and can be tested at the next smaller size.

Scheduled job frequency

A job can change from hourly execution to every five minutes, a dbt model can add 40 downstream tables, or a BI tool can begin refreshing on every dashboard load. These changes increase compute without necessarily changing the underlying SQL.

QUERY_HISTORY can be grouped by QUERY_TYPE, WAREHOUSE_NAME, and query text hash over the last 60 days, then sorted by elapsed time and execution count. A statement that increased from 210 executions last month to 9,380 this month identifies a frequency change. Execution timing can distinguish interactive use from a scheduler.

Serverless and Cortex usage

Serverless features are billed separately from warehouses and do not appear in warehouse-only monitoring. Snowpipe, automatic clustering, materialized view maintenance, search optimization, and replication have separate metering views. Cortex AI functions bill by tokens processed, so an LLM function applied to millions of rows can materially increase spending.

METERING_DAILY_HISTORY reports credits by service type after the Cloud Services adjustment. Growth in a non-warehouse category can then be investigated through the feature-specific view.

Resume minimums and small queries

Snowflake bills compute per second with a 60-second minimum on every resume. A warehouse that repeatedly resumes for sub-second queries is billed for a full minute on each cold start. Thousands of one-second queries can therefore produce much more billed time than execution time.

QUERY_HISTORY can identify high execution counts with short runtimes. Consolidating this traffic on a warm warehouse can reduce repeated minimum charges.

Time Travel and Fail-safe storage

Storage is generally smaller than compute. Time Travel retains changed and deleted data for up to 90 days on Enterprise, and Fail-safe retains it for another 7 days. A table rewritten in full each day can therefore occupy several times its visible size. STORAGE_USAGE and TABLE_STORAGE_METRICS separate active, Time Travel, and Fail-safe bytes.

Cost ownership

Warehouses with generic names such as COMPUTE_WH and no object tags do not identify the responsible team. Tags on warehouses and databases can be joined from TAG_REFERENCES to metering views to associate changes with workloads.

Frequently asked questions

My query volume is flat, so why did the bill rise?Volume flat and cost up usually points to idle time or warehouse size rather than queries. A warehouse that was resized or left active longer costs more regardless of how many queries run. Check the idle-cost gap in WAREHOUSE_METERING_HISTORY first.

Which warehouse is driving the cost?Query WAREHOUSE_METERING_HISTORY grouped by WAREHOUSE_NAME over the last 30 days and sort by total credits. That ranks your warehouses by spend in one query:

-- 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;

Then split each one into idle credits and query-attributed credits to see whether the problem is the work or the waiting.

Do the ACCOUNT_USAGE numbers match what I am billed?They do not match exactly. WAREHOUSE_METERING_HISTORY does not reflect the cloud services adjustment, so it can read higher than what you pay. Use METERING_DAILY_HISTORY when you want the credits Snowflake billed.