Snowflake Cost Optimization: 6 Cost Reduction Strategies

Snowflake is popular among data teams for a number of reasons: scalability, performance, and ease-of-use. But on the flip side, it’s easy to spend more on Snowflake than you originally planned. If you’re looking for ways to reduce Snowflake spend, rightsize your contracts, or get the most out of your credits, you’re in the right place. Read on for our tried-and-true Snowflake cost optimization best practices. 

Contents

1. What is Snowflake cost optimization?
2. Is Snowflake a cost effective solution? 
3. How does Snowflake pricing work?
4. Why is Snowflake cost optimization important? 
5. Top 6 Snowflake cost reduction strategies
6. Snowflake cost optimization examples

What is Snowflake cost optimization? 

Snowflake cost optimization is the process of monitoring Snowflake usage, identifying unnecessarily high spend, and adjusting your configuration or usage to reduce costs. 

A common misconception is that optimizing Snowflake costs comes at the expense of performance. In our experience, this doesn’t have to be the case. Some cost optimization techniques (e.g. query routing) actually maintain and increase performance while reducing costs. Others (like warehouse optimization) can be configured to only reduce costs with no or very limited negative performance impact.

Is Snowflake a cost effective solution? 

Snowflake can be a cost effective data cloud solution. Or, it can be too costly. It depends on how you use it. 

On paper, yes, Snowflake seems to offer a number of options to help keep costs under control. Limited overhead, flexible pricing, and scalability. If you control your usage and only buy what you need, you can reduce costs significantly, especially compared to on-prem or other cloud data platforms. 

But if you don’t proactively control your Snowflake usage, you could end up spending 200% to 300% more than expected. There are a number of reasons why Snowflake costs can get out of control so quickly: 

• Over-provisioning Snowflake credits. Often Snowflake users purchase credits at Capacity based on anticipated growth over the course of their contract. When that growth doesn’t materialize, they end up with credits they don’t really need. 
• Under-provisioning at Capacity. The opposite can also be true. By buying too few credits at Capacity (and at a discount), users are paying too much for add-on credits just to maintain their performance levels. 

• Lack of visibility into cost savings opportunities. It can be difficult to identify opportunities to reduce Snowflake spend. This is partly because of Snowflake’s complex pricing structure, but also due to limited visibility into heavy-hitting users and queries. 
• Manual action. There are 3rd party service providers Snowflake cost monitoring tools that provide recommendations for cost savings. But given the dynamic nature of the cloud, recommendations are only useful in the moment. Without instant, real-time action, these 3rd party service providers are ineffective. 

Basically, Snowflake can be a cost effective solution if you make it. But without proactive, real-time management, you can end up with serious sticker shock. 

How does Snowflake pricing work?

Snowflake pricing consists of three spend categories: data storage, data transfer, and compute resources. Data storage is priced based on a flat rate per terabyte (TB) for both uncompressed and compressed data. Data transfer is priced based on how much data you transfer from a Snowflake account to a different cloud platform or Snowflake region.

But the third spend category—compute resources—is what most people think of when they think of Snowflake spend. Executing queries, loading data, or engaging in other DML operations all consume compute resources. These resources fall into three categories. 

Virtual warehouse compute

Virtual warehouse compute resources consume credits per second spent executing queries, loading data, and other DML operations. You can size warehouses based on desired compute power. Warehouses double in credit consumption with each successive size increase. 

Snowflake users can purchase credits in two ways: On-Demand or Capacity. On-Demand is a true pay-as-you-go model, while Capacity involves pre-purchasing a set number of credits for a significant discount. 

Serverless compute

Other Snowflake features like Search Optimization and Snowpipe use serverless compute resources, which Snowflake automatically scales up or down for each workload.  This can be cost-effective for irregular workloads or when you need to handle spikes in activity without maintaining a continuously running virtual warehouse.

Cloud services compute

Snowflake also consumes credits for tasks like authentication, metadata management, API, SQL, query parsing and access control if those tasks exceed 10% of daily warehouse usage.

How much do Snowflake credits cost? 

Snowflake credits are priced based on which Snowflake pricing tier (called “Editions”) you use. There are four Snowflake Editions available to users. 

Standard Edition

Snowflake Standard Edition features the full SQL data warehouse and cloud-based services. Key features include dedicated virtual warehouses, database replication, and enterprise-grade encryption when data is both in transit and at rest. 

Enterprise Edition

Snowflake Enterprise Edition includes everything in the Standard plan, adding multi-cluster warehouse, 90-day “time travel” data recovery, dynamic data masking, external data tokenization, and materialized views. 

Business Critical Edition

The Snowflake Business Critical Edition adds the following features to the Enterprise capabilities: HIPAA and PCI DSS compliance, support for AWS & Azure Private Link and GCP Private Service Connect, and AWS API Gateway Private Endpoints.

Virtual Private Snowflake (VPS) Edition

Snowflake VPS Edition offers all the features of the previous three tiers, adding customer-dedicated virtual servers accessible only by authorized team members. 

What does Snowflake use to measure your costs?

The vast majority of Snowflake costs are measured via your Snowflake Edition, which determines the cost per credit, and the number of credits consumed. By controlling your credit consumption, you can reduce your Snowflake costs. 

Why is Snowflake cost optimization important?

Snowflake optimization offers a number of benefits that go beyond just reducing your current spend levels. It can also help justify a lower Snowflake contract upon renewal. Additionally, it can help you get the most out of your current provisioned credits. 

Reduce Snowflake spend

If you’re on an On-Demand plan, the immediate benefit of Snowflake cost optimization is a reduction in Snowflake spend. 

However, it’s important that the optimization approach you use doesn’t consume more resources than you save. For example, if a data engineer spends hours manually adjusting your warehouse, it could end up being a net negative.

Rightsize future Snowflake contracts

If you’re using a Capacity plan, you won’t see an immediate reduction in spend until your plan comes up for renewal. However, if you can reduce your spend by 25% for six solid months, you can confidently negotiate a lower contract without any fear of credit overuse. 

Get the most out of your current credits

Snowflake cost optimization can also benefit you, even if you don’t reduce immediate spend or negotiate a smaller contract in the future. The fewer credits you consume for a particular query or set of queries, the more credits you’ll have in the future. In short, cost optimization helps you maximize the value of each credit you currently have. 

6 Snowflake cost optimization strategies – How to save costs on Snowflake

Regardless of your Snowflake cost reduction objectives, you have a wide range of tools available to help you achieve those goals. These range from relatively simple practices that are easy to manage, to more complex operations that require more time and resources to do well. They generally fall into one of these six strategies. 

1. Virtual warehouse configuration

Virtual warehouse configuration involves dynamically adjusting the compute resources provisioned for particular uses at the warehouse level. The goal is to provision only the resources necessary to maintain desired performance and no more. 

Reducing auto-suspend

Snowflake only consumes credits from actively running warehouses. Suspending warehouses when they’re not in use can help you consume fewer credits. As such, many Snowflake users auto-suspend warehouses after a specified period of inactivity (expressed in seconds): 

ALTER WAREHOUSE compute_wh SET auto_suspend=120;

One common mistake users make is to set auto-suspend as low as possible. The reason for this is an actively running warehouse maintains a cache of table data accessed by recent queries. By accessing this cache, the warehouses can run subsequent queries on that same table faster. 

If you set your auto-suspend at, say, five seconds, you’ll end up with a thrashing warehouse constantly going back and forth between suspend and active. Each time the warehouse suspends, you lose your cache, and queries take longer to execute as they’re constantly pulling data from cold storage. 

An alternative is a predictive approach to auto-suspend. There’s a manually set maximum upper limit, but if the AI determines based on  predictive analysis that there will be no incoming queries within that limit, it can shut down the warehouse sooner and save those credits. 

Rightsizing your virtual warehouses

Another Snowflake cost optimization tactic is to rightsize your virtual warehouse to match incoming workloads. This approach ensures that you only provision resources you need to complete the task and no more. 

It’s easy to adjust your Snowflake warehouse sizes in Snowsight or the classic console. Here’s an example of how to make these changes in SQL:

ALTER WAREHOUSE my_wh SET WAREHOUSE_SIZE = small;

Adjusting warehouse sizes isn’t a set-it-and-forget it process. Far from it. Snowflake workloads are highly dynamic, often changing minute-to-minute (or second-to-second). If your warehouses are too small to handle a suddenly resource-heavy workload, you can end up consuming more credits.

Here’s an example of what we mean: 

In that example, then, the cost savings ended up favoring the XL warehouse. But let’s consider another case:

Because Snowflake has a 60-second minimum for query execution, scaling up to an XL, while speeding up query performance, ends up costing you significantly more credits.

You can see how even with this simple example there are complex factors going into Snowflake spend. Given how quickly these changes occur, you can see how this could quickly become someone’s full-time job. If you have to pay an engineer for their time spent on cost optimization, it’s not truly a net positive. 

That’s one reason we recommend using an AI-powered tool to handle this. That way, your engineers are freed up to perform more value-add tasks and projects. 

Ensure minimum clusters are set to 1

If you have Snowflake Enterprise Edition or higher, you have access to multi-cluster warehousing. Snowflake’s virtual warehouses consist of a single cluster of compute resources available to execute queries. By clustering with other warehouses, you can essentially “pull” resources in the event a single warehouse can’t handle its assigned workload. 

Image source: Cristian Scutaru on Medium

If you use multi-cluster warehouses, make sure your minimum cluster count is set to 1 and not any higher. This will help you avoid unnecessary over-provisioning. If your warehouses require more resources, Snowflake will simply add them up to your maximum cluster count automatically. 

Here’s how to simply set this up in SQL: 

ALTER WAREHOUSE compute_wh SET min_cluster_count=1;

Consolidate warehouses

Too many organizations structure their warehouses according to their business logic, not warehouse logic. For example, they may have warehouses dedicated to specific clients or business functions, irrespective of whether those verticals are using all the resources provisioned to them. 

If you have too many warehouses sitting around without reaching query saturation, it can be helpful to consolidate those warehouses. A good place to start is to set up warehouses by data function, not internal org charts. One warehouse for loading, one for transformations, and one for querying is better than having dedicated warehouses for marketing, sales, supply chain, finance, etc. 

However, sometimes warehouse consolidation is not feasible. In that case, consider leveraging alternative Snowflake query performance optimization techniques, like query routing. 

Snowflake virtual warehouse configuration challenges

Regardless of which tactics you prioritize, there are a few challenges with Snowflake virtual warehouse configuration: 

• Virtual workloads are dependent on ever-changing user demands, which means warehouse configuration is an ongoing process
• Ongoing monitoring and observability are necessary to make configuration decisions in enough time to actually save on Snowflake
• Some of these tactics are complex enough that it requires an experienced data engineer to manage without further hurting performance—leading to higher personnel costs

All of these are part of the reason we suggest using an AI tool, not a human engineer, to make real-time changes to Snowflake warehouses. Not only can AI do it faster, but it can achieve a more fine-tuned balance between savings and performance. 

2. Workload configuration

Virtual warehouse configuration involves adjusting the warehouse to fit the workload. Snowflake workload configuration does the opposite: adjusting workloads to fit the resources assigned in your warehouses. Depending on a given workload’s frequency, number of concurrent queries, scan size, and more, it makes sense to assign it to a warehouse with more or fewer provisioned compute resources. 

Active workload monitoring

Before you start configuring, you first need to get a handle on what your Snowflake workload actually looks like. Specifically, you need to identify which queries, users, and warehouses are consuming the most resources. 

You can do this via SQL queries or through (limited) visibility tools in Snowsight. But if you really want to get a read on those heavy hitters, use Keebo’s free Snowflake Workload Intelligence tool. 

Reducing query frequency

Not all Snowflake workloads need to run hourly. Low traffic times, like weekends, can afford a higher latency. Whether or not you can afford to reduce frequency depends on a number of factors, including your desired performance and any active service level agreements. 

Query routing

Most Snowflake instances have a mix of over- and under-utilized warehouses. This is typically due to warehouse configuration based on business logic vs. data cloud performance logic. To avoid this disparity, you can route queries from one warehouse to another—essentially making the most of the sources you’ve already provisioned. 

Query optimization

Another common Snowflake cost reduction tactic is to simply edit the queries themselves. Certain SQL commands consume more resources than others. Often you can achieve the same result faster and cheaper just by rewriting your code. 

Some common query optimization tactics include:

• Instead of using the SELECT * command, use SELECT to gather data only from necessary columns, thus reducing the amount of data processedC
• Prune queries by placing the WHERE clauses as early as possible, adding well-clustered columns to JOIN and MERGE conditions, avoiding use of functions in WHERE conditions, and more
• Consolidate and remove unnecessary operations from your SQL commands
• Consider using Common Table Expressions (CTEs) to separate SQL logic into separate subqueries
• Avoid JOIN functions with an OR condition

Maintain referential integrity

Without proper referential integrity, you risk running queries that retrieve bad data. By the time you’ve identified the problem, it takes extensive resources (read: costly engineering hours) to fix. 

Image source: Database.Guide

One quick and easy way to help maintain referential integrity is to use CONSTRAINT commands in SQL when you CREATE TABLE or ALTER TABLE. You can use the TABLE_CONSTRAINTS command in your Information Schema to retrieve a list of available table constraints. 

Only process new or updated data

A good chunk of your Snowflake data won’t change at all once created: shipment dates, web events, first name, last name, etc. Others won’t change after a certain interval: orders are highly unlikely to be altered beyond a month after your initial purchase. 

If you can avoid re-querying immutable data every time you do a batch data transformation, it can significantly cut down on your credit consumption. By using incrementalization to filter records within a certain time window, you can only pull new data then insert it into the final table without having to reprocess it all over again. 

Challenges with Snowflake workload configuration

Despite the savings that come through optimizing your Snowflake workloads, there are some challenges: 

• Require in-depth SQL knowledge and general technical acumen to implement correctly—which means those hours can be expensive
• Heavily reliant on good practices among your data team, which requires ongoing training and supervision
• Some workloads are impossible to optimize (e.g. an AI-generated query through a Looker integration)

While it’s important to optimize Snowflake workloads where you can, it’s not feasible to rely on this as your primary means of cost reduction. The exception to the rule is query routing, which you can automate in the background and run it 24/7 through an AI-powered tool. 

3. Table configuration

Inefficient tables require queries to consume more resources than necessary. By specifying column lengths, storing semi-structured data in VARIANT columns, and using transient tables, you can reduce data scans and, with them, the resources necessary to execute your queries. 

What’s more, the more data in your tables, the higher your Snowflake storage costs. By optimizing your table configuration, you can ensure you’re only retaining the data you need in Snowflake and not spending on unnecessary resources. 

Cluster tables correctly

We briefly discussed query pruning above, which can help reduce the number of micro-partitions scanned during query execution, thus reducing the amount of irrelevant data scanned. This requires filtered columns to have a narrow range of values.

For query pruning to work, Snowflake tables must be clustered based on query access patterns. For example, if you frequently query a last_modified date for your orders tables, you should cluster around that column. This can reduce query runtime and significantly lower your costs. 

Image source: Snowflake

Drop unused tables

Every Snowflake user has some tables that are unused—whether time-travel backups or otherwise un- or underutilized data. If you’re on Snowflake Enterprise edition or higher, you can identify unused tables in just a few clicks. Alternatively, you can perform a simple SQL query to identify rank tables by TOTAL_BILLABLE_BYTES and find the ones with the highest storage costs. 

SELECT
   table_catalog AS database_name,
   table_schema AS schema_name,
   table_name,
   (active_bytes + time_travel_bytes + failsafe_bytes +
   retained_for_clone_bytes) AS total_billable_bytes
FROM
   snowflake.account_usage.table_storage_metrics
ORDER BY
   total_billable_bytes DESC
LIMIT 5;

Reduce data retention

In the same vein, you can reduce the number of days Snowflake retains a time-travel backup table. The longer that data is retained, the more you’ll spend in storage costs. Ask yourself: what data do we really need historical access to and for how long? 

Use transient tables

One strategy for reducing data retention is to use transient tables. If you regularly delete and recreate tables as part of your ETL processes, you don’t need to back up your data. By converting a permanent table into a transient one, you can avoid spending unnecessary data storage costs for fail safe or backups. 

Challenges with Snowflake table configuration

Configuring your Snowflake tables is generally a good practice and can help realize some savings. However, for most Snowflake users, poor table configuration represents a small percentage of wasted Snowflake spend. So if you deploy too many resources against these problems, it may not end up being a net positive in savings. 

4. Data loading patterns

Although Snowflake doesn’t charge for incoming data, your data loading patterns can impact your storage and compute costs. As such, optimizing how you load your data can reduce your Snowflake spend down the line. 

Avoid frequent DML operations

Snowflake is built to handle large volumes of data. Treating it like an operational database with frequent DML operations is a poor best practice reducing your Snowflake spend. First, every time you update or delete a record, Snowflake recreates the entire micro-partition within which that record is contained, which contains hundreds of thousands of records. Second, constantly recreating micro-partitions requires Snowflake to keep copies of all versions of a table, dramatically increasing the amount of storage you use. 

Ensure your files are optimally sized before loading

When loading data files into Snowflake, you need to achieve the Goldilocks zone: not too large, not too small. The optimal range is somewhere around 100-250MB. Above that, you’re over-saturating any one thread used for data loading. Below that, you’re incurring excessive costs as Snowflake charges an overhead fee of 0.06 credits per 1,000 files loaded. 

Challenges with data loading

While optimizing your data loading patterns is a good best practice, it only helps at the start of the data lifecycle. It really does nothing to control the costs of ongoing analysis, transformation, and overall usage of that data.  

5. Performance tuning

Snowflake performance tuning involves a host of tactics that optimize three broad categories of Snowflake activity: data loading, data transformation, and query & task execution times. Some of the tactics we’ve discussed thus far fall into the broad category of performance tuning, but here are three more to add to the list. 

Check and reduce queuing

Query queues form when a warehouse is so overloaded with requests that it cannot execute new queries until adequate resources are available. You can identify queries experiencing queuing delays with a free tool like Snowflake Workload Intelligence, or by running the following SQL query: 

SELECT query_id,
   user_name,
   warehouse_name,
   start_time,
   end_time,
   total_elapsed_time / 1000 AS total_elapsed_time_seconds,
   queued_provisioning_time / 1000 AS queued_provisioning_time_seconds,
   queued_repair_time / 1000 AS queued_repair_time_seconds,
   queued_overload_time / 1000 AS queued_overload_time_seconds,
   (queued_provisioning_time + queued_repair_time + queued_overload_time)
    / 1000 AS total_queued_time_seconds,
   transaction_blocked_time / 1000 AS transaction_blocked_time_seconds,
   execution_time / 1000 AS execution_time_seconds,
   query_text
  FROM snowflake.account_usage.query_history
  WHERE start_time >= DATEADD(day, -1, CURRENT_TIMESTAMP())
  AND (queued_provisioning_time > 0 OR queued_repair_time > 0 OR
   queued_overload_time > 0 OR transaction_blocked_time > 0)
  ORDER BY total_queued_time_seconds DESC;

• Consider creating additional warehouses and route new queries to them
• Increase the maximum number of clusters for multi-cluster warehouses
• Adjust your maximum concurrency level to adjust the number of queries that can run simultaneously—note that this reduces the resources allocated to each query, thus increasing the latency for all queries running concurrently

Use result caching

Snowflake query caching consists of three layers: the result cache, local disk cache, and remote disk cache. Of the three, the result cache is the most important, as it stores the full results of every executed query for 24 hours. This enables subsequent queries to retrieve these results, which can significantly reduce query latency. 

Result caching uses two SQL functions. The first is RESULT_SCAN, which retrieves and processes the result set of a previously executed query. From there, you can process output from the following: 

• SHOW or DESC[RIBE] command that you executed
• Queries executed on metadata or account usage information
• Stored procedure results

SELECT * FROM TABLE (RESULT_SCAN('<query_id>'));

The second function is DESC[RIBE] RESULT, which Describes the columns in the result of a query over the past 24 hours: 

DESC[RIBE] RESULT { '<query_id>' | LAST_QUERY_ID() }

Mitigating row explosion

When a query produces an unexpectedly large number of rows, we call that row explosion. The most common cause of row explosion is JOIN or other operations that multiply the number of rows. Tactics to mitigate row explosion include:

• Leveraging more compact data types
• Filtering out unnecessary columns or rows
• Reducing returned rows with DISTINCT or GROUP BY clauses
• Aggregating before joining instead of joining before aggregating
• Breaking down queries into smaller steps, storing immediate results in temporary tables

Image source: Snowflake Community

Spillage monitoring

When a warehouse has insufficient memory to accommodate a given operation, it will “spill” that data onto a local disk or to remote storage. Because spillage significantly degrades query performance, it can significantly balloon your Snowflake costs. 

Some solutions to help prevent spillage include the tactics already mentioned above: warehouse optimization, query pruning, mitigating row explosion, query optimization, and more. 

Challenges with performance tuning

Snowflake performance tuning can help dramatically keep your Snowflake costs under control. However, it can get unwieldy when you’re relying on human engineers to monitor and correct poor practice in real-time. Using automated tools to rightsize your provisioned resources can help with queuing, result caching, spillage remediation, and the other challenges mentioned here. 

6. Leverage built-in Snowflake controls

Although we’re listing it last on our list, the first strategy users typically implement when optimizing their spend is to use Snowflake’s built-in tools. While these tools are limited, they offer some limited help in controlling your spend. 

Leverage access control

One often underrated approach to controlling Snowflake costs is access control. By restricting permissions to change or adjust your warehouses, you reduce the chance of someone accidentally making a mistake that inflates your cost, like scaling up a warehouse and forgetting to scale it back down. 

Additionally, Snowflake enables you to control user access to warehouses, limiting who can run queries. This can be especially helpful if you have heavy hitter users you need to control. By forcing them to use smaller warehouses, you incentivize them to write more efficient queries and, thus, consume fewer resources.

Enable query timeouts

Snowflake includes the ability to set automated query timeouts. If a query runs longer than your designated length, Snowflake will automatically cancel it. 

Set up Snowflake resource monitors

Another option is to use resource monitors in Snowflake to help control your credit consumption. When a given warehouse hits a certain credit limit, the resource monitor will automatically suspend it.

Image source: Snowflake

While resource monitors are great at keeping your credit consumption under control, they’re not a feasible solution for most businesses. For instance, if you have an SLA that requires you to hit certain performance benchmarks, shutting down the warehouse isn’t an option. 

Snowflake budgets

Another option for keeping your costs under control are Snowflake budgets. These budgets track credit usage across all your tables, materialized views, schemas, databases, warehouses, pipes, and tasks. Once you exceed your budget, you’ll automatically get a notification. But if you want to take action to keep your costs under control, you then have to implement one of the strategies listed above.

Snowflake cost optimization FAQs

What strategies should you use to manage compute costs in Snowflake?

The most common strategies we recommend to manage compute costs in Snowflake are: warehouse optimization & query routing. Warehouse optimization involves dynamically configuring your warehouses to respond to highs and lows in resource needs. Query routing involves sending queries to unused or underutilized warehouses to ensure you’re getting the most out of your existing resources. 

What is a KPI in Snowflake? 

There are a number of Key Performance Indicators (KPIs) or Snowflake metrics to help determine your performance levels. The best for monitoring performance and cost are heavy hitting queries or query patterns, heavy hitting users, and warehouse utilization metrics (credit usage, query volume, execution times, queuing times, etc.).  

Does Snowflake separate storage & compute?

Snowflake charges separately for storage and compute. Data storage is charged on a flat rate per terabyte (TB) of data stored. Data compute is charged on a credit-based system. 

Does Snowflake charge for data storage?

Snowflake charges for data storage on a flat rate per terabyte basis. 

Snowflake cost optimization examples

Let’s now take a look at three examples of Snowflake cost optimization in practice. Each of these companies used Keebo to automate warehouse optimization and significantly reduced their Snowflake costs as a result. 

Barstool Sports: Reducing Snowflake costs by 70%

Barstool Sports has a major digital media footprint and uses data from Snowflake, Looker, and AWS data analytics tools to better align their content with user interests. However, the sheer volume of data causes their costs to balloon. 

After deploying Keebo as a cost optimization solution, Barstool Sports cut Snowflake spend by 70%, freeing up resources to deliver high-value strategic features to the business on a tight timeline.

According to Nick Booth, Barstool Sports Head of Backend Engineering, “With Keebo, we can focus on delivering value instead of spending time worrying about costs. It was a really easy decision for us to trial and keep Keebo in our infrastructure because of how easy it was to integrate and how immediate and apparent the benefits were.”

Read the full Barstool Sports case study here. 

Hyperscience: 50% reduction in Snowflake costs

As Hyperscience began new initiatives to deliver dashboards and predictive models to their business users, their Snowflake usage increased by 4X. After deploying Keebo, Hyperscience managed to reduce that spend by 50% with no corresponding reduction in dashboard response time. 

According to Erik Jones, Hyperscience Head of BI and Analytics, “Keebo brought immediate savings from the very start—half of what we were projecting with Snowflake. To do what Keebo does for us, I would need an entire team of data engineers.”

Read the full Hyperscience case study here. 

Freshworks: Reducing Snowflake cost optimization from weeks to hours

Freshworks generates over seven million Snowflake queries every day, and that number continues to grow. Even with a large data team, manual optimization could not keep up with their growth rate. 

After deploying Keebo, Freshworks reduced their Snowflake costs by 10-15% even while they increased their work loads. They did this while maintaining strict SLA demands and reducing data team optimization workload from weeks to mere hours. 

According to Anand Chiddarwar, Freshworks Principal Engineer, “Keebo’s automated optimizations always keep us on top of opportunities to save without impacting query performance.”

Read the full Freshworks case study here. 

Final thoughts on Snowflake cost optimization

Like any other cloud platform, it’s easy for Snowflake costs to get out of control. Snowflake cost optimization, on the other hand, requires intentional, consistent action. Even large data teams struggle to get a handle on all the various practices necessary to reduce your costs. 

That’s why we recommend using an AI-powered tool like Keebo to make real-time adjustments that enable you to both save money and also get the most out of your current Snowflake spend. 

The results speak for themselves. So every second you spend waiting to get started is money and credit usage you’re leaving on the table. 

Get started with Keebo now, and you could start reducing your Snowflake costs by the end of the day.