Warehouses spilling over 1 GiB to remote storage are undersized for their workload

The rule that recommends a bigger bill per hour

Most rightsizing findings point down. This one points up, and the arithmetic still favors you: Snowflake bills credits per second of runtime, so a query that runs 4 times faster on a warehouse charging 2 times the rate costs half as much. Sustained remote spillage is the clearest signal that faster is available: the workload is doing its sorting and joining through object-storage round-trips instead of memory, and paying for every stretched second.

Memory, then local disk, then the network

When an operation outgrows warehouse memory, Snowflake spills first to the node’s local SSD, a tolerable slowdown. When even local disk overflows, intermediate results go to remote object storage, orders of magnitude slower per access. bytes_spilled_to_remote_ storage in QUERY_HISTORY records that second, expensive tier, and it is the only tier this rule reads: local spill alone never triggers it.

The p95 gate

Hourly buckets of remote-spill bytes are rolled up from QUERY_HISTORY per warehouse; the rule fires when the 95th percentile across 14 days exceeds 1,073,741,824 bytes, or 1 GiB. The percentile matters: one monster backfill query does not fire the rule, a recurring pattern of heavy spill does. The threshold is deliberately the mirror image of the downsize rule’s safety gate, which requires spill below 1 MiB before calling a warehouse oversized.

Find the queries doing the spilling

SELECT query_id, warehouse_name,
       bytes_spilled_to_remote_storage / POWER(1024, 3) AS spilled_gib,
       total_elapsed_time / 1000 AS elapsed_s
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE start_time >= DATEADD('day', -14, CURRENT_TIMESTAMP())
  AND bytes_spilled_to_remote_storage > 0
ORDER BY bytes_spilled_to_remote_storage DESC
LIMIT 50;

QUERY_HISTORY lags up to 45 minutes, immaterial over a two-week view.

Before you resize

Check whether the top of that list is a handful of rewritable queries (an exploding join, an unbounded ORDER BY feeding a window function), because fixing two queries is cheaper than upsizing a warehouse for everyone. If the spill is broad-based, take the one-step resize: Medium to Large moves the rate from 4 to 8 credits per hour and, on memory-bound workloads, routinely cuts runtimes by more than the rate increase. Then re-run the query above; spill should collapse toward zero, and if it does not, the bottleneck was not memory.