[On-demand Webinar] How to Right-Size Snowflake Warehouses: Vertical Scaling & Gen 2 Strategies

We move beyond arbitrary default settings to explore how data-driven resource allocation can align your warehouse spend with your company’s Service Level Objectives (SLOs).

 

The End of “Trial and Error” in Snowflake Warehouse Right Sizing

Most Snowflake teams size warehouses the same way: start with defaults, wait for complaints, then bump the size when queries slow down. While this approach feels pragmatic, it is fundamentally arbitrary.

Snowflake exposes a wide range of tunable parameters—warehouse size, concurrency, memory pressure, cache behavior—but human intuition is not well suited to reason about their combined effects. Two workloads that look identical at a high level can behave radically differently under the same configuration.

Instead of guessing, this session introduces a methodology that reconstructs your warehouse state from scratch. By replaying a real workload over a fixed time window, we simulate how each query behaves under different configurations. This allows teams to evaluate performance and cost outcomes before making any changes in production.

The Science of Vertical Scaling

A common misconception is that increasing warehouse size always increases cost. In reality, Snowflake query behavior is non-linear.

Heavy queries running on warehouses that are too small often cost more because they execute inefficiently. They suffer from low parallelism, excessive queuing, and memory pressure that forces data out of RAM. As a result, these queries run longer, consume more credits, and delay everything behind them.

Vertical scaling works when it moves a workload into its efficiency zone—the point where queries complete faster, use memory effectively, and reduce total warehouse uptime. Effective Snowflake warehouse right sizing is about finding this non-linear “sweet spot,” not minimizing size at all costs.

The session walks through how to identify that point by analyzing how performance changes as resources scale, and where additional capacity stops producing meaningful gains.

The Five Metrics That Actually Matter

Correct vertical scaling decisions rely on a small set of concrete metrics pulled directly from Snowflake telemetry. In this session, we focus on five:

• Warehouse Size – The compute and memory resources allocated

• Query Load Percentage – How much of the warehouse is actually utilized

• Bytes Scanned – A critical proxy for memory pressure

• Spillage – When queries exceed available RAM and spill to disk

• Query Duration – The final driver of cost

Rather than evaluating these metrics in isolation, we show how to interpret them together. For example, bytes scanned on its own is not a cost metric—but when mapped to available RAM, it becomes a predictor of spillage and runaway runtimes.

Mastering Spillage: RAM vs. SSD Is Not a Small Difference

Spillage is one of the most misunderstood performance killers in Snowflake.

When a query runs out of memory, Snowflake must move intermediate data from RAM to local disk or remote storage. The performance difference between these tiers is enormous—moving from cache to RAM to SSD can mean the difference between minutes, hours, or even days of runtime.

This session explains how to translate bytes scanned into RAM pressure, and how to predict when a query will spill before it happens. By doing so, teams can determine whether scaling up memory is cost-effective or whether the workload is fundamentally disk-bound.

Understanding this boundary is critical to making rational scaling decisions.

Gen 1 vs. Gen 2: A Decision Matrix, Not a Default

Snowflake’s Gen 2 warehouses offer stronger processing power, faster memory I/O, and double the L2 cache—but they do not improve local disk speed. As a result, they are not a universal upgrade.

We present a clear decision matrix:

• Processing-heavy workloads benefit significantly from Gen 2

• Storage-heavy workloads rarely do, because disk remains the bottleneck

• Mixed workloads require a calculated ratio between in-memory processing and local disk I/O

Rather than treating Gen 2 as a blanket solution, this session shows how to evaluate whether your specific workload will actually see a performance-to-cost advantage.

Optimizing Warehouse Uptime, Not Just Queries

Snowflake charges for warehouse uptime, not individual queries. Optimizing a single query in isolation often produces misleading results.

In this session, we demonstrate how to reconstruct an entire workload timeline—looking at how queries overlap, queue, and compete for resources across time. By recalculating runtimes under different constraints, we can determine when scaling actions should occur.

This enables precise recommendations such as scaling to Extra-Large at 02:00 or switching to Gen 2 only for a specific batch window. Effective Snowflake warehouse right sizing comes from optimizing the full timeline, not chasing individual slow queries.

About the Methodology

Seemore Data replaces intuition with algorithmic precision. By calculating the ratio between processing performed in memory and I/O performed on local disk, we identify the exact tipping point where scaling up becomes cheaper than staying small.

This approach allows data teams to move from reactive tuning to engineered efficiency—making Snowflake performance and cost predictable rather than experimental.