The numbers tell the story. A thread on r/dataengineering asking whether anyone still writes SQL pulled in hundreds of responses. The top-voted answer, at 397 upvotes, is a one-liner: “no i almost always generate it. Now I have an SQL interview coming up and feel super rusty.”
Let that sink in. The person who gets the most validation on a data engineering forum says they haven’t hand-written SQL in months, and they’re terrified of the interview gauntlet their employers still run.
So which is it? Is SQL a legacy skill, like COBOL, that’s about to be generated into irrelevance? Or are we watching a language transform into something more important than ever?
The honest answer is both, and neither.
The “I Never Write SQL Anymore” Boast Is a Half-Truth
The shift happening in day-to-day data engineering work is real. Projects that used to require four or five engineers now move with one person plus an AI coding assistant. Migrations that took a quarter are getting done in weeks. Senior engineers report that Claude Code, Codex, and OpenCode can now write plausible pipeline code, code that passes review, deploys cleanly, and fails in ways that are genuinely fascinating to debug.
But here’s the uncomfortable part that the “AI writes everything now” crowd tends to skip: the people who are most successful with AI-generated SQL are the ones who understand SQL deeply.
One engineer in that thread put it well: they can’t physically type SQL at 60-80 words per second, so AI is 15-20x faster at the mechanical part. But they still need to know what the output should be. They still need to catch the subtle grain error in a 2,000-line transformation. They still need to understand that a filter applied on one path and forgotten on another quietly lets synthetic accounts into a fraud model.
Sound familiar? That’s the exact failure mode that one readable SQL file solves that sprawling, multi-file pipelines can’t: when every line of code is technically correct but the meaning is wrong, the only defense is a human who can see the whole picture.
What Nobody Tells You About the SQL Interview Circus
Here’s where the conversation gets genuinely uncomfortable.
Engineers who generate SQL all day are being asked to write it by hand in interviews, with no reference guide and no AI. One senior data engineer described bombing a SQL interview hard, fumbling simple joins because they’d gotten used to syntax suggestions and interactive query tools. Yet the same engineer nailed every conceptual question about sharding, indexes, and query optimization.
Their interviewer, a manager-type who “hasn’t really used AI much”, couldn’t reconcile the two.
This isn’t an isolated case. Practitioners are increasingly seeing hand-written coding exercises as an “orange flag” for a company’s technical maturity. Some teams have adapted, shifting to code reviews instead of code writing, because, as one engineer noted, reviewing generated code for correctness and meaning is what the job actually involves now.
And for what it’s worth, a few engineers admit they can still write SQL from scratch but choose not to. There’s something almost defiant about the comment from a veteran developer who says most SQL syntax will stay with them forever, no matter how long they go without touching it.
The Real Skill Isn’t Writing SQL, It’s Specifying Intent
Here’s the uncomfortable truth hiding in this debate:
When you write queries by hand, you’re translating an intent into syntax. When you prompt an AI to write a query, you’re doing the same thing, just in natural language instead of SQL. The syntax generation is now automated. The intent specification is not.
That’s precisely why the engineers thriving in this new era treat AI as a bridge, not a replacement. They use it for what it’s good at, generating the trim(left(substring(replace(... monstrosities that nobody wants to type, while still writing their own transforms when clarity matters more than speed.
One engineer captured the tension well: for simple queries, it’s often slower to explain what you want to an AI than to just write it yourself. If your prompt is “select columns x, y, z from table”, you’ve already written the query. The AI is just adding latency.
The shift from imperative to declarative pipelines mirrors this. You don’t tell a system how to process data anymore. You tell it what the data should look like when it’s done. SQL is the language of what. It always has been.
Why the Warehouse Still Speaks SQL (and Always Will)
Here’s the counterintuitive part: the more AI writes code, the more SQL becomes the interface layer that keeps everything honest.
Datadog’s data observability and quality monitoring is a perfect example. Yes, they have anomaly detection models that learn your data’s normal behavior. Yes, they have automated schema checks. But the most business-specific quality checks still get expressed as custom SQL queries:
SELECT COUNT(*) as failed_orders
FROM ANALYTICS_DB.PROD.ORDERS
WHERE STATUS = 'FAILED'
That’s not because Datadog is behind the times. It’s because “count the failed orders” is a business rule, and business rules live in SQL. The AI can write a thousand lines of pipeline code, but someone still has to tell it what “failed” means in the context of a specific business.
Microsoft’s announcements at SQLCon Barcelona 2026 reinforce the point. They’re not deprecating SQL, they’re building agentic tools on top of it. SQL Database Agent combines the engine’s native Intelligent Query Processing (IQP) with AI reasoning. GitHub Copilot’s Agent Mode in SSMS reasons across database objects, generates and evaluates DDL, and handles multistep tasks from a single prompt.
The pattern is unambiguous: the database ecosystem’s biggest players are betting that SQL becomes the specification that AI agents implement, not a language humans type directly.
The Pipeline Is Outgrowing the Code, In Both Directions
This is where the conversation gets interesting.
AI coding agents are now fast enough that review and validation are the bottleneck, not generation. Asking a person to review 2,000 lines across fifteen files produces exactly the kind of fatigue that misses a one-line grain error in file nine. The entire industry is trying to solve this in divergent ways:
- Consolidate everything into one readable file (DataSQRL’s approach): keep the entire pipeline’s logic in one SQL file that a human can actually read in one sitting.
- Distribute the logic and automate validation (Datadog’s approach): lean on lineage mapping, freshness monitors, and anomaly detection to catch what human review misses.
- Move upstream entirely (the SQLMesh/dbt axis): push logic into transformation frameworks with built-in semantic understanding and lineage.
All three approaches share one crucial trait: they’re built on top of SQL, not instead of it. Even the hot new tools from the evolution of SQL-based transformation frameworks like dbt and SQLMesh are ultimately generating SQL, they just wrap it in a layer of dependency management and testing that was painfully absent in raw pipeline code.
Where This Actually Leaves Your Career
Let’s be blunt about the implications.
The career calculus for data engineers has shifted. Knowing SQL syntax alone was never a differentiator, and it’s even less one now. The language is so widely known, and so effectively generated by AI, that asking “can you write a join” is like asking a carpenter if they can swing a hammer.
What actually separates engineers in the agentic era is the ability to:
- Specify intent clearly. Can you articulate a business rule so precisely that an AI can translate it into correct SQL? This is harder than it sounds, because it requires understanding both the business and the data model deeply.
- Review generated code for meaning, not syntax. The bug where every line is correct and the meaning is wrong can only be caught by someone who understands the pipeline as a whole.
- Design for verifiability. Can you build pipelines where quality problems are detectable? The marriage of pipeline health and data quality monitoring is where the industry is heading.
- Survive the interview gauntlet. However you feel about hand-written SQL exams, they’re still the norm at many companies. Companies that have adapted to code-review interviews exist, but you may need to find them.
The Verdict on SQL’s Obituary: Premature
Here’s the thing about the “SQL is dying” narrative: it’s been floated basically every year since NoSQL became a buzzword, and SQL has responded by swallowing novel query workloads whole.
DuckDB is SQL.
Spark SQL is SQL on top of a distributed engine.
Trino and Presto are SQL on top of everything.
The gold layer of modern data pipelines is increasingly composed almost entirely of SQL, because for final transformations, declarative logic beats imperative code for readability and correctness.
The actual shift isn’t SQL dying. It’s hand-written SQL becoming less common as AI agents take over generation. The engineers who understand SQL deeply are becoming more valuable, not less, because they’re the ones who can:
- Evaluate whether generated SQL actually implements the intended business rule
- Debug the semantic failures that unit tests can’t catch
- Design the data contracts that keep AI agents from hallucinating column names (or worse, updating the wrong class because of a typo in the prompt)
The engineers who treat AI as a replacement for understanding SQL are setting themselves up for exactly the future they fear: a world where they can’t write code, can’t effectively prompt for code, and can’t tell whether the code being generated is correct.
The engineers who treat AI as a tool for expressing SQL intent in new ways are the ones who’ll find that the job expands rather than disappears. AI doesn’t remove the need for technical understanding, it removes the need for typing.
One of the more telling comments from the thread captured it perfectly: “I was very anti-AI up until Opus 4.6 because the SQL generated was garbage. But now, it’s been months since I actually wrote SQL. I feel a bit empty, but I know there is no other way to keep up with the expectations.”
That’s not a eulogy for SQL. It’s a eulogy for the belief that typing SQL was the valuable part.
The language is fine. It’s the job description that needs updating.
