The useful consensus was narrower and better than the post. What lasts is not every bit of SQL syntax. What lasts is set-based thinking, relational modeling, and a feel for how databases actually execute work. People kept returning to the same failure mode. Developers think imperatively, hide behind ORMs, then write loops, cursors, and chatty round trips where one set-oriented query would be simpler and faster. That is why learning joins, subqueries,
window functions, indexes, and query plans matters. Not because SQL is “low level,” which many rejected, but because it forces a mental model that travels across stacks and tools.
A second theme was that plain SQL beats abstraction layers more often than teams admit. Many said code got simpler once they dropped heavy ORMs in favor of explicit queries or lightweight mappers like
Dapper and
sqlc. The reason was not ideology. It was control. You can see the query, reason about performance, avoid hidden
N+1 access patterns, and keep generated or AI-assisted code honest. At the same time, experienced database people pushed the scope wider than the article did. Knowing SQL alone is not enough. You need database fundamentals like normalization, indexing, transactions, isolation, client-server round trips, and where logic belongs. Stored procedures got mixed treatment here. Some still value them for reducing network chatter and localizing logic. Others see big stored procedures as a dumping ground for application code that should live elsewhere.
The comments also added useful caveats. SQL is stable, but not frozen. Modern practice includes later additions like window functions and vendor-specific features such as
QUALIFY, plus meaningful dialect differences across
PostgreSQL,
DuckDB,
ClickHouse, Oracle, and others. Several people stressed that you do not really “learn it once” and walk away. You learn the core once, then deepen it through repeated use on real problems. That still leaves SQL looking unusually strong as a career investment. Not because it is beautiful, since many called the language syntax clumsy and inconsistent, but because the underlying relational approach keeps surviving every attempted replacement.
fagnerbrack.com