[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"post:cloud-data-warehouse-cost-optimization":3},{"id":4,"slug":5,"title":6,"excerpt":7,"body":8,"tags":9,"read_minutes":14,"status":15,"published_at":16,"updated_at":17},"732de24e-2fbe-49ef-b372-ff0b25fcc066","cloud-data-warehouse-cost-optimization","Cost Optimization in Cloud Data Warehouses: A FinOps Playbook","Snowflake, BigQuery and Databricks bills rarely explode overnight — they creep. Practical queries and settings to find idle compute, fix clustering, and stop paying for warehouses nobody is using.","\u003Cp>Cloud data warehouse bills rarely explode overnight. They creep: a warehouse left on XL after a one-off backfill, a dashboard refreshing every five minutes for a team that checks it weekly, a dev environment that never suspends. By the time finance asks questions, nobody remembers which knob was turned.\u003C\u002Fp>\u003Cp>With engineering leadership under real economic pressure, FinOps has moved from a nice-to-have to a quarterly OKR. The good news: the biggest savings usually come from a handful of unglamorous fixes, and the warehouse itself will tell you where they are.\u003C\u002Fp>\n\u003Ch2>Find the idle compute first\u003C\u002Fh2>\u003Cp>Start where the money is: compute, not storage. In Snowflake, query ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY and join it against QUERY_HISTORY — any warehouse burning credits with near-zero queries per hour is your first target. In BigQuery, the INFORMATION_SCHEMA.JOBS view exposes slot usage per job; sort by total_slot_ms and you will usually find one scheduled query responsible for a shocking share of spend.\u003C\u002Fp>\u003Cp>Then fix the settings that let idleness cost money. Snowflake's auto-suspend default of ten minutes is generous — most interactive warehouses do fine at sixty seconds. In Databricks, enforce auto-termination on all-purpose clusters and push scheduled work onto job clusters, which are billed at a lower rate and die when the job does.\u003C\u002Fp>\n\u003Ch2>Make the pruning do the work\u003C\u002Fh2>\u003Cp>The second lever is scan efficiency. A well-chosen clustering key in Snowflake — or partitioning plus clustering in BigQuery — means queries touch a fraction of the data. Cluster on the columns your WHERE clauses actually filter by (almost always a date plus one high-cardinality business key), and check SYSTEM$CLUSTERING_INFORMATION before paying for automatic reclustering on tables that don't need it.\u003C\u002Fp>\u003Cp>Beware the opposite failure too: clustering everything. Reclustering costs credits on every load, so a table that is only ever full-scanned gains nothing and pays constantly.\u003C\u002Fp>\n\u003Ch2>Make cost a metric, not an audit\u003C\u002Fh2>\u003Cp>One-off cleanups decay. The teams that keep bills flat treat cost like latency: a per-team dashboard fed by the metering views, budget alerts on anomalies, and a monthly review of the ten most expensive queries. When engineers can see the cost of a query next to its runtime, the expensive habits fix themselves.\u003C\u002Fp>",[10,11,12,13],"FinOps","Snowflake","BigQuery","Databricks",8,"published","2026-07-08T00:00:00Z","2026-08-27T16:17:41.412599Z"]