ResourcesData

Snowflake Cost Optimization: Strategies & Orchestration

Unexpected Snowflake bills stem from uncoordinated workloads. Learn to reduce Snowflake costs by orchestrating compute, storage, and cloud services efficiently.

TL;DR — Snowflake cost optimization is the practice of managing compute, storage and cloud services so the bill tracks the value produced. The main levers are right-sizing warehouses, letting them auto-suspend, rewriting queries that scan more than they need, and controlling when workloads run at all — most overspend is idle compute, not expensive queries.

Snowflake offers unparalleled flexibility and scalability for data workloads, but its pay-as-you-go model can lead to unexpected costs if not managed proactively. Many teams find themselves wrestling with rising bills, unsure of where their credits are going. The culprit is often uncoordinated execution: idle warehouses, cascading refreshes, and workloads firing at suboptimal times.

This guide explores the core drivers of Snowflake costs and outlines actionable strategies for optimization. We’ll dive into how precise orchestration can bring control and predictability to your Snowflake spend, ensuring you maximize value without sacrificing performance.

Understanding Snowflake Costs: The Primary Drivers

To effectively manage Snowflake costs, you first need to understand where the charges originate. The billing model is based on three main components:

  1. Compute: This is the cost of running virtual warehouses, the engines that execute your queries and data loading jobs. It’s billed per second based on the size of the warehouse (X-Small, Small, Medium, etc.). Compute is typically the largest and most variable part of a Snowflake bill, making it the primary target for optimization.
  2. Storage: This is the cost of storing your data within Snowflake. It’s a flat rate per terabyte per month, but it includes not just your active data but also data retained for Time Travel and Fail-safe features. While generally less expensive than compute, unmanaged storage can add up over time.
  3. Cloud Services: This layer handles metadata management, query optimization, security, and coordination. Snowflake provides a free daily credit allocation for cloud services, typically equivalent to 10% of your daily compute credit usage. Costs are only incurred if usage exceeds this free tier, which can happen with complex metadata operations or inefficient queries.

Understanding the differences between data warehouse cost models is essential for building a cost-effective data platform. For Snowflake, the key is that compute costs are directly tied to warehouse uptime, making control over execution schedules a powerful lever for optimization.

The Cost of Uncoordinated Execution: Why Orchestration Matters

A common source of runaway Snowflake costs is the “always-on” warehouse. This often happens not by choice, but as a result of uncoordinated data pipelines. Consider a typical scenario:

  • An ingestion tool loads new data into Snowflake every 15 minutes.
  • A dbt model runs on a schedule to transform that data.
  • A reverse ETL job syncs the transformed data to a CRM.
  • BI dashboards refresh periodically.

If each of these processes triggers the warehouse independently without coordination, the warehouse may never find a gap long enough to auto-suspend. The result is paying for compute credits 24/7, even if the warehouse is idle for significant periods between tasks.

This is where a universal orchestrator becomes essential. While Snowflake Tasks are useful for in-database scheduling, they lack visibility and control over the external tools that trigger warehouse activity. An orchestration platform can manage the entire end-to-end workflow, ensuring the warehouse is active only when a job needs it.

Orchestrate Snowflake Cost Control with Kestra: Event-Driven Warehouse Management

Instead of relying solely on Snowflake’s AUTO_SUSPEND feature, you can use an external orchestrator like Kestra to implement more intelligent, proactive warehouse management. This approach allows you to suspend and resume warehouses based on the actual state of your data pipelines, business hours, or any other custom logic.

The following Kestra workflow demonstrates how to automatically check a Snowflake warehouse for activity and suspend it if it has been idle, sending a notification to Slack.

id: snowflake-cost-saver-suspend-idle-warehouse
namespace: company.team.finops
tasks:
- id: check_warehouse_activity
type: io.kestra.plugin.jdbc.snowflake.Query
url: "{{ secret('SNOWFLAKE_URL') }}"
username: "{{ secret('SNOWFLAKE_USER') }}"
password: "{{ secret('SNOWFLAKE_PASSWORD') }}"
warehouse: "ADMIN_WAREHOUSE"
database: "SNOWFLAKE"
schema: "ACCOUNT_USAGE"
fetchOne: true
sql: |
SELECT
COUNT(*) AS recent_queries
FROM QUERY_HISTORY
WHERE WAREHOUSE_NAME = 'ANALYTICS_WH'
AND START_TIME >= DATEADD(minute, -15, CURRENT_TIMESTAMP());
- id: if_idle_suspend
type: io.kestra.plugin.core.flow.If
condition: "{{ outputs.check_warehouse_activity.row.recent_queries == 0 }}"
then:
- id: suspend_warehouse
type: io.kestra.plugin.jdbc.snowflake.Query
url: "{{ secret('SNOWFLAKE_URL') }}"
username: "{{ secret('SNOWFLAKE_USER') }}"
password: "{{ secret('SNOWFLAKE_PASSWORD') }}"
warehouse: "ADMIN_WAREHOUSE"
sql: "ALTER WAREHOUSE ANALYTICS_WH SUSPEND;"
- id: notify_on_suspend
type: io.kestra.plugin.notifications.slack.SlackIncomingWebhook
url: "{{ secret('SLACK_WEBHOOK_URL') }}"
payload: |
{
"text": "Snowflake warehouse 'ANALYTICS_WH' was idle and has been suspended to save costs. Execution: {{ execution.id }}"
}
triggers:
- id: every_15_minutes
type: io.kestra.plugin.core.trigger.Schedule
cron: "*/15 * * * *"

What this flow accomplishes:

  • Scheduled Monitoring: The flow runs every 15 minutes, acting as a vigilant cost-saving agent.
  • Activity Check: It queries Snowflake’s QUERY_HISTORY to see if the target warehouse (ANALYTICS_WH) has executed any queries in the last 15 minutes.
  • Conditional Suspension: If no recent queries are found, it executes an ALTER WAREHOUSE ... SUSPEND command.
  • Auditable Action: A Slack notification is sent, providing a clear audit trail of when and why the warehouse was suspended.

This declarative YAML approach allows FinOps and data teams to define and version control their cost-saving policies as code. You can find more details in the Snowflake plugin documentation.

When to Use External Orchestration vs. Native Snowflake Tasks

Choosing between a universal orchestrator and Snowflake’s native features depends on your workflow’s scope:

  • Snowflake Tasks: Use for scheduling sequences of SQL statements that run entirely within Snowflake. They are a good fit for simple, recurring in-warehouse jobs.
  • Kestra: Use when you need to orchestrate Snowflake as part of a larger, multi-system process. This includes triggering jobs based on external events (e.g., a file landing in S3), running dbt transformations, calling external APIs, and managing dependencies across different technologies.

For end-to-end cost control, an external orchestrator provides the end-to-end visibility that is necessary to manage the full lifecycle of data and compute.

Core Strategies for Snowflake Cost Optimization

Beyond intelligent scheduling, several other strategies matter for reining in Snowflake expenses:

  • Warehouse Sizing and Management: Start with smaller warehouses and scale up only when performance requirements demand it. Use multi-cluster warehouses to handle concurrency spikes, and set an aggressive AUTO_SUSPEND time (e.g., 60-300 seconds) as a baseline.
  • Query Optimization: Inefficient queries are a major source of credit consumption. Use Snowflake’s Query Profile to identify bottlenecks. Techniques like reducing data scanned, using clustering keys on large tables, and leveraging materialized views can dramatically cut query times and costs.
  • Data Storage and Retention: Regularly review your data retention policies for Snowflake Time Travel. While a powerful feature, a 90-day retention period for all tables can be costly. Adjust it based on the criticality of the data. Similarly, manage your data lifecycle in cloud storage with tools like S3 Lifecycle Policies.
  • Resource Monitors: Configure resource monitors to send alerts or automatically suspend warehouses when credit consumption reaches a predefined threshold. This is a critical safety net against unexpected spikes in usage.
  • Efficient Data Loading: For continuous data ingestion, use Snowpipe to avoid keeping a warehouse active just for small, frequent loads. For batch loads, group data into larger files (100-250MB) to optimize the loading process.

FinOps on Snowflake: Integrating Financial Accountability

Effective cost optimization is not just a technical challenge; it’s also a cultural one. Adopting a FinOps mindset is key to long-term success.

  • Visibility and Governance: Provide teams with clear visibility into their Snowflake consumption. Use dashboards and tagging to track costs by project, team, or application.
  • Cost Allocation: Implement chargeback or showback models to make data teams accountable for their own spend. When teams see the direct financial impact of their workloads, they are more motivated to optimize.
  • Collaboration: Foster collaboration between finance, engineering, and business teams. This ensures that cost-saving initiatives are aligned with business priorities and that trade-offs between cost and performance are made consciously.

By combining technical optimization with financial governance, organizations can achieve significant and sustainable cost savings with open-source orchestration.

Where Proactive Cost Control Pays Off

Implementing orchestrated cost controls delivers tangible benefits across various use cases:

  • Daily ETL/ELT Pipelines: Ensure compute-intensive transformation jobs only run when new data is available and that the warehouse suspends immediately afterward.
  • BI and Reporting: Schedule warehouse activity to coincide with peak reporting hours, keeping it suspended during nights and weekends.
  • Ephemeral Dev/Test Environments: Automatically create and tear down warehouses for CI/CD runs, ensuring you only pay for compute during testing.
  • AI/ML Feature Engineering: Manage complex, multi-stage data preparation workflows, activating high-powered compute only for the duration of the task.

You can explore practical implementations in Kestra’s Snowflake blueprints, including patterns for querying data and running dbt transformations.

Ready to take control of your Snowflake spend? Explore Kestra’s capabilities for declarative data orchestration.

Frequently asked questions

Find answers to your questions right here, and don't hesitate to Contact Us if you couldn't find what you're looking for.