Why Your Snowflake Bill Jumped

A Snowflake bill that jumps overnight rarely comes from one big query. More often a warehouse stayed running while statements waited to compile or trickled in.

Book a Call

The short answer

A Snowflake bill usually jumps because a warehouse stayed running, not because a query scanned a lot of data. Statements stuck in compile, or a steady trickle of small queries, keep auto-suspend from firing, and compile time climbs steeply when many statements compile at once. Split compile and execute time by warehouse first, then flatten heavy queries, throttle fan-out, and move automated work to its own warehouse.

Sound familiar?

  • A small warehouse used many times its normal daily credits.
  • No query ran for long, and bytes scanned were trivial.
  • Auto-suspend is set to 60 seconds, but the warehouse stayed up for hours.
  • An automated tool or agent started sending many queries at once.

Why it happens

Deep query plans take long to compile
A statement with dozens of chained CTEs gives the optimizer a big plan to build. In one case, a query with 41 chained CTEs compiled in 31 seconds and executed in 1 to 4 seconds against 51 MB.
Concurrency multiplies compile time
Compilation runs in Snowflake's shared cloud services layer and slows badly when many statements compile at once. The same statement went from 33 seconds with under 10 concurrent statements to 744 seconds at 160 and up.
Auto-suspend never gets an idle minute
Auto-suspend counts from the last statement finishing. Four parallel processes sending about 400 small queries over six hours kept an X-Small awake the whole time, with nothing individually slow.

How we fix it

  1. 1

    Split compile and execute time by warehouse

    Query QUERY_HISTORY for compile seconds, execute seconds, and worst single compile per warehouse, and pair it with WAREHOUSE_METERING_HISTORY for credits. Read the query text of the worst compilers before deciding anything runs on the wrong warehouse.

  2. 2

    Fix the cause, in order

    Flatten the heavy query by materializing the middle of the CTE chain. Throttle or batch tools that validate with many parallel SELECTs or EXPLAINs. Move automated validation to its own small warehouse with a 60-second auto-suspend.

  3. 3

    Add guardrails before the next spike

    Attach resource monitors that warn at 50, 75, and 90 percent and suspend at 100. Give AI and analyst queries their own warehouse with a statement timeout, and use budgets for serverless features and AI services that resource monitors do not track.

What you end up with

  • A compile versus execute breakdown by warehouse
  • Named causes for the spike, with the query text behind them
  • Separate warehouses for automated and AI workloads
  • Resource monitors and budgets with alerts

Common questions

Why didn't auto-suspend stop the warehouse?

Auto-suspend counts from the last statement finishing, so a statement sitting in compile, or a steady trickle of small queries, keeps the warehouse from ever being idle. Auto-suspend was working; the warehouse never had an idle minute.

Does moving queries to a separate warehouse fix slow compiles?

Not on its own. A separate warehouse isolates warehouse uptime, not cloud services compilation, so heavy compiles still slow each other down. It does stop automated work from holding the production warehouse open, and shows what that work costs.

Should auto-suspend be shorter than 60 seconds?

No. Snowflake bills a 60-second minimum each time a warehouse resumes, so a shorter setting buys nothing.

Do resource monitors cover AI and serverless costs?

No. Resource monitors track warehouses. Snowflake points to budgets for serverless features and AI services, so set up both.

Bring the numbers that don't add up

We'll trace them to the source with you and say where we'd start. No pitch deck.

Book a Call