Snowflake Auto Suspend: How to Balance Idle Cost and Warehouse Cache

Snowflake recommends a low auto suspend value, typically 5 or 10 minutes or less, matched to the gaps in your query workload. Its documentation also flags the trade-off: the warehouse cache is dropped on suspend.

Some guidance pushes the value much lower, to 10, 30, or 60 seconds. For workloads that re-read the same data every few minutes, intervals that short can cost more than they save.

What Snowflake Gives You

Every warehouse has an AUTO_SUSPEND setting, in seconds. The default is 600 (10 minutes). Snowflake bills a 60-second minimum each time a warehouse resumes, then per second after that.

Snowflake’s warehouse guidance is to set auto suspend low and match it to your workload’s gaps. It also points out that the local cache is dropped when a warehouse suspends, so you’re weighing saved credits against slower queries right after resume.

Here’s how to see where each warehouse stands:

-- Current setting per warehouse (auto_suspend column is in seconds) SHOW WAREHOUSES;  -- How much of each warehouse's scanning came from cache (last 7 days) SELECT   warehouse_name,   COUNT(*)                                     AS queries,   ROUND(AVG(percentage_scanned_from_cache), 2) AS avg_pct_scanned_from_cache FROM snowflake.account_usage.query_history WHERE start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())   AND warehouse_name IS NOT NULL   AND bytes_scanned > 0 GROUP BY warehouse_name ORDER BY avg_pct_scanned_from_cache ASC;  -- Adjust once you know the query cadence ALTER WAREHOUSE my_wh SET AUTO_SUSPEND = 300;

A warehouse with a very short suspend setting and a low cache percentage is the first place to look.

Why Short Auto Suspend Intervals Can Backfire

At first glance, shorter intervals look like the obvious way to cut idle cost.

But short intervals drop the warehouse cache more often, so the next query reads from remote storage instead of local SSD. Those reads are slower, and the extra runtime is billed warehouse time.

What a Cache Miss Costs

For workloads that re-read the same tables within minutes, aggressive suspension can cost more in extra runtime than it saves in idle time.

For workloads with long, unpredictable gaps, a short interval is usually the right call.

Why One Interval Rarely Fits the Whole Day

Snowflake’s guidance is to match auto suspend to the gaps in your workload. The challenge is that those gaps move.

Business-hours BI, batch windows, and overnight jobs each have a different rhythm. One fixed value has to compromise across all of them.

How Keebo Adjusts Auto Suspend Dynamically

Keebo’s patented AI algorithm continuously calculates the auto suspend interval for each warehouse based on real-time query data, balancing cost and performance.

The screenshot below shows Keebo adjusting this in real time. In this example, Keebo determined that at 6:10 AM the right time to suspend this warehouse was after 251 seconds. Later, as the load changed, it reduced the auto suspend value sharply.

Illustrative Example: Comparing Auto Suspend Strategies

Let’s assume three queries, Q1, Q2, and Q3, arrive at 9:00 AM, 9:03 AM, and 9:10 AM. For illustration, each query takes 1 minute if its data is already in the warehouse’s local cache and 4 minutes if it has to read from remote storage. (These runtimes are illustrative, not measured.)

Scenario 1: Fixed 5-Minute Interval

Q1 arrives at 9:00 AM and finishes at 9:01 AM (cached). The warehouse stays active for 5 minutes.

Q2 arrives at 9:03 AM, hits an active warehouse, and finishes at 9:04 AM (cached). The warehouse stays active until 9:09 AM.

Q3 arrives at 9:10 AM, hits a suspended warehouse, and finishes at 9:14 AM (cache miss). The warehouse stays active until 9:19 AM.

• Total cost: 18 minutes (9:00 to 9:09 and 9:10 to 9:19)
• Cache misses: 1 (Q3)
• Avg execution time: (1+1+4)/3 = 2.0 min/query

Scenario 2: Fixed 1-Minute Interval

Q1 arrives at 9:00 AM and finishes at 9:01 AM. The warehouse suspends at 9:02 AM.

Q2 arrives at 9:03 AM, hits a suspended warehouse, and finishes at 9:07 AM (cache miss). The warehouse suspends at 9:08 AM.

Q3 arrives at 9:10 AM, hits a suspended warehouse, and finishes at 9:14 AM (cache miss). The warehouse suspends at 9:15 AM.

• Total cost: 12 minutes (9:00 to 9:02, 9:03 to 9:08, and 9:10 to 9:15)
• Cache misses: 2 (Q2, Q3)
• Avg execution time: (1+4+4)/3 = 3.0 min/query

Scenario 3: Keebo Dynamic Optimization

Q1 arrives at 9:00 AM and finishes at 9:01 AM (cached). Keebo predicts the warehouse should stay active until shortly after 9:03 AM.

Q2 arrives at 9:03 AM, hits an active warehouse, and finishes at 9:04 AM (cached). Keebo suspends the warehouse right away.

Q3 arrives at 9:10 AM, hits a suspended warehouse, and finishes at 9:14 AM (cache miss). Keebo suspends right afterward.

• Total cost: 8 minutes (9:00 to 9:04 and 9:10 to 9:14)
• Cache misses: 1 (Q3)
• Avg execution time: (1+1+4)/3 = 2.0 min/query

Summary

The picture below compares the three scenarios.

The table summarizes cost (minutes the warehouse is running or idle) and performance (queries that hit a suspended warehouse and missed the cache, plus average execution time).

Scenario	Total Cost (minutes)	# Cache Misses (Queries)	Avg Execution Time (minutes/query)
Fixed 5-Minute Interval	18	1 (Q3)	2.0
Fixed 1-Minute Interval	12	2 (Q2, Q3)	3.0
Keebo Dynamic Optimization	8	1 (Q3)	2.0

In this example, the dynamic approach matches the 5-minute interval on performance and uses fewer warehouse minutes than either fixed value. It also shows how a very low value all day (Scenario 2) can cost more than a dynamic approach and run slower.

That result depends on predicting arrivals well. When a prediction misses, the cost is the same as a static setting that guessed wrong: some idle time or one extra cache miss.

This is a contrived example. The point is to show why no single static value, large or small, fits a workload whose gaps change through the day. Keebo learns those gaps from historical query arrival patterns and real-time concurrency, then sets the interval for each warehouse as the pattern shifts.

Case Study: FinTech Company Cuts Compute Costs 38% With Keebo Auto Suspend

The Challenge

A global FinTech firm runs large-scale analytics and compliance workloads on Snowflake.

The team had set auto suspend to 30 seconds to minimize idle cost. With queries arriving every few minutes, warehouses cycled between suspend and resume, dropped their cache, and re-read data from remote storage. Query latency rose, and so did credit consumption.

The Keebo Solution

The company replaced fixed suspend settings with Keebo’s continuous, workload-aware adjustments. Keebo analyzed historical query arrival patterns and real-time concurrency to set the suspend interval for each warehouse at every hour of the day.

Within days, Keebo found that the right suspend window moved between 120 seconds during business hours and 300 seconds overnight, and it adjusted as traffic changed. Both values sit inside Snowflake’s own recommendation of 10 minutes or less.

The Results

• 38% reduction in total Snowflake compute costs within the first month
• 24% improvement in average query latency, from fewer cache misses
• No manual tuning. Keebo adjusted suspend intervals autonomously.

FAQs

What Is Snowflake Auto Suspend and Why Is It Important?

Snowflake auto suspend automatically suspends a warehouse after a period of inactivity. It reduces idle compute cost, but it needs tuning to your workload because suspending drops the warehouse cache.

Why Can Very Short Auto Suspend Intervals Backfire?

Very short intervals drop the cache more often, so queries read from remote storage instead of local cache. That increases query runtime, and the extra runtime can outweigh the idle minutes saved.

How Does Dynamic Auto Suspend Differ From Static Intervals?

Dynamic auto suspend, like Keebo’s approach, adjusts the interval continuously based on real-time query patterns and workload activity. A static interval stays the same as the workload changes.

What Costs Come With Frequent Warehouse Suspensions?

Frequent suspensions lead to cache misses and longer query runtimes. That extra runtime can offset the idle time saved.