dbt vs natural language: do you still need to write SQL?

The transformation layer is not going anywhere. The open question is who gets to interact with it, and right now the answer is whoever knows SQL. That is a small group, and most data teams have accepted the bottleneck it creates as the normal cost of doing business.

What the transformation layer actually does

The transformation layer sits between raw sources and the clean tables your teams use. Engineers write SQL models that rename fields, apply business logic, map codes to labels, and join tables into something a human can reason about. In most modern stacks that means dbt, and it is where data quality either gets built in or gets skipped.

It is not a query tool and it does not answer questions. It builds the foundation everything else sits on, and when the foundation has errors, every dashboard and every report downstream inherits them. Most business users have no idea this layer exists. They just know the numbers are sometimes wrong and that fixing them takes a long time.

Two use cases that get conflated

Natural language tooling does not replace the transformation layer. It changes who can get answers from it and who can flag problems with it. Those are two different jobs and vendors tend to blur them.

The first is querying. Someone asks "what were our top campaigns last quarter" in plain English and gets a number back. This is conversational access to data that already exists and is already correct. It is the easier of the two problems and it is the one every demo shows.

The second is correction. An analyst notices that a field is mapped wrong, a label is stale, or a calculation does not match what finance is reporting. Today that means filing a ticket, explaining the logic to an engineer who was not in the room when the logic was written, waiting for a PR, and hoping the fix ships before quarter close. This is the harder problem and the one almost nobody is solving well.

Who this is actually for

If you are a data engineer writing SQL every day, natural language querying is not for you. You already have direct access and the tooling around dbt is already your workflow. Nobody should be trying to sell you a chat box.

The people who benefit are the ones locked out of the process. I spent years on the agency side running pipelines for CPG and financial services clients, and the same person showed up at every one of them: the analyst who knew the campaign type field had been wrong for six months, could describe exactly what the fix was, and had no path to make it happen except pinging me. I had a backlog. Their fix waited. The dashboard stayed wrong.

That analyst is not asking to replace the transformation layer. They are asking to participate in it without becoming an engineer.

The real bottleneck

Data teams are not slow because engineers are slow. They are slow because every request, from "what did we spend in January" to "the region mapping is out of date," flows through the same channel and competes for the same person's attention.

Natural language does not remove the engineer from that loop. It changes where they enter it. Instead of triaging every question and every correction, they review the ones that need review. The mechanics look something like this: a business user flags that "Paid Social" should include the new TikTok source, the tool drafts the change to the mapping seed or the model's case statement, and the engineer sees a proposed diff instead of a Slack message that starts with "hey, quick question." The engineer still approves it. They just spend five minutes instead of an afternoon.

That is the actual value proposition. Not "no more SQL." SQL for the people who need to write it, and plain language for everyone else.

What this requires from your stack

None of this works if the transformation layer is a mess. Natural language on top of inconsistent field names, stale mappings, and undocumented logic does not produce better answers. It produces confident wrong answers faster, and now they arrive in a friendly chat window that makes them look more trustworthy than the spreadsheet did.

Before you put a natural language tool in front of anyone, three things need to be true. Your models reflect current business logic, not the logic from the last reorg. Your field names mean what they say. Your transformation rules are documented somewhere other than the head of the engineer who wrote them two years ago, which in dbt means the YAML descriptions are filled in and someone has read them recently.

That is the pre-work most teams skip, and it is the reason most natural language tools underdeliver in production. The tool gets blamed for a foundation problem.

You still need SQL. You still need the transformation layer. What you do not need is every question and every correction waiting on the same engineer every time.