AI writes the SQL. Someone still has to read it.

Will AI replace SQL? No — but it does change what SQL skill means. The value moves from writing syntax to judging whether a query answers the question that was actually asked.

Short answer

AI is changing how queries get written, not whether SQL is used. Every AI data tool in production today works by generating SQL and running it against a database. The interface changed; the foundation didn't. What changed for people is the skill: less writing, far more reading.

Anyone can now ask a question in plain English and get back a query, a chart, or a paragraph of analysis in seconds. It's a genuine shift, and it has produced a genuinely wrong conclusion — that SQL is on its way out.

Ask an AI tool for "the top 10 customers by revenue this quarter" and nothing magical happens. It writes SQL, runs it against your database, and returns rows. Whether a person or a model composed it, the database still parses, plans and executes SQL. That layer isn't being abstracted away; it's being written faster, by something that doesn't know your business.

Which is precisely where the new skill lives.

The query that looks right and isn't

Here is the failure mode that matters most, and the reason "AI writes it for you" doesn't close the question. Ask for revenue by region this quarter, and a model might produce this:

sql

SELECT c.region, SUM(o.total) AS revenueFROM customers cJOIN orders o ON o.customer_id = c.idJOIN order_items i ON i.order_id = o.idWHERE o.created_at >= date_trunc('quarter', now())GROUP BY c.region;

The join to order_items multiplies each order by its line-item count, so an order with three items contributes its total three times. No error is raised. The query runs in 40 milliseconds. The chart looks entirely normal.

This is ordinary join and GROUP BY semantics doing exactly what they are defined to do — and date_trunc is behaving correctly too. Nothing about the output announces the problem. There is no exception, no warning, no red text. The number is simply wrong, plausibly wrong, and formatted well — and it goes into a board deck. Catching it requires someone who reads the query and notices that the grain changed when that third table entered.

That is not a syntax skill. You could have every keyword in the language memorized and miss it. It is a data skill, and AI has made it more valuable, not less, because it now produces confident queries at a rate no human review process was designed for.

Four ways AI-generated SQL goes wrong

The wrong grain. The example above. A join fans rows out and an aggregate silently multiplies. The most common cause of a wrong number that nobody catches, because everything about the result looks healthy.

The plausible wrong column. amount versus amount_net. created_at versus completed_at. The model picks the one whose name best matches your words, not the one your business uses for that metric. Both exist, both return numbers, only one is right.

The dropped filter. Test accounts, cancelled orders, internal users, soft-deleted rows. Every mature database carries exclusions that everyone on the team knows and no schema records. A model can't infer a convention nobody wrote down.

The query that works and shouldn't run. Correct results, catastrophic plan. A generated query with no useful index path can saturate the database that also serves your application — a correctness success and an operational incident at the same time. This is what EXPLAIN exists to show you, and what nothing in the answer itself will.

Notice that none of the four are syntax errors. Syntax is the part AI genuinely solved. What's left is everything syntax was never the hard part of.

"Calculate monthly active users" is not a SQL problem

Take a request that sounds completely specified: calculate monthly active users. Before a single line of SQL can be correct, four questions have to be settled:

• What counts as active? A login? A session over some duration? A meaningful action, and which ones qualify?
• Which table records it? Often several do, at different grains, with different retention.
• How are duplicates handled? Distinct users, or events? What about a user with two accounts?
• What window applies? Calendar month, rolling 30 days, or trailing 28 to keep weekday effects constant?

A model will answer all four for you, instantly, invisibly, and differently depending on how you phrased the question. It won't tell you it made four judgement calls. Two people asking for MAU in different words can get two different numbers, both defensible, and neither flagged.

These are definitional problems, not technical ones. The organizations that get this right define their metrics once, in a semantic layer, so the model chooses from defined metrics rather than inventing arithmetic per query.

What "knowing SQL" means now

What it used to mean

• Recalling join syntax and window function clauses
• Writing the query from a blank editor
• Knowing the dialect's quirks by heart
• Speed of composition

What it means now

• Reading a query and judging whether it answers the question asked
• Knowing your schema, its grain, and where the joins fan out
• Knowing the filters everyone applies and nobody documents
• Speed of verification

This is a smaller skill to acquire than the old one, and a more valuable one to hold. You no longer need to write a correlated subquery from memory. You do need to look at one and say whether it's counting what you asked it to count.

If you're starting from zero today, the efficient path has changed accordingly: learn to read SQL before you learn to write it. Joins and grain first, then aggregation and GROUP BY semantics, then filtering and NULL behavior. Window functions and optimization can wait — those are the parts AI handles best.

SQL is the audit record

There's a second reason SQL isn't going anywhere, and it has nothing to do with skills.

SQL is a readable, reproducible record of exactly how a number was produced. When a regulator, an auditor, or a CFO asks where a figure came from, "the AI said so" is not an answer. A query is. It can be reviewed, re-run, version-controlled, and diffed. That property is the reason regulated organizations can adopt these tools at all.

An AI analytics tool that hides its SQL isn't offering simplicity. It's removing the only artifact that makes the answer checkable.

The portability argument, briefly

SQL became an ANSI standard in 1986 and an ISO one in 1987, and it is still being revised — the current edition is ISO/IEC 9075-1:2023. Four decades on, it is spoken by essentially every serious data platform: Postgres, MySQL, SQL Server, Oracle, Snowflake, BigQuery, Redshift, Databricks. New AI interfaces sit on top of those systems; none of them replaced the query language underneath. As technical investments go, that track record is hard to match.

The interface changes. The foundation stays.

AI has made data genuinely more accessible, and that's worth celebrating rather than defending against. But accessibility isn't the same as reliability, and the gap between them is exactly the size of the SQL you can't see.

The people who do well in this era won't be the ones who refuse to use AI to write queries, and they won't be the ones who trust it blindly either. They'll be the ones who can look at a generated query and say, in ten seconds, whether it means what the question meant.

Query it. Analyze it. Visualize it. — all with DBx Studio.