The Cost of Your SQL Style: FinOps for Data Teams

01

What problem made SQL cost a six-figure concern?

Cloud data warehouses charge per query based on compute consumption (Snowflake credits, BigQuery slots, Redshift node-hours). This pricing model means that SQL style, query structure, and materialization choices directly determine cost. Two queries producing identical results can differ in cost by 10x to 50x depending on how they are written.

I audited 3 Snowflake deployments in 2024 and 2025, each spending between $100,000 and $200,000 annually on warehouse compute. The audits revealed that 60% to 72% of compute costs were driven by fewer than 15% of queries. These expensive queries shared common patterns: full table scans where partition pruning was possible, repeated computation of the same intermediate results across multiple models, and over-materialized tables that were rebuilt daily but consumed weekly.

The total annual spend across the 3 deployments was $412,000. The optimized spend, after applying the patterns documented below, was $187,000. The $225,000 annual savings required no changes to business logic, no removal of features, and no reduction in data freshness.

02

What query patterns created the largest cost impact?

Three patterns accounted for 78% of the excess cost:

Pattern 1: Unfiltered scans on large tables. Snowflake’s micro-partition pruning can skip 90% or more of a table’s storage when queries filter on the clustering key. But 34 of the most expensive queries filtered on non-clustered columns, forcing full scans of tables with 50 million to 400 million rows. Reclustering 8 tables on their most-queried filter columns (typically date and customer_id) reduced scan costs for those queries by 85%. The reclustering itself cost $340 in compute and took 4 hours.

Pattern 2: Repeated intermediate computation. 11 dbt models computed the same customer lifetime value calculation independently, each running a 47-second query against the same base tables. Extracting this into a single materialized intermediate model (refreshed once daily) reduced compute from 11 executions of 47 seconds to 1 execution of 47 seconds plus 11 lightweight reads from the materialized result. Monthly savings: $2,100.

Pattern 3: Over-materialization. 23 tables were materialized (rebuilt from scratch) on every dbt run, executed 4 times daily. 14 of these tables changed meaningfully once per day or less. Converting them to incremental models (appending only new or changed records) reduced their average build time from 90 seconds to 8 seconds per run. For 14 tables running 4 times daily, this saved 4,592 seconds of daily warehouse time, approximately $1,400 per month in compute.

03

What were the measurable outcomes?

Beyond query optimization, I implemented 3 additional cost controls. First, warehouse auto-suspend reduced from 5 minutes (the default) to 60 seconds for interactive warehouses, saving idle compute during gaps between queries. Second, I separated workloads into purpose-specific warehouses: a small warehouse for dbt development queries, a medium warehouse for production builds, and a large warehouse for the 3 weekly analytical queries that required heavy computation. Previously, all workloads ran on a single large warehouse, meaning development queries consumed large-warehouse pricing.

Third, I implemented query cost tagging. Every dbt model and BI query now carries a cost attribution tag, enabling monthly cost allocation to teams and use cases. This visibility alone changed behavior: when the marketing analytics team saw their dashboards consumed $4,200 per month, they voluntarily reduced refresh frequency from hourly to every 4 hours for 6 dashboards that nobody checked more than twice daily.

04

What would I change in hindsight?

I would implement cost tagging on day one of any warehouse deployment, not as a retrospective audit. Every query should carry attribution metadata from the moment it runs. The cost visibility alone changes team behavior before any optimization is applied. Two of the 3 organizations I audited had no query cost attribution, meaning no team knew what their queries cost. Invisible costs are unmanaged costs.

I would also establish a weekly “cost review” ritual, 15 minutes of examining the top 10 most expensive queries from the past week. At one organization, I found that a single analyst’s ad-hoc query (a cross-join on two large tables, likely accidental) cost $890 in a single execution. This was discovered in the monthly audit, 3 weeks after it ran. A weekly review would have caught it within days.

The deeper lesson is that FinOps for data teams is not a project with a completion date. It is a continuous discipline, like code review or testing. The moment you stop paying attention, costs drift upward. Query patterns change, new models are added, warehouse sizes creep, and within 6 months, you need another audit. The organizations that maintain cost discipline are those that build it into weekly operations, not those that run annual optimization sprints.