Warehouse spend does not creep. It jumps, usually in the month after someone connects a BI tool with auto-refresh enabled, or a well-meaning analyst schedules an hourly job that scans the full history every run. The good news is that the cause is nearly always a small number of queries, and finding them takes an afternoon.
01Attribute the spend before optimising anything
Every major warehouse exposes query history with bytes scanned, execution time and the user or service that ran it. Pull the last thirty days, group by query fingerprint, and sort by total cost rather than by individual query cost. The expensive thing is usually a cheap query running twelve thousand times, not one enormous one.
That distinction matters because the fixes are different. A cheap query running constantly is a scheduling problem or a missing cache. A genuinely expensive query is a modelling or partitioning problem. Optimising the wrong one produces a modest improvement and a lot of wasted effort.
| Source | Share of spend | Usual cause |
|---|---|---|
| BI tool auto-refresh | 30-50% | Dashboards refreshing on a timer nobody set deliberately |
| Scheduled transformations | 20-40% | Full rebuilds where incremental would do |
| Ad hoc analyst queries | 10-20% | SELECT * on wide tables during exploration |
| Reverse ETL and syncs | 5-15% | Full-table syncs on a short interval |
| Actual application queries | Often smallest | Usually already tuned |
02Partitioning and clustering, or the lack of it
A query filtering on a date against an unpartitioned table scans everything. The same query on a table partitioned by that date scans a fraction. This one property accounts for more warehouse waste than any other, and it is invisible until someone looks at bytes scanned rather than wall-clock time.
Partition on the column your queries actually filter by - usually an event or transaction date - and cluster on the next most common filter. Then verify by checking bytes scanned before and after, because a partition on a column nobody filters by costs you maintenance and saves nothing.
03Incremental models instead of full rebuilds
Rebuilding a table from all history on every run is simple, correct and increasingly expensive as history grows. Incremental models process only new or changed rows, which turns a cost that scales with total data into one that scales with daily volume.
The complication is late-arriving data and updates to old rows. The pattern that works is incremental for the recent window, with a periodic full refresh - weekly or monthly - to catch corrections. That keeps daily cost low while bounding how long an error can persist unnoticed.
| Fix | Effort | Typical saving |
|---|---|---|
| Turn off unused dashboard auto-refresh | Minutes | Often 10-30% |
| Add partitioning to the largest tables | Hours | 20-50% on affected queries |
| Convert full rebuilds to incremental | Days | 40-80% on those models |
| Right-size warehouse compute | Hours | 10-25% |
| Auto-suspend idle compute | Minutes | Varies, sometimes large |
04Compute sizing and auto-suspend
Larger compute is not proportionally more expensive if it finishes proportionally faster - the same work, less time. Where it becomes expensive is idle time, and warehouses left running between queries bill for doing nothing at all.
Set aggressive auto-suspend, usually a minute or two of idle. Then separate workloads onto their own compute so an analyst's exploratory query cannot slow the scheduled pipeline, and so you can attribute cost by workload rather than guessing.
05Make cost visible or it will come back
The reason warehouse costs regress is that nobody sees them until the invoice. Put spend by team and by model on a dashboard the data team looks at weekly, and alert on week-over-week increases above a threshold.
The most effective control we have seen is surfacing estimated cost in the pull request that adds or changes a model. An engineer who can see that their change adds meaningfully to the monthly bill usually reconsiders before merging, which is considerably cheaper than discovering it two invoices later.
Topics
Priya Iyer
Staff Engineer · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer