Cutting a five-figure monthly cloud bill out of a large data estate

Where it started

An enterprise data estate past four thousand dbt models — models, tests, snapshots and seeds — running across Snowflake, Databricks and Azure, the whole environment provisioned as code with Terraform. Well-built, by capable people, and growing fast enough that nobody could explain the cloud bill any more.

That’s the normal state of affairs at this size. Estates don’t become expensive all at once. They accumulate decisions that were reasonable when they were made, and past a certain point no single person holds the whole picture.

What I found

Ingestion had sprawled. Dozens of Databricks ingestion notebooks doing near-identical work, each maintained separately, each drifted a little from the others. I consolidated them into a single templated framework. That cut compute, but the more valuable outcome was that data quality stopped depending on which copy of the logic you happened to hit.

CI was rebuilding far more than it needed. The dbt project was doing broad rebuilds on every pull request, which meant paying warehouse credits for the privilege of reviewing code. On a busy repository that quietly approaches the cost of running production. Scoping CI to what actually changed took a fraction of that straight off the bill.

Compute was sized for peak and running at idle. All-purpose clusters left up because someone needed one once, auto-suspend set generously enough that it effectively never fired. I moved the workloads onto right-sized, auto-terminating job clusters. This is usually the easiest money on the table and often the largest single line.

Models that should have gone incremental years ago were still full-refreshing. The most expensive pattern in dbt and the hardest to fix late, because by then downstream models quietly depend on the rebuild behaviour. Converting them meant untangling those dependencies first, which is where most of the work actually went.

What it was worth

A five-figure sum a month, recurring, without ripping anything out or migrating to anything. No new platform, no bigger warehouse — the same estate, running the way it should have been.

The part I’d emphasise to anyone facing the same bill: attribute spend to workloads and teams before you change anything. You can’t fix what nobody owns, and the ranking of what to do first is entirely different once you can see who is spending what. Then set guardrails — budgets, resource monitors, query policies — because the conditions that produced the leak haven’t changed, and it will otherwise reopen inside six months.

The fix at this scale is almost always architectural. A bigger warehouse is just the expensive way to postpone the question.