There seems to be a school of thought in the tech community that a robust knowledge SQL is now optional. After all, with modern AI tools able to generate SQL from plain English, it seems “obvious” that we have abstracted away the need to understand the language itself.
My thoughts are that the exact opposite is true: Learning SQL is more important than ever.
(I know you’ll be surprised to hear this given my database background 😂, so let me justify my position)
The illusion of “just talk to your database”
Natural language to SQL initially looks super cool – “Show me last quarter’s top customers” and voila! Out pops a SQL query. But that convenience comes with a fundamental problem: ambiguity. After all, that is generally why computer languages were invented – to bring precision to the definition of what task you want done.
Human language is not precise. “Top customers” never defines with “top” is. It could mean highest revenue, most orders, biggest growth, highest margin, etc etc. “Last quarter” might be fiscal quarter or calendar quarter, or last completed quarter. Your LLM (or agent) may well have to guess.
The big problem is that if it guesses wrong, it is probably going to do so quietly. The “best” case is that the query fails. What is more likely is that it runs and returns plausible but incorrect results. That’s far worse. This is why developers having SQL knowledge is going to be even more critical, because otherwise you will be trusting an interpretation of the data that you can’t verify. Only with SQL knowledge will you be able to see if the SQL code actually matches your intent.
Cake baking
To use a (terrible 😂) metaphor of making a cake, I see AI-generated SQL as doing a chunk of the basic requirements: Going to the shop, getting all the ingredients, and prepping them. However, the combining of ingredients in the right way, and adding the finishing touches is what really makes a great cake, and it will be the same with SQL. Your SQL skills as a human will be what takes a “almost good enough” SQL to one that runs well, handles edge cases, doesn’t crash when the data is not as expected etc.
With some help from annotations, AI might understand your schema, but probably not your data quality issues, or the mysteriously quirky business contexts that often lie behind your database tables. I’ve lost track of the number of customer sites where snippets in conversation arise like “Oh, if the fiscal year starts on a weekend, we don’t actually use that table. We use a calculation from these two other tables“, and the knowledge of that fact is buried 9 levels deep in a subroutine somewhere.
That’s where your human expertise comes in. Knowing SQL means you can:
-
Validate the logic proposed by an LLM
-
Refactor the generated queries for clarity and correctness
-
Adjust for real-world data anomalies
and most importantly, treat all code (AI or human generated) with scepticism instead of blind trust.
What about agents running SQL directly?
There’s a lot of excitement around autonomous agents querying your databases directly. In a production system, that is incredibly risky. I’ve seen a lot of posts on the intertubes about “Yeah, I would be worried about performance“. For me, that is the least of my concerns. The much bigger risk of ad-hoc SQL access is to accidentally expose sensitive information. Slow systems make customers frustrated, but insecure systems lose the trust of customers, and they’ll desert you.
Do you really want to have an automated agent rolling the “adhoc SQL” dice?
Production environments generally require:
-
Predictability/stability
-
Security controls
-
Auditability
-
Performance guarantees
Good SQL meets those requirements whereas AI-generated SQL might meet those requirements. The transition from generated SQL to good SQL requires human expertise, because it will be a human that is responsible for it.
SQL as documentation, not just a language
Something that is perhaps overlooked because it is more seen as a soft skill, is that SQL teaches you how to think about data.
Writing SQL forces you to:
-
Understand relationships between entities
-
Reason about sets, not just rows
-
Be explicit about the assumptions you’re making
These are core skills for a data professional that aren’t really just about SQL. Even if AI writes 90% of your queries, you still need that mental model to guide, critique, and refine what it produces.
As AI takes on more of the typing, the your role will “shift” to interpretation, validation, and responsibility. I use quotes for “shift” because you have always had the job of interpretation, validation, and responsibility when it comes to the code you deploy to production. And you can’t do that without understanding the language underneath.
Don’t get me wrong. The AI tools of today and tomorrow that write SQL will be fantastic accelerators of our coding work. They’ll save time, give us ideas, and help you get moving when you’re stuck. But they don’t remove the need for expertise in SQL – they magnify the value of having that expertise. So yes, by all means, use AI to write SQL. But this increases not decreases your need to become an expert with the SQL language. so you know when it’s right, when it’s wrong, and when it’s dangerous.
So SQL skills are not becoming less relevant – they are becoming even more critical.
Once that SQL is written, validated and verified (by you), lock it behind an appropriate API or abstraction layer, and let AI tools build your apps around those APIs. Your customers and your security team will thank you for it.
Leave a Reply