Snowflake warehouse credit and resize calculator

Why a five second query costs a minute

Snowflake quotes warehouse rates per hour but meters them per second, and a running warehouse is charged for every second it is up, idle or not. There is one twist: each start or resume carries a 60 second minimum. Start a warehouse, run a query that finishes in five seconds, and let it suspend, and you are billed for the full minute. The five seconds of query work and the fifty-five seconds of nothing cost the same.

The tool splits the day's bill into real work and that overhead so you can see the ratio. With the defaults, a Medium warehouse running 100 five second queries a day spends 500 seconds of actual work and 5,500 seconds paying the minimum. Only 8 percent of the bill buys query time. The rest buys the right to have started the warehouse at all.

The usual advice is to shorten auto-suspend so the warehouse stops billing while idle. That helps, but it does not touch the minimum. Every time the warehouse goes cold and a query arrives, the clock restarts at sixty seconds. The workloads hit hardest are the ones people assume are cheap: scheduled dashboards, a handful of hourly jobs, anything with long gaps between queries and a low auto-suspend.

When queries arrive closer together than the auto-suspend window, the warehouse never suspends and the picture flips. There is one start for the day, so the minimum stops mattering, but the warehouse stays warm between queries and bills through the gaps. A warehouse that never suspends runs down the clock almost continuously, which is a different way to spend the same money.

Upsizing pays only past twice as fast

One size up doubles the credits per hour. So if a query runs twice as fast on the larger warehouse, it finishes in half the time at double the rate and the cost per query is unchanged. That break-even sits exactly at a 2x speedup, and it is the number Snowflake's own sizing guidance uses. Move up and run less than twice as fast, and the cost per query goes up.

Set the speedup input to your measured value and the tool compares the two costs. It also surfaces a trap the rule of thumb hides: when a query is short enough that the 60 second minimum binds at both sizes, doubling the rate doubles the cost for any speedup, because both warehouses are floored at the same sixty seconds. The floor has to fall away, roughly runtime above 120 seconds, before a speedup can repay the resize at all. Below that, upsizing a query the minimum already covers is a pure cost increase.

That is the case for measuring before you resize. The sizing post below walks through the decision, and the Gen2 piece covers how warehouse generations change the rate itself. Upsizing is a bet that the speedup clears 2x, and on short queries the minimum means the bet cannot pay at all.

Measuring the real number from ACCOUNT_USAGE

The numbers here come from a model, and your own account has the real ones. Query cost is not stored on the query row: SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY has runtimes and sizes, but no credits column, and credits_used_cloud_services is cloud services spend, not warehouse compute. Warehouse compute credits live in ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY, one row per warehouse per metering interval.

Attributing metering credits to individual queries is therefore an estimate, not a lookup. The common method is to share each metering interval's credits across the queries that ran in it, weighted by their elapsed time. That share ignores the 60 second floor and the idle tail, so it understates cheap, infrequent queries and overstates busy ones. Treat it as a ranking, then read the flat total from the metering table.

WITH q AS (
  SELECT warehouse_name,
         query_id,
         start_time,
         total_elapsed_time,
         DATE_TRUNC('hour', start_time) AS hour_bucket
  FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
  WHERE start_time >= DATEADD('day', -7, CURRENT_TIMESTAMP())
    AND warehouse_name IS NOT NULL
),
m AS (
  SELECT warehouse_name,
         DATE_TRUNC('hour', start_time) AS hour_bucket,
         SUM(credits_used) AS credits
  FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
  WHERE start_time >= DATEADD('day', -7, CURRENT_TIMESTAMP())
  GROUP BY 1, 2
),
share AS (
  SELECT warehouse_name,
         query_id,
         hour_bucket,
         total_elapsed_time,
         SUM(total_elapsed_time)
           OVER (PARTITION BY warehouse_name, hour_bucket) AS hour_elapsed
  FROM q
)
SELECT s.warehouse_name,
       COUNT(*) AS queries,
       SUM(m.credits * s.total_elapsed_time
           / NULLIF(s.hour_elapsed, 0)) AS attributed_credits
FROM share s
JOIN m
  ON m.warehouse_name = s.warehouse_name
 AND m.hour_bucket   = s.hour_bucket
GROUP BY 1
ORDER BY attributed_credits DESC;

A query that overlaps two metering intervals is credited entirely to the hour it started, and a query with total_elapsed_time of zero (a cache hit or a failed compile) still counts as a row but shares no weight. Swap the seven day filter for a week and split by warehouse_size to see the same workload at two sizes, which is the measurement the resize question actually needs. ACCOUNT_USAGE lags by up to 45 minutes and needs a role that can read the views.

For the sizing decision itself, read stop paying for idle compute, which covers why the warehouse size is a cost setting before it is a performance one. The credit controls that catch runaway spend are in Snowflake FinOps: credits, warehouses and the cost controls that work, and the generation that changes the rate is in Gen2 warehouses. The rates themselves are on the Snowflake pages for understanding compute cost and sizing a warehouse for performance.