What are you doing about your cloud spending? It’s a key question on many organizations’ minds, and with good reason. Unpredictable cloud spending has quietly become the single biggest bottleneck facing modern data teams, especially as AI workflows have increased.
This is particularly important for Snowflake users. Snowflake transformed cloud data warehousing by making enterprise analytics simple to launch and operate. However, the convenience of its consumption-based model often comes at a cost, leading to budget volatility. What begins as a convenient, elastic environment often turns into a budget bottleneck when mixed or heavy workloads scale up.
This cost escalation is rooted in an architectural limitation. Snowflake relies on proprietary storage formats and native compute resources. It is also rooted in data centralization, which is a key architectural constraint. When organizations try to solve data access by centralizing every dataset inside the warehouse, they incur continuous costs for data ingestion, proprietary storage, and heavy compute costs. While Snowflake is powerful, it also represents an expensive solution when used for all workloads in an organization.
How can you keep Snowflake but reduce costs?
Luckily, there is a way to solve this problem, and it can be done iteratively. Reducing these expenses does not require abandoning the platform entirely. Instead, modern data management requires architectural optionality. By embracing open table formats like Apache Iceberg and joining interoperability efforts like the Open Semantic Interchange initiative, organizations opt to move certain workloads from one engine to another, decoupling their data from a monolithic, singular approach to compute.
Let’s look at a few strategies to help you facilitate this transition towards compute optionality.
TL;DR
* Configure aggressive auto-suspend settings and right-size warehouses to match specific workload demands rather than over-provisioning.
* Implement resource monitors and statement timeouts to prevent runaway queries from consuming excessive credits.
* Use query optimization techniques and predicate pushdown to reduce the volume of data scanned during execution.
* Identify high-volume or cold datasets to move into a data lakehouse using Apache Iceberg and Amazon S3.
* Adopt data federation to query across distributed sources instead of centralizing every secondary dataset into the warehouse.
* Utilize the Starburst icehouse architecture to manage data maintenance tasks without relying on proprietary warehouse credits.
Right-sizing warehouses and managing auto-suspend
The most immediate way to control costs in Snowflake is to audit virtual warehouse size. Because Snowflake scales compute linearly, a Medium warehouse costs twice as much as a Small, and a Large costs twice as much as a Medium. Organizations should start with the smallest possible warehouse for any new workload and only scale up if the query performance does not meet service level agreements.
A common mistake is leaving the default auto-suspend settings too high. For most business intelligence workloads, an auto-suspend setting of 60 seconds or less is appropriate. If a warehouse stays active for ten minutes after a query finishes, the organization pays for idle compute time. This can be adjusted via the `AUTO_SUSPEND` parameter in the SQL interface or the management console. For tasks that run intermittently, such as hourly data loads, ensuring the warehouse shuts down immediately after completion is necessary for cost control.
Multi-cluster warehouses are useful for high-concurrency workloads. Instead of sizing up to a larger warehouse to handle many users, multi-cluster warehouses allow Snowflake to automatically start additional clusters of the same size. This approach is often more cost-effective because it scales horizontally only when needed and spins down those extra clusters as demand subsides. This prevents a single large warehouse from running at 20% capacity during off-peak hours.
Implementing resource monitors and query limits
To prevent unexpected billing spikes, teams must implement resource monitors at both the account and warehouse levels. Resource monitors allow for hard limits on credit consumption for a specific period, such as a week or a month. These monitors can be configured to send alerts when usage reaches a certain percentage or to automatically suspend warehouses when they hit a predefined quota.
Beyond account-level monitors, the `STATEMENT_TIMEOUT_IN_SECONDS` parameter should be applied to individual warehouses or user sessions. By default, Snowflake allows queries to run for up to 48 hours. A poorly written join or a Cartesian product can consume hundreds of credits before it is noticed. Setting a more reasonable timeout, such as one hour or 30 minutes for ad hoc queries, ensures that runaway processes are terminated before they cause significant financial damage.
Query acceleration services can also be restricted. While the Query Acceleration Service can speed up large scans by offloading work to shared resources, it incurs additional credit costs. Monitoring the `QUERY_ACCELERATION_MAX_SCALE_FACTOR` ensures that the system does not over-allocate resources to a single query.
Query hygiene and optimization tactics
The efficiency of your SQL query also directly impacts credit spend. Teams should regularly review the Query Profile in the Snowflake UI to identify queries with high Remote Disk IO. This usually indicates that the data being queried does not fit into the local warehouse cache, forcing the system to pull data from the storage layer. This process is slower and often requires larger warehouses to perform effectively.
Properly defining clustering keys can reduce costs for very large tables. When data is naturally ordered by a specific dimension, such as a timestamp or a region, Snowflake can skip over irrelevant micro-partitions. This is a form of predicate pushdown where the engine filters data as early as possible. However, users must be careful with the Search Optimization Service and Automatic Clustering, as these features carry their own background maintenance costs in credits.
Materialized views require careful evaluation. While they speed up frequent queries, they consume credits for background maintenance whenever the underlying table changes. For highly volatile tables, the cost of maintaining the materialized view might exceed the savings gained during query execution. In such cases, standard views or optimized table structures are often more economical. Applying query optimization principles helps identify these trade-offs before they impact the monthly bill.
Understanding storage vs compute separation
Snowflake separates storage and compute, but the data must be in a proprietary format to be queried by its compute engine. This creates a situation where organizations pay for both the storage of the data and the compute required to ingest and transform it. For organizations with petabyte-scale data, the cost of ingesting and storing cold data that is rarely accessed can become a significant burden.
Analyzing the data lifecycle helps identify datasets that do not require the high-performance features of a cloud data warehouse. Log files, historical archives, and raw landing zone data are often better suited for an open data lakehouse solution. By storing this data in open formats like Apache Iceberg on Amazon S3, organizations maintain ownership of the data and avoid the costs associated with proprietary ingestion and storage.
This separation also allows for more granular control over data retention policies. Instead of keeping years of historical data in Snowflake, organizations can move older partitions to Amazon S3 while keeping them accessible via external tables or federated queries. This reduces the storage footprint within the warehouse and lowers the compute overhead for maintenance tasks like re-clustering.
Offloading workloads to an open data lakehouse
This is where Starburst comes in. By serving as an open execution engine built on managed Trino, Starburst provides universal access to data across more than 50 sources through data federation. For AWS workloads, running large-scale analytics and data lakehouse queries with Starburst can cut compute spend by up to 65 percent compared to native warehouse credits.
Crucially, capturing these savings does not demand a risky, all-at-once migration. Organizations can adopt a flexible coexistence model by deploying Starburst side by side with Snowflake. Engineering teams can identify heavy or cold workloads, validate query performance on open formats, and taper remaining Snowflake credits on their own schedule.
Achieving a sustainable data budget requires balancing quick operational fixes with long-term architectural strategy. The following sections walk through actionable tactics to optimize your current Snowflake configuration today while building an open foundation for tomorrow.
Using Snowflake alongside Starburst
A strategic way to reduce Snowflake costs is to move specific workloads to a more cost-effective compute engine. Starburst Galaxy and Starburst Enterprise both provide a high-performance SQL engine based on Trino that can query data directly on Amazon S3. In contrast, Starburst can be up to 65% cheaper than Snowflake for certain AWS workloads, though this is a vendor-stated figure and has not been independently verified.
By using the Icehouse architecture, organizations can build a functional data lakehouse that supports ACID transactions and high-performance analytics on open formats. This allows for reserving Snowflake for high-value, highly structured workloads where its specific features are most beneficial, while moving large-scale data processing and exploratory analytics to a more economical environment.
This approach helps avoid the risks of a full migration. Core financial reporting can remain in Snowflake while data science and experimental workloads move to Starburst. This coexistence model ensures the right tool is used for the right job without overpaying for compute. It also prevents the warehouse from becoming a dumping ground for raw data that has not yet been refined.
Leveraging data federation to minimize ingestion costs
Data migration is often a hidden cost of data warehousing. Every time data moves from a source system into Snowflake, costs are incurred for the ETL process, the compute used for ingestion, and the storage of the duplicate data. Data federation offers an alternative by allowing users to query data where it lives.
Using Starburst, teams can connect to various databases, such as PostgreSQL, MySQL, or other data warehouses, and join that data with existing Snowflake tables. This reduces the need to build and maintain complex pipelines for data that is only needed occasionally. It also ensures that analysts are querying the most recent data from the source system.
Rippling uses this approach to manage diverse data sources effectively. By federating queries, organizations provide a unified view of data to analysts without the overhead of centralizing every byte into a single, expensive repository. This strategy is particularly effective for cross-functional reporting where data resides in multiple SaaS applications or regional databases.
Transitioning to Apache Iceberg for long-term flexibility
The industry is moving toward open standards, and Apache Iceberg has emerged as a leading table format for the data lakehouse. Snowflake has introduced support for Iceberg tables, but using them within the Snowflake ecosystem still involves Snowflake compute credits. By adopting an open data lakehouse solution that uses Starburst and Apache Iceberg, organizations gain more control over compute costs.
When data is stored in Apache Iceberg on Amazon S3, the compute engine can be chosen based on the cost and performance requirements of the task. For a detailed look at how this architecture functions, see How Does a Data Lakehouse Work?. This flexibility is essential for Choosing the Best Data Lakehouse Platform for AI, where the volume of data can be massive and query patterns are often unpredictable.
Using the Icehouse lakehouse platform allows for data maintenance tasks, such as compaction and snapshot expiration, to be performed without relying on proprietary warehouse credits. This decoupling of data management from the warehouse engine is a key factor in long-term cost reduction and architectural freedom.
Why enterprise AI success comes down to data access
As organizations integrate artificial intelligence into their operations, the cost of data access becomes a primary concern. Traditional warehouses can become bottlenecks when AI models require access to vast amounts of raw data for training and inference. The ability to reach data across a distributed environment is more efficient than centralizing it.
AI workloads often involve non-linear access patterns that do not align well with the micro-partitioning logic of a standard data warehouse. By using an open data lakehouse, data scientists can use specialized tools to interact with Apache Iceberg tables on Amazon S3 without incurring the high per-query costs of a warehouse. This ensures that AI initiatives remain financially viable as they scale from pilot programs to production environments.
Furthermore, an open architecture allows for the use of multiple compute engines against the same data set. A machine learning model might use a Spark-based engine for training while a business analyst uses Starburst for reporting, all without moving the data or paying for multiple storage copies.
Evaluating when to move off the warehouse
While Snowflake is an effective tool for many use cases, it is not always the most cost-effective choice for every workload. Organizations should consider replacing their cloud data warehouse for specific high-volume or low-value datasets. If a significant portion of Snowflake spend goes toward data that is rarely queried or toward simple transformation tasks, those are candidates for offloading.
The goal is to optimize Snowflake use rather than replace it entirely. By implementing strict warehouse management, improving query hygiene, and strategically offloading workloads to an open data lakehouse solution, organizations can significantly reduce overall data platform spend. This balanced approach maintains the performance users expect while keeping the cloud budget under control.
Use Snowflake differently by leveraging Starburst
Reducing Snowflake costs is a continuous process that requires technical optimization and architectural strategy. Organizations should begin by cleaning up the existing environment through warehouse right-sizing, aggressive auto-suspend settings, and the implementation of resource monitors. Once these immediate steps are taken, the broader data architecture should be evaluated.
By integrating data federation and moving toward an open data lakehouse model with Starburst and Apache Iceberg, companies can create a more sustainable data estate. This strategy ensures that organizations are not locked into a single vendor pricing model and provides the freedom to scale data capabilities without a corresponding explosion in costs.
Learn more about Starburst vs Snowflake, or read the full ebook.
