Leading Consumer Tech Company
35%
COMPUTE
[ abstract ]
We ran eight scheduled scans against a leading consumer tech company's dbt repo. Each finding arrived as a PR with an equivalence report attached. The team merged 110 of them, 35% of warehouse compute came off, and no model's output changed. The finding that mattered most wasn't about cost: two revenue definitions that disagreed by 0.4%.
| repo | Their dbt project |
| scans | 8, on a schedule |
| output | one PR per finding, with proof |
| tolerance | 0.01% on any number |
| PRs merged | 110 |
| compute removed | 35% |
[ context ]
Nobody on the team did anything wrong. The repo grew the way every dbt repo grows: a model copied to get a dashboard out on time, an hourly job nobody moved to daily, a full refresh that could have been incremental. Each one costs a little. Together they were about a third of the bill.
Finding them isn't hard. Proving a change is safe is. A cleanup PR nobody can verify just sits in review, so the scans only mattered if every PR could show that nothing downstream would move.
[ method ]
- 01
Scan
Eight scans on a schedule: dead models, duplicates, divergent logic, full refreshes that could be incremental, jobs running more often than anyone reads them, and a few more.
- 02
Propose
Each finding became a PR: the change, the models it touched, and every downstream reader in Looker, Hightouch and notebooks.
- 03
Prove
The change ran on a 4.20% scale model. If any row count, sum, null profile or distribution moved by more than 0.01%, the PR was blocked.
- 04
Review
Reviewers came from CODEOWNERS. Their engineers merged or closed each one.
[ the run log ]
Eight scans. One finding that mattered.
84
Incremental conversion
full-refresh models that didn't need to be
180
Unused models
no downstream, no exposure, still billed
14
Divergent logic
two revenue definitions, 0.4% apart
31
Duplicate logic
same grain, two names
62
Frequency optimization
hourly jobs that moved daily
209
SQL optimization
scans the router could skip
19
Table merges
same grain, cheaper as one
7
Right-sizing
warehouse class above the workload
fct_revenue
net of refunds, booked at capture
mart_revenue
gross, booked at authorized
[ what missed, and why ]
Not everything passed. The check blocked PRs that would have changed a number, and those went back to be reworked or closed:
incremental conversions
Switching a full refresh to incremental dropped late-arriving events that landed after the window.
showed up as · row counts short on recent days
fix · added a lookback window, then it matched
table merges
Two models at the same grain, but one filtered test accounts and the other didn't.
showed up as · distinct users differed
fix · closed; they weren't really duplicates
divergent logic
fct_revenue booked revenue at capture, net of refunds. mart_revenue booked it at authorization and left refunds to a later mart.
showed up as · revenue 0.4% apart
fix · not something an agent should decide; see below
[ result ]
| compute removed | 35% |
| PRs merged | 110 |
| divergent logic | 14 |
| unused models | 180 |
| models with drift | 0 |
[ who did what ]
The 0.4% couldn't be merged automatically, because picking the right definition is a business call. The PR laid out the difference row by row, and their analysts chose capture, net of refunds. Everything else, the engineers reviewed and merged like any other PR.
“Two revenue numbers, 0.4% apart, for a year. With the proof attached, our analysts closed it in an afternoon.”
[ notes ]
- n1
Divergent logic is the one scan an agent can't finish alone. It can show you that two numbers disagree and exactly why. Someone still has to decide what the number should mean.
- n2
Zero drift here means zero drift on the models the PRs touched. The 14 divergent definitions were a disagreement that already existed, and it's now written down.
[ read next ]
Working on something like this? Chat with Founders →