Snowflake Cost Per Query: Complete Guide to Query-Level Cost Attribution

Picture this: Your Snowflake bill has just hit a $50,000 all time high for the month. You have no idea what queries keep hiking up the price. You’re flying blind and optimizing in the dark. 

If this is you, you’re not alone. Many Snowflake customers understand what drives their warehouse level costs, but can’t dig deep to query-level cost attribution level. That gap is the difference between an out of budget and within budget month. 

The good news? Calculating Snowflake cost per query is doable. And it’s vital to truly understand Snowflake cost optimization if you’re not investing in a third-party tool or a consultant.

In this article, we’ll break down: 

• Why query-level cost attribution is so important
• Easier, but less in-depth calculation strategy
• A more advanced calculation approach
• Snowflake’s native query attribution
• How to streamline costs with third-party tools

Why Query-Level Cost Attribution Matters

Remember: Snowflake’s billing model means you’re paying for every second your virtual warehouses are running – and you have a minimum 60-second charge every time a warehouse resumes. 

Snowflake will give you a warehouse level cost breakdown, but what it doesn’t show you are the queries behind your bill. 

This is why you need to understand the cost per query. Query-level cost attribution reveals situations like: 

• That single poorly optimized dashboard query costing you $2,000 every month
• Redundant data transformations running multiple times and churning out identical results
• Those developmental queries running on production-sized warehouses
• Idle time queries eating up 40% of your compute budget

Now that you know why keeping an eye on Snowflake cost per query is so important, let’s take a look at two approaches to calculate costs. 

The Easier Approach: Execution Time x Billing Rate

There’s an easy way and a harder way to calculate your Snowflake cost per query. The more straightforward path is easier to do, but comes with a few problems. 

All you have to do is take your query’s execution time and multiply it by your warehouse billing rate. 

Example calculation: 

Say you have a: 

• Query that runs for 10 minutes on a Medium warehouse
• That medium warehouse costs you four credits per hour 
• At $3 per credit, you’re looking at: 10/60 hours x 4 credits/hour x $3/credit = $2

SQL Implementation

WITH warehouse_sizes AS (
    SELECT 'X-Small' AS warehouse_size, 1 AS credits_per_hour UNION ALL
    SELECT 'Small' AS warehouse_size, 2 AS credits_per_hour UNION ALL
    SELECT 'Medium' AS warehouse_size, 4 AS credits_per_hour UNION ALL
    SELECT 'Large' AS warehouse_size, 8 AS credits_per_hour UNION ALL
    SELECT 'X-Large' AS warehouse_size, 16 AS credits_per_hour UNION ALL
    SELECT '2X-Large' AS warehouse_size, 32 AS credits_per_hour UNION ALL
    SELECT '3X-Large' AS warehouse_size, 64 AS credits_per_hour UNION ALL
    SELECT '4X-Large' AS warehouse_size, 128 AS credits_per_hour
)
SELECT
    qh.query_id,
    qh.query_text,
    qh.execution_time/1000/3600) * wh.credits_per_hour * 3 AS query_cost
FROM snowflake.account_usage.query_history AS qh
INNER JOIN warehouse_sizes AS wh
    ON qh.warehouse_size=wh.warehouse_size
WHERE
    start_time >= CURRENT_DATE - 30

The Problem With the Easier Approach

This approach is simple for a reason. It gives you an idea of your spend, but not the full picture. 

• Idle time excluded: You’re paying for the entire active time of a warehouse, including idle periods. If a query runs for six seconds but causes a warehouse to idle for four minutes before auto-suspension, you’re paying for a full four minutes and six seconds.
• Concurrency distorts costs: When multiple queries run simultaneously, you’re charge for total warehouse time, not individual query time. Two 20 minute queries running concurrently would cost you 20 minutes, not 40. 
• Query metadata makes group difficult: If you’re using Looker, dbt, or Tableau, you should know each injects unique metadata into every query execution, making identical queries look different:

-- First execution
SELECT id, created_at FROM orders
-- {"user_id":181,"history_slug":"9dcf35a"}

-- Second execution 
SELECT id, created_at FROM orders
-- {"user_id":181,"history_slug":"1kal99e"}

Without proper text processing, these identical queries won’t be grouped together for cost analysis. 

There is a way to remove comments and metadata like this: 

SELECT
    -- Remove /* comment */ blocks
    REGEXP_REPLACE(query_text, '(/\*.*\*/)') AS _cleaned_query_text,
    -- Remove -- single line comments 
    REGEXP_REPLACE(_cleaned_query_text, '(--.*$)|(--.*\n)') AS cleaned_query_text
FROM snowflake.account_usage.query_history

Use this code to group functionally identical queries no matter the injected metadata. 

Note: Test this regex pattern with your specific metadata format as syntax may vary. 

The Advanced Approach: Proportional Credit Allocation

The more difficult, but accurate, method starts with actual warehouse charges from warehouse_metering_history and allocates credits according to execution time within every hour. 

For example, if a warehouse consumes 100 credits in an hour and three queries ran (two for 10 minutes, one for 20), credits are allocated proportionally with this method: 

• Query 1 (10 minutes) 25 credits
• Query 2 (20 minutes): 50 credits
• Query 3 (10 minutes): 25 credits

This approach automatically accounts for idle time because it distributes queries that ran during that period. 

Implementation How-To

Don’t be intimidated by this being called an “advanced” approach. Here’s how to implement these calculations into your regular workflow: 

1. Filter queries running on warehouses (excluding cloud service-only queries) 
2. Calculate execution start time by adding queue and compilation time to start_time
3. Generate hourly time slots for the analysis period
4. Join queries to hours they were executed in
5. Calculate proportional time for each query used within every hour
6. Allocate actual credits from warehouse_metering_history proportionally 

Snowflake’s Native Query Attribution

Snowflake actually does have a query attribution history for you to look at native cost attribution. It was released in July 2024. But it has a few limitations: 

• Data only available from July 1, 2024 onwards
• Short queries (under 100ms) are excluded
• Idle time isn’t included in attribution costs
• Data appears with up to 6-hour delays
• Some users report inflated costs for short queries

Snowflake’s native query attribution is promising, but it’s not there yet. Many organizations still turn to a custom logic for more accurate readings. 

How to Identify Your Most Expensive Queries

Now that you know how to find your Snowflake cost per query, here’s how to quickly spot your most expensive queries: 

SELECT
    md5(cleaned_query_text) as query_signature,
    sum(query_cost) as total_cost_last_30d,
    total_cost_last_30d * 12 as estimated_annual_cost,
    max_by(query_text, start_time) as latest_query_text,
    avg(execution_time/1000) as avg_execution_time_s,
    count(*) as num_executions
FROM query_history_enriched
WHERE start_time >= dateadd('day', -30, current_date())
GROUP BY 1
ORDER BY total_cost_last_30d DESC
LIMIT 100

Use this to find those queries driving thousands of costs annually – and monthly. Those are prime candidates for optimization. 

Streamline Cost Optimization With Purpose-Built Tools

You know how to build your DIY solution for figuring out costs per query, but this method – and other cost measurement solutions – are often unsustainable long-term. You’re facing an uphill battle against: 

• Constant updates for new Snowflake releases
• Handling the complexity of multi-cluster and auto-scaling warehouses 
• Long-term cost analyses require robust data retention strategies
• Technical solutions may not be best for business stakeholders

You don’t have to spend entire engineering cycles building and maintaining cost attribution systems. Many organizations are turning to Snowflake cost optimization platforms like Yuki for help. These solutions provide: 

• Automated cost attribution with real-time accuracy
• Query optimization recommendations based on execution patterns
• Warehouse right-sizing and automated scaling
• Budget alerts and governance to prevent cost overruns
• Easy to use and understand executive dashboards perfect for stakeholders

Plug-and-play tools like Yuki mean calculating – and optimizing – your queries with ease, no additional dev lift needed. 

Ready to gain complete visibility into your Snowflake costs? Yuki’s intelligent cost optimization platform provides automated query-level attribution, optimization recommendations, and governance controls – all without engineering overhead. 
Contact us to get your free demo today.