Introducing Keebo Performance Guardrails: Protect Performance While Reducing Snowflake Spend

Handing over Snowflake cost optimizations to an AI can be scary. What if it slows down your application during peak user traffic? What if that slowdown violates an existing SLA? 

These concerns are valid. That’s why Keebo works to give our users as much control over their optimizations as possible. For a while, we’ve offered the ability to specify whether you want the AI to optimize for maximum savings, maximum performance, or to strike a healthy balance.

Now we’re going a step further. Keebo Performance Guardrails now enable you to specify the exact parameters—latency, queued time, or number of queued queries—used to define the performance benchmarks used in Snowflake cost optimizations.

Striking the cost savings vs. performance balance

Any time you reduce Snowflake spend, there’s a risk those cost savings come at the expense of performance. If you’re optimizing unutilized or underutilized warehouses, these hits are often negligible and don’t really impact your workloads more broadly.

But sometimes, your optimizations can impact critical warehouses and have a larger, negative impact. 

When users enable Keebo’s AI algorithm, they can save anywhere from 10 to 70% of their Snowflake spend. 

However, we wanted to give customers even more control to ensure both optimal cost optimization and performance. That’s why we’re launching automated performance guardrails. 

With guardrails in place, you can trigger your AI automations to “back off” when certain criteria are met. There are several ways to arrive at these criteria. The most common include: 

• Service-level agreements (SLAs) with clients or internal departments
• Historical performance data
• Industry best practices & benchmarks

What are Keebo Performance Guardrails?

Keebo Performance Guardrails is a new feature built to give Keebo customers more control as they balance cost optimizations and performance. We’ve created a specific way for users to control how their cost optimizations impact performance. 

When setting warehouse optimization configurations, users can establish criteria that, when met, will back off on cost optimizations and revert the warehouse to its larger state. This provides ample compute to handle those queries.

Then, once those criteria are no longer met, the optimizations will resume their normal activities. 

Why set different performance guardrails for different warehouses?

Keebo Performance Guardrails enable you to not only customize your optimization settings, but to set different increments for different warehouses. This level of control can be helpful when managing:

• Different warehouses for different clients, each of which have their own performance requirements
• Different SLAs for different warehouses, requiring more specific fine-tuning
• Different warehouse priorities that enable broader and stricter optimizations

How do Keebo Performance Guardrails work? 

Keebo users will already be familiar with the sliding scales that enable users to control how aggressively Keebo optimizes their warehouses. It’s a scale of 1-5, with 1 delivering best performance, and 5 delivering best Snowflake cost optimization.

Previously, Keebo set the scale of 1-5 to a default recommended value for each increment. Now Keebo allows individual users to set their own unique values for each increment and define based on five different criteria. 

Query latency

The first three criteria all pertain to query latency, or how long a query runs before it completes. The longer a query runs, the bigger the impact on performance. Plus, a long-running query on a smaller warehouse may end up costing more than running that same query for a shorter time, but on a larger warehouse.

As such, when query latency reaches a certain level, it’s best to back off your cost optimizations and give your warehouses ample resources to execute those queries. Query latency allows users to set specific parameters that, when met, will trigger a backoff. 

Because every workload has edge cases that can swing the workload in one direction or another, there are three query latency options within Keebo Performance Guardrails. 

• 95th percentile. When this option is selected, Keebo will back off its cost optimizations when 5% of queries do not meet the desired latency parameters.
• 99th percentile. When this option is selected, Keebo will back off its cost optimizations when 1% of queries do not meet the desired latency parameters.
• Max latency. When this option is selected, if a single query exceeds the latency parameters, Keebo will back off its optimizations. 

The goal of these options is to allow “wiggle room”, knowing that there are always edge cases that can impact query latency. We don’t want to optimize for edge cases, but the majority of the queries. However, you do have the ability to set stricter latency parameters in case your SLAs require you to do so. 

Total queue time

The other parameter you can use to trigger Keebo backoffs is the total queue time. In Snowflake, queries can end up in a queue for a number of reasons:

• Overload. Queries end up in a queue because the warehouse does not have sufficient resources to handle its current query workload.
• Provisioning. Queries can be queued as they wait for new resources to be allocated to them, including warehouse creation, resuming, or resizing. 
• Repair. Queries can end up in a queue due to hardware failures and wait for faulty servers to be replaced by healthy ones (this happens rarely). 

The total time queries spend in a queue is an indicator of warehouse overload or underprovisioning. Setting guardrails based on queue times will automatically back off optimizations, return the resources necessary to complete the queue, and then restart to optimizations once the queue time is below the indicated threshold. 

Number of queued queries

Finally, users can set five parameters for the number of queued queries. So for example, Best Performance could cause Keebo to back off on the optimizations when two queries are in the queue, and Lowest Cost could cause Keebo to back off when 12 queries are in the queue. Each increment would then fall along that scale. 

Regardless of which value you prioritize, Keebo Performance Guardrails give you more control over managing Snowflake cost savings vs. performance. The result: faster data, faster applications, all for a fraction of the cost. 

Want to learn more about Keebo Performance Guardrails? Schedule a live demo to see the feature—and our broader cost optimization platform—in action.