Field note · August 27, 2026
Should I use dbt?
If you have more than a handful of SQL models and more than one person editing them, yes — and mostly for reasons that have nothing to do with the too
A question that came in more than once, so the answer goes here.
Should I use dbt?
If you have more than a handful of SQL models and more than one person editing them, yes — and mostly for reasons that have nothing to do with the tool.
What it actually gives you: version control on transformation logic, a dependency graph that is derived rather than maintained, tests that live next to the models, and documentation that is at least adjacent to the truth.
You can have all of that without dbt. Almost nobody does, because the discipline is the hard part and the tool supplies it as a default.
Where it goes wrong: treating every model as a materialised table, and ending up with a warehouse full of intermediate results nobody reads and everyone pays for. Views are free to store and the default worth starting from; materialise when a query is slow enough to justify it, not preemptively.
The second failure is a dependency graph that mirrors the source systems rather than the business. If your model names read like the upstream tables, you have moved the mess rather than resolving it, and every analyst still needs to know which of four order tables is the real one.