dbt vs Natural Language: Do You Still Need to Write SQL?

dbt is not going anywhere. The question is who gets to interact with it.

Right now, the answer is: whoever knows SQL. That is a small group. And it creates a bottleneck that most data teams have just accepted as normal.

What dbt is actually doing

dbt is a transformation tool. It sits between your raw data sources and the clean, business-ready tables your teams actually use. Engineers write SQL models that define how raw data gets shaped into something meaningful. Things like renaming fields, applying business logic, mapping codes to labels, joining tables together.

That layer is where most data quality lives or dies.

It is not a query tool. It does not answer questions. It builds the foundation that other tools sit on top of. When that foundation has errors, everything downstream inherits them.

Most business users have no idea this layer exists. They just know that sometimes the numbers are wrong.

Where natural language fits

Natural language tooling does not replace dbt. It changes who can flag problems with it and who can get answers from it.

There are two separate use cases here and they often get conflated.

The first is querying: asking questions of your data in plain English and getting answers back. "What were our top campaigns last quarter?" "How much did we spend in January?" This is conversational access to data that already exists.

The second is correction: a business user noticing that a field is mapped wrong, a label is outdated, or a calculation does not match what they expected. Today, surfacing that correction means filing a ticket, explaining the logic to an engineer, waiting for a PR, and hoping the fix goes through before end of quarter.

Both are real problems. They need different solutions.

Who benefits and who doesn't

If you are a data engineer who writes SQL every day, natural language querying is not for you. You already have direct access. The tooling around dbt is already your workflow.

The people who benefit are the ones locked out of the process.

The analyst who knows the "Campaign Type" field has been wrong for six months but has no way to fix it without engineering support. The product manager who needs to know if the numbers in the dashboard match what sales is reporting. The VP who wants a quick answer and does not want to wait two days for someone to pull a report.

These people are not asking to replace dbt. They are asking to participate in the process without becoming engineers.

The real bottleneck

Data teams are not slow because engineers are slow. They are slow because every request flows through a single channel.

Business user notices a problem. Files a ticket. Engineer triages it against everything else on the backlog. Fix gets made. Fix gets reviewed. Fix gets deployed. Business user finds out three weeks later.

Natural language does not eliminate the engineer's role. It changes when the engineer gets involved. Instead of triaging every question and every correction, they review and approve the ones that matter. The loop closes faster.

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

What this requires from your data stack

None of this works if the transformation layer is a mess.

Natural language querying on top of inconsistent field names, stale mappings, and undocumented logic does not give you better answers. It gives you confident wrong answers faster.

Before layering natural language on top of dbt, the foundation needs to hold. Your models need to reflect current business logic. Your field names need to mean what they say. Your transformation rules need to be documented somewhere other than the head of the engineer who wrote them two years ago.

That is the pre-work most teams skip. It is also the reason most natural language tools underdeliver in production.

You still need SQL. You still need dbt. What you do not need is every correction and every question going through the same engineer every time.