DuckDB and text-to-SQL: redesign the analytics team

September 21, 2026 · 5 min · Free, with full transcript

If a manager can type "show me last quarter's churn by region" and get an answer in ten seconds, what is the analytics team for? The position here is that DuckDB plus language models that write SQL is a workforce redesign, not a tooling upgrade. The ad hoc request queue goes first, dashboard building is half gone, and the analytics engineer who owns the semantic layer becomes the centre of the team. You get a concrete redesign of a team of eight, the reason a model will compute churn three contradictory ways, the caveat on dbt Labs and O'Reilly survey numbers, and a Monday test: count how many live definitions exist for your five most quoted metrics.

Listen to the podcast

4 min

Chapters

Key takeaways

  • Treat natural-language BI as a job redefinition rather than a headcount cut.
  • Check that generated SQL is visible so analysts can verify the number and the query behind it.
  • Fund owners of the semantic layer, the single blessed definition of churn, revenue and active user.
  • Rebalance a team of eight from five juniors, two seniors and one engineer toward two hard-analysis roles and four definition owners.
  • Count how many distinct definitions are live for your five most quoted metrics; more than one means you have a dictionary problem, not a tooling problem.
Read the full transcript

Welcome back to Leaders Insights.

Duck DB just made the analyst job description obsolete.

Here is what CDOs should do about it and why it matters this week.

If a business manager can type, show me last quarter's churn by region, and get a working

answer in 10 seconds, what exactly am I still paying my analytics team for?

That's the question keeping half the chief data officers I talk to awake.

And most of them are answering it wrong.

They're treating it as a headcount cut.

It's a job redefinition.

Walk me through what actually changed.

Because natural language BI sounds like a slide from 2019 that never delivered.

It didn't deliver, and here's why it does now.

Two things collided.

First, Duck DB.

A free, tiny analytics database engine that runs inside your laptop or your browser.

No server farm required.

Second, language models that can turn plain English into SQL.

The query language you use to interrogate a database.

So the model writes the query and Duck DB runs it.

Where's the leap?

People have bolted chatbots onto dashboards for years.

The leap is the query executes on real data, locally, in under a second.

And you can see the SQL it wrote.

Old text-to-query tools gave you a black box and a plausible looking number.

This gives you the number and the receipt.

You can check its work.

Let's tear something apart.

Pull up the standard analytics teamwork chart most companies are running right now.

Fine.

Bottom layer, three or four junior analysts whose whole day is turning Slack messages

into queries and pasting results into decks.

Middle, a couple of senior analysts building dashboards.

Top, an analytics engineer maintaining the data models.

That's the shape at maybe 70% of mid-sized firms.

Which of those layers is already dead?

The bottom one as a job description.

Not the people.

The description.

DBT Labs publish survey data suggesting analysts spend over half their time on ad hoc requests.

Though they sell the tooling that promises to fix exactly that.

So I'd cross-check it.

O'Reilly's developer surveys land in a similar zone independently.

Either way, the ad hoc request queue is the first thing a language interface eats.

And the senior layer?

The dashboard builders?

Half dead.

And this is where CDOs get it wrong.

They think dashboards survive because they're pretty.

Dashboards survive because someone decided which metric matters and how it's defined.

A model will happily compute churn three different ways depending on how you phrase the question

and hand you three confident, contradictory numbers.

That sounds less like a helpful intern and more like a very fast liar.

It's a fast intern who never asks whether the question makes sense.

If you ask for revenue by region and your data has customers build in one region but

serviced in another, it'll pick one silently.

The machine writes the skewl.

It does not write the definition of what region means to your business.

So the analytics engineer at the top, the one nobody could explain to the CEO, suddenly

matters most.

They become the whole game.

MIT Sloan Management Review has been making this point for a couple of years now.

The value moves from producing answers to governing definitions.

Sloan has to own the semantic layer.

The dictionary that says churn means this, revenue means that, and here's the one blessed way

to calculate it.

Without it, natural language BI just industrializes disagreement.

You stop hiring query writers and start funding definition owners.

Take a team of eight.

Historically, five juniors, two seniors, one engineer.

Redesigned, two people fielding genuinely hard analysis, and four building and policing that

shared dictionary of metrics.

Same money, completely different job postings.

The mistake is keeping the old five and handing them a chatbot.

What happens to the CDO who buys the tool and calls it a transformation?

In 18 months, they've got a team optimized for a bottleneck that no longer exists, and

a business making faster decisions off inconsistent numbers.

Need without agreed definitions is just quicker arguments.

One thing they should do Monday morning.

Take your five most quoted metrics.

Revenue, churn, active user, whatever, and check how many distinct definitions are live

across your teams right now.

If it's more than one per metric, you don't have a tooling problem.

You have a dictionary you haven't written yet.

Sources for today's episode.

Towards Data Science, Cade Nuggets, The New Stack, DBT Labs, Vendor, Data Tooling, O'Reilly

Radar, MIT Sloan Management Review.

That's a wrap.

Fresh CDO briefings drop daily at MBA-training.com.

Read and go deeper