Change without fear
Modular, version-controlled models with tests mean a change is reviewed, tested and reversible, not a leap of faith.
One file, copied logic. Any edit can break what you cannot see.
Small, named SELECTs. Each change is a readable diff you can revert.
- dbt build passed
- all data tests passed
- 1 review approved
Reviewed, tested and reversible in git. A change stops being a gamble and becomes a routine step.
Most data teams have one transformation nobody wants to touch. It works, more or less, but it is a tangle of hand-rolled scripts that only the person who wrote it understands. Every change to it is a gamble: a small edit can break something three steps downstream that nobody saw coming, and the only way to find out is to ship it and wait.
The problem
Spaghetti ETL is expensive in two quiet ways. The first is maintenance: when logic is copied and pasted across scripts, a single rule change means hunting down every copy, and missing one means a silent wrong number. The second is key-person risk. When the structure lives only in one engineer’s head, the team cannot move faster than that one person, and onboarding a new hire means months of reverse-engineering.
What dbt does about it
dbt replaces tangled scripts with modular, version-controlled models. Each model is a single SELECT statement that dbt turns into a table or view, and each one references the others by name rather than repeating their logic. Because every model is a file in git, a change is a reviewable diff, not an invisible edit to a shared script. You can see what moved, ask why, and revert it cleanly if it was wrong. Continuous integration runs the tests on the proposed change before it merges, so the gamble becomes a checked, reversible step.
What it looks like
An analyst needs to change how revenue is calculated. Instead of editing a 600-line script and hoping, they open the revenue model, adjust one SELECT, and open a pull request. The diff shows exactly the lines that changed. CI runs the tests, a colleague reviews it, and it merges. If a downstream report looks wrong a week later, the team reads the git history, finds the change, and reverts it in minutes. The same discipline gives the team one agreed way of working, so a new hire can read the project rather than interview its author.
How we think about it
We treat transformation as software, because that is what it is. Version control, code review and tests are not overhead, they are the things that let a team change data confidently and often. Our aim is simple: make every change small, visible and reversible, so shipping a fix stops feeling like a risk and starts feeling routine.
Change without fear, in short.
Do we have to rewrite everything to start?
No. dbt wraps the SQL you already have. You bring an existing query, paste the SELECT into a model file, and it becomes a managed, version-controlled object. Teams usually migrate the highest-risk transformations first and leave the rest until there is a reason to touch them.
What happens to our existing SQL?
It stays SQL. dbt does not ask you to learn a new language or move your data. Each model is a single SELECT statement that dbt turns into a table or view on your warehouse. The skill your team already has carries straight over.
How does review actually work?
Every model lives in git, so a change shows up as a readable diff in a pull request. A colleague can see exactly what moved, comment on it, and approve it. CI runs the tests on the proposed change before it merges, so review is informed, not a rubber stamp.
What does DRY mean here?
Do not repeat yourself. Common logic lives in one model that others reference, so a definition is written once and reused everywhere. Fix it in one place and every downstream model picks up the fix, instead of the same logic drifting across a dozen copied scripts.
Keep exploring
One agreed way of working
Bronze, silver, gold layers and reusable models give every team one contract, so questions become queries, not rebuilds.
Faster, cheaper runs
Incremental models process only what changed, so runs are faster, compute costs less, and the warehouse is under less strain.
Change shared models without breaking everyone
When a shared model changes, it can silently break every team downstream. Model versions and contracts let a central team ship a new version while consumers migrate on their own schedule.
Want this for your data?
If this is how you want your team to work, we should talk.