I have spent more time than I would like trying to understand , and I still do not fully get it. Not the mechanics; those you can learn in a weekend. I mean the devotion. dbt is the most talked-about tool in analytics by a wide margin, and every time I set it beside the platforms I have spent a career with, it seems to do less, not more, to make my actual job easier. So how did it win the argument this completely? I went looking, and the answer was not the one I expected.

My first theory was generational. Data work used to be a quiet, slightly esoteric corner of the business, staffed mostly by people who wandered in from finance or operations or reporting. Then it became one of the hottest jobs in tech and pulled in a wave of people trained as programmers. Maybe the divide was just age and schooling: veterans who learned the craft on integrated suites, against newcomers fluent in and Git who wanted their data work to look like software. I asked around. In my small and thoroughly unscientific sample it even seemed to hold, though back to front from the lazy guess, with the older and more technically deep people favouring the integrated platforms and the younger, less technical ones favouring code-first dbt. Too neat, and it did not survive a harder look.

What actually separates the camps has little to do with age, years in the field, or how much Python anyone wrote at university. The real split is the operating model each side optimises for. One optimises for metadata, generated patterns, lineage, repeatability, , source-change propagation, and long-lived operational control. The other optimises for transparent transformation logic, Git workflows, pull requests, tests next to the code, fast iteration, and low procurement friction. Both are coherent. They fear different failure modes, and they can look at the same tool and see opposite things. The public evidence for exactly who sits where is thinner than I would like, so I hold the reading loosely, but it changed the question for me. The real one is which operating model a team should want, with dbt as the natural output of one particular answer.

The claim on trial

Somewhere near you, a data team is celebrating. They have just moved four hundred transformations out of stored procedures and into dbt. Everything lives in Git now. Every model has tests, every pull request gets a review, and the DAG renders beautifully in the docs site. By the standards of the , they have done everything right.

The claim behind that celebration is the one I want to test: that dbt brought software engineering discipline to analytics, and that hand-written in version control is therefore what serious data teams do. It has been the default assumption since about 2020. In the usual telling, graphical and metadata-driven tools are what you graduate from.

That telling misses who is actually arriving. Some teams do come from mature platforms, or or the like, and for them the move to dbt is a lateral step at best on the automation they leave behind. Far more come from somewhere messier: home-grown pipelines stitched from scripts, scheduled SQL, and cron, built through the 1995-to-2020 stretch when perfectly good automation tools already existed and were quietly ignored. Both crowds are converging on dbt, and they are not the same story. One is trading generation for hand-craft. The other is getting version control for the first time and calling it modernisation.

My bias, so you can weigh it. I come from the platform side of that fence. I spent years with Informatica, BusinessObjects Data Services, and Talend Studio, and I have written what must add up to miles of SQL, along with perl, Easytrieve, bash, DOS batch, and PowerShell. My background is computer engineering, C, C++, and Java, before data modelling and systems design took over, and these days I co-write code with agents in most mornings. Typing is not the problem. My dbt experience is not production experience: official training, a lot of documentation and video, architecture reviews rather than a project I have run end to end. But I built dbt's surface features before, more than once, in the years before dbt existed. Templated SQL generation, dependency ordering, lineage tracking, data validation. So did half the field. We each rolled our own, shaped to one client and one warehouse, and none of them talked to each other. That is the real thing dbt did: it turned a thousand private conventions into one shared framework. A framework is worth having. It is a different claim from the one on trial, which puts the hand-writing at the centre of the craft.

What the claim gets right

Start with the strongest version of the claim, because it is genuinely strong. But first correct a piece of folklore that usually rides along with it: that before dbt there was no version history, no review, no way to see what depended on what. That is not true of the mature tools. Informatica has had a versioned repository, with check-in, check-out, and object history, for as long as most of us have worked . Talend Studio jobs have lived in Git for just as long . BusinessObjects universes, data-quality rule sets, and business glossaries have carried audit trails for years. The history was real. What it was not was uniform: it lived in a dozen proprietary shapes, some diffable and some not, and reading it took a human who knew the tool.

Where the folklore holds is the other population. The home-grown estate, built from scripts and scheduled SQL and whatever glue was to hand, genuinely had none of this. Dependencies lived in people's heads, run order was a diagram someone drew once, and because many of the people building these pipelines were not programmers, a great deal of it never went near version control at all. That is the mess dbt walked into, and on that ground it did something plainly good. It put the logic in files, the dependencies in a graph, the tests next to the code, and forced the whole thing into Git whether the author had ever used Git or not . For a team that had been editing production SQL by hand on a shared drive, that is not a lateral move. It is a floor under the feet.

And for logic that genuinely encodes business meaning, code with review is the right home. A contested revenue definition deserves a pull request and a named reviewer. An exception rule that took three workshops to agree on should live somewhere a human can read it, diff it, and trace who changed it and why. If dbt had positioned itself only as the governance layer for that slice, there would be no argument to have. The trouble starts with what else ends up inside the project.

Open the project and count

Take the four-hundred-model project above and sort its models into two piles. Pile one: staging views that rename and cast columns, surrogate key generation, handling, historisation, hubs and links and satellites, conformance mapping, audit columns, scaffolding. Pile two: metric definitions, domain-specific business rules, curated marts, the logic someone actually argued about in a meeting.

In every large project I have been shown, pile one dwarfs pile two. The mechanics run to 80–90% of the estate. And pile one has a defining property: it is patterned. A type 2 dimension differs from the next type 2 dimension in table name, key columns, and tracked attributes. That is metadata. Given the metadata, the code follows mechanically, which is exactly why tools like and have generated it from a model for two decades, along with the deployment, the documentation, and the lineage .

dbt is very good at governing hand-written transformation logic. It is not, by itself, a cure for having too much of it.

Writing pile one by hand, four hundred times, is what I mean by an artisanal SQL factory: skilled people producing near-identical parts by hand, with craftsmanship standing in for tooling. Putting that factory under Git makes it a well-run artisanal factory. The parts are still hand-made and still vary in small accidental ways, and every source system change means a human editing files that a generator would have regenerated from the changed metadata.

dbt's own guidance concedes the point. The official project-structure guide recommends automatically generating all of the source YAML and staging boilerplate rather than typing it . Its legacy-migration guide starts by copying the old SQL into dbt and auditing the output against the original , which is a sensible migration path and also a plain description of moving the artisanal factory indoors.

The same transformation estate read two ways: as four hundred files to write, or as a thin human-owned layer above machinery a generator should produce. Author's illustration.

dbt is a layer, not a stack

The second thing the claim gets wrong is scale, and it gets it wrong in two directions at once. The small direction first: "it's just SQL" stops being true the moment the project matters. gives you control flow, environment-aware logic, and macros that behave like functions ; Python models exist for what SQL cannot express ; and a real project adds incremental strategy, backfills, environment separation, CI, orchestration, and compiled-SQL review. A macro library needs what any shared code needs: an owner, naming discipline, tests, and a deprecation plan. None of that is unwelcome. It is software, and someone has to run it.

The larger direction is the one teams forget. dbt is a transformation layer, and the comparison runs wider than dbt against a suite's transformation module. Set it beside everything the suite was quietly doing around that module: ingestion and , orchestration, end-to-end lineage and impact analysis, , scheduling and the runtime tuning that decides what a load costs, and the surfaces a modern stack is expected to carry on top, a , data-product management, a catalog, data- services, observability. On an integrated platform most of that is present because it came in the box. Choose dbt and you are choosing to source, wire together, and own each of those yourself. Composability is a real strength of the code-first world. It is also a real bill, and it arrives itemised.

This is where the analyst-heavy team gets into trouble, and the trouble is not about talent. Give a team of SQL-fluent analysts an open dbt mandate and the first quarter looks great: models multiply, ship. The macro framework nobody owns and the incremental models nobody tested against late-arriving data surface later, load-bearing by the time they do. The analysts did nothing careless. dbt relocated platform engineering into their laps and did not mention it, where a suite would have shipped most of those decisions as defaults.

The precise version of the critique

A team leaving a hand-made stored-procedure estate should ask why that estate became unmaintainable. If the answer is sprawl the team could not control, moving the sprawl into dbt gives it better folders and a nicer graph. The operating model that produced it is intact.

And here is the assumption underneath the whole code-first default: that the data team is a team of programmers. A lot of them are not. Plenty of good warehouse and work is done by people who are not full-time engineers and never wanted to be, doing the data part on the side of a job that is really project planning, or logistics, or finance. Programmer tools and programmer workflows are wonderful for programmers. Handing them to everyone else and calling it discipline is how you get a fragile platform maintained by people who were hired to do something else.

Both camps are building the same tool

The third piece of the claim is the workflow: Git, code review, CI, the things the graphical tools supposedly lacked. That was true in 2020. It is not a moat in 2026, and the wall is coming down from both sides at once.

From the platform side, the graphical suites have grown code-native spines. 's Talend Cloud pipelines went declarative in June 2026: the whole pipeline defined in YAML, schema validation in the editor, -native review, branching, and environment promotion , and an announcement that openly assumes an will write the YAML against the published schema . Informatica, now owned by , went the same way from a different angle, exposing its platform headless through endpoints that agents and developer tools call directly . It is the same headless, agent-and-code-driven shape as dbt's, reached from the platform side rather than the code side.

From the code side, dbt has grown a face. It shipped Canvas, a drag-and-drop visual editor whose models compile to SQL and land in Git, pitched at people without an analytics-engineering background , and dbt to author models and generate SQL, tests, and docs from natural language .

The merger, completed in June 2026 , went further than a face. dbt stopped being the low-friction independent: the pitch now belongs to a combined ingestion-and-transformation vendor selling the whole pipeline, and Fivetran will run your dbt transformations automatically once a connector sync lands . Fivetran had already bought in May 2025 for , billing itself as the first end-to-end data movement platform , and Tobiko Data that September for , so the combined company now owns two transformation frameworks. Count what one vendor now sells: ingestion, transformation, activation back into the business systems, a semantic layer, and the loads orchestrated end to end. That is an integrated suite in everything but the branding, assembled in thirteen months of shopping. If code-first were a genuinely different category of thing, its flagship would not have rebuilt the old category at the first opportunity. Both camps are building the same hybrid from opposite corners: generate the mechanics, review the semantics, drive it with an agent.

One counterargument deserves to be met head on, because it sounds decisive. Custom logic needs custom code, so you need a code-first tool. The premise is right and the conclusion does not follow. Every serious platform ships escape hatches: custom tasks in Qlik Compose , a SQL transformation in Informatica PowerCenter , reusable custom code in TimeXtender , hand-written scripts in WhereScape . So the real comparison is "generate the 80–90% and code the exceptions" against "code nearly everything and review it well," and put that way, I know which side I would ask to explain itself.

The platform is eating the tool

There is a sharper sign of the convergence, and it undercuts the loudest fear on both sides. The platforms have stopped competing with dbt. They are hosting it instead.

You can now run dbt Core inside as a first-class object, scheduled by Snowflake's own tasks, its DAG drawn in the console, its version pinned, with Snowflake's AI assistant scaffolding the models . runs dbt as a native task in Lakeflow Jobs, in the same pipeline as ingestion and streaming and the BI layer . runs a dbt job inside Data Factory, governance applied automatically, no to stand up . Rumour has it Qlik is looking into hosting the dbt runtime in too, though it is not on any public roadmap.

This matters for the lock-in argument, which both sides get to stop shouting about. The platform camp warned that code-first meant assembling and operating your own stack forever. The code camp warned that a suite meant a proprietary cage. Neither is quite true any more. Adopt dbt now, and if you later decide you want the automation, the lineage, and the operational plumbing the platforms hand you as standard, you do not rewrite. You move the project onto the platform and start augmenting: let the platform generate the mechanics, keep your hand-written models where they earn it, and converge, gradually, on one integrated set of pipelines with lineage that runs end to end through a single metadata layer. dbt turns out to be a reasonable on-ramp to the thing its advocates positioned it against.

The best argument is about agents

The strongest case for the code-first default right now barely mentions humans; it is about agents. Everything in dbt is text, and all of the text is in Git, which makes it a near-perfect substrate for AI-assisted work. There is no to click through, no proprietary canvas an agent cannot see, just files a language model is very good at reading and writing. If the future of this work is agents proposing changes and humans reviewing diffs, plain text in version control is exactly the shape you want the codebase to be. I find that persuasive.

I also think it is a narrower advantage than it looks, for two reasons. The platforms are racing to expose their own internals to the same agents: Qlik's YAML written to a published schema , Informatica's functions published as callable endpoints , the AI assistants now baked into Snowflake and Fabric. Under every GUI there was always code or configuration; what is new is that the vendors are surfacing it for agents to drive. Text for agents is becoming table stakes, not a dbt exclusive.

The second reason is what the agent is working on. Point it at a platform's components and it assembles pipelines from vetted, supported, upgradeable building blocks. When the vendor ships a better slowly-changing-dimension pattern or a faster incremental load, every project that used the component inherits the improvement. Point the same agent at hand-written code and you get more hand-written code: quick to produce now, but you already had three ways to load a dimension, and the agent will happily add a fourth. Cruft accrues at machine speed. Leaving is harder too, because metadata is portable in a way code is not. A model regenerates for a new engine or a new SQL dialect, or targets instead of SQL; an agent can translate a pile of bespoke SQL, but it hands you back another pile of bespoke SQL that nobody wrote, nobody owns, and no vendor supports.

Which is why I have stopped believing the semantic layer is obviously better as code. Better as something explicit, diffable, and reviewable, yes. That is not the same as hand-written SQL. It can be metadata or governed configuration as readily as a model file, and all three are increasingly -backed and agent-readable anyway. The one place code is clearly ahead is the agent's-eye view, and that is exactly the edge the rest of the industry is busy copying.

The best case for the factory floor

The strongest form of the rebuttal deserves respect. A generator has no judgement. It produces a wrong model with the same serene consistency as a right one, faster than any team of humans could, so a bad metadata model builds a bad warehouse at industrial speed. Generated artifacts can be opaque, diffs on them can be ugly, and a proprietary repository is a real exit cost. All of this is true, and none of it requires hand-writing the staging layer. The remedy is architects who own the metadata model, and generated output the team can open and read.

A chain of punched cards drives a monumental Jacquard loom weaving cloth with one motif repeated perfectly, while a small embroidery hoop nearby holds a single unique hand-stitched motif.
One chain of cards holds the pattern, the loom turns out every repeat, and the hoop keeps the one motif worth stitching by hand. Author's illustration.

What tips it, for me, is what generation does to the shape of the work. When the tool builds and orchestrates the bulk of the pipelines, delivery is faster and, in my experience, noticeably less error-prone; a generator does not mistype a hash key on the third Friday of the month. But the hours are the larger effect. A team freed from producing and reviewing mechanical SQL spends that attention on the data itself: whether the grain is right, whether that status field means what the source system pretends it means. Those are the questions that decide whether the warehouse can be trusted, and no amount of pull-request hygiene on boilerplate answers them.

I keep returning to the fact that I like code. I have written it for thirty years and now write it alongside agents daily. If typing speed were the constraint, agents have made typing nearly free, and you could argue the artisanal factory just hired cheap robot artisans. But generating boilerplate one at a time still produces four hundred individually authored files to review, test, and drift-check, where a metadata model produces one pattern, four hundred instantiations, and a single place to change when the pattern must change. Cheap typing is welcome. It does not compete with not needing the files at all.

The cause or the container

So run the diagnostic on your own estate before you choose the tool. Write down the five things that make the current system painful, and for each ask whether dbt changes the cause or only the . No version control, no tests, hidden dependencies, promotion by hand: dbt changes the cause, adopt it and mean it. Too much hand-built pattern work, weak modelling, no semantic ownership, analysts running production engineering: dbt changes the container and not the cause, so the sprawl regrows inside it with the same operating model behind the tidier folders.

The default I argue for in platform evaluations is the opposite of the fashionable one. Generation is the baseline for the repeatable machinery, and every hand-written transformation has to earn its place: a contested definition, or a genuine exception the business needs a person to debate line by line. Where that justification holds, give the code the full dbt treatment and mean it. Where it does not, ask why a person is typing what a model already knows.

I keep coming back to the shape of the work, because that is what the argument is really about. A project is mostly not a programming project. It is sourcing the right data, deciding what it means, getting the grain and the history right, and building marts a business can trust. Call it ninety-five percent data and five percent code. The code-first default takes a team's scarcest resource, the attention of the people who understand the data, and spends it reviewing staging boilerplate and arguing about macro structure. A generator has no better judgement than those people. It just refuses to spend them on the five percent, so the ninety-five gets the attention it deserved all along.

What I was really objecting to

Which returns me to the question I opened with. dbt never clicked for me because I had been optimising for the other operating model all along, and I had mistaken that preference for a verdict. For all that I like code, my objection was to the operating model dbt assumes: that you hand-build and govern machinery a model could generate, on the grounds that governing it well is what modern teams now do. That is a preference about how the work should be shaped, and I had been calling it a flaw in the tool.

None of which makes dbt bad. Looked at squarely, it is a large step up from hand-rolled everything, and for a team drowning in undocumented stored procedures it may be exactly the right move. I still do not think it beats the integrated automation suites, and the gap widens as a project grows in size and scope. Keeping a large dbt estate under control takes a discipline and a standing time cost, and that time is better spent on the actual deliverable, which is the data and the metadata that make it mean something.

dbt taught the industry that transformation logic deserves version control, tests, and review, and the industry needed that lesson. What it did not teach, and what the code-first default quietly forgot, is that governing the work is a separate question from choosing to do all of it by hand.

Final thought

Craftsmanship belongs in the model of the business, and in the few transformations that carry its meaning. Everything else is parts, and parts come off a press.

References25
  1. 1dbt Developer Hub, "Jinja and macros". docs.getdbt.com ↗ Accessed 2026-07-23
  2. 2dbt Developer Hub, "Staging: Preparing our atomic building blocks" (project-structure best practices). docs.getdbt.com ↗ Accessed 2026-07-23
  3. 3dbt Developer Hub, "Refactoring legacy SQL to dbt". docs.getdbt.com ↗ Accessed 2026-07-23
  4. 4dbt Labs (via PR Newswire), "dbt Labs Launches AI-Powered Features to Onboard Data Analysts into dbt", May 28, 2025. prnewswire.com ↗
  5. 5dbt Developer Hub, "About Canvas". docs.getdbt.com ↗ Accessed 2026-07-23
  6. 6Fivetran, "Fivetran + dbt Labs Complete Merger to Create the Data Infrastructure for Trusted AI Agents", June 1, 2026. fivetran.com ↗
  7. 7Qlik Developer Portal Changelog, "Declarative Pipelines for Qlik Talend Cloud Pipelines", June 30, 2026. qlik.dev ↗
  8. 8Qlik Cloud Help, "Manage your pipeline projects with version control". help.qlik.com ↗ Accessed 2026-07-23
  9. 9WhereScape, "WhereScape RED" product documentation and RED Templates (metadata-driven generation, manually created and template-generated scripts). wherescape.com ↗ Accessed 2026-07-23
  10. 10TimeXtender Support, "Customized Code and Custom Scripting in TimeXtender Classic". support.timextender.com ↗ Accessed 2026-07-23
  11. 11Qlik Compose Help, "Creating and managing custom ETLs". help.qlik.com ↗ Accessed 2026-07-23
  12. 12Informatica PowerCenter documentation, "SQL Transformation Overview". docs.informatica.com ↗ Accessed 2026-07-23
  13. 13dbt Labs, dbt-core repository (GitHub). github.com ↗ Accessed 2026-07-23
  14. 14dbt Developer Hub, "Python models". docs.getdbt.com ↗ Accessed 2026-07-23
  15. 15Informatica Documentation, "Version Control" (PowerCenter Repository Guide). docs.informatica.com ↗ Accessed 2026-07-23
  16. 16Qlik Talend Studio Help, "Best Practices: Git with Talend". help.qlik.com ↗ Accessed 2026-07-23
  17. 17Qlik (via Business Wire), "Qlik Delivers Agentic Data Engineering in Qlik Cloud to Help Enterprises Build Trusted Data for AI", June 30, 2026. businesswire.com ↗
  18. 18dbt Developer Hub, "About dbt Copilot". docs.getdbt.com ↗ Accessed 2026-07-23
  19. 19Snowflake, "Announcing the General Availability of dbt Projects on Snowflake". snowflake.com ↗ Accessed 2026-07-23
  20. 20Databricks Documentation, "Use dbt transformations in Lakeflow Jobs". docs.databricks.com ↗ Accessed 2026-07-23
  21. 21Microsoft Fabric Blog, "dbt + Microsoft Fabric: a strategic investment in the modern analytics stack". blog.fabric.microsoft.com ↗ Accessed 2026-07-23
  22. 22Salesforce, "Informatica from Salesforce Delivers the Trusted Data Foundation Every AI Agent Needs", May 20, 2026. salesforce.com ↗
  23. 23Fivetran, "Transformation Scheduling" (Transformations for dbt Core). fivetran.com ↗ Accessed 2026-07-23
  24. 24Fivetran, "Fivetran Signs Agreement to Acquire Census, Delivering the First End-to-End Data Movement Platform for the AI Era", May 1, 2025. fivetran.com ↗
  25. 25Fivetran, "Fivetran Acquires Tobiko Data to Power the Next Generation of Advanced, AI-Ready Data Transformation", September 3, 2025. fivetran.com ↗