# snowflake_wh_remote_spillage

> Remote spill exceeding 1 GiB at the 95th percentile across 14 days signals working sets overflowing the warehouse's memory and local disk into slow object storage. Spilling queries stretch, and stretched queries bill more credit-seconds. Sizing up one step, despite doubling the hourly rate, often nets out cheaper.

Source: https://zop.dev/integrations/snowflake/recommendations/snowflake-wh-remote-spillage
Updated: 2026-08-19

---

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

```sql
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.