Half a century of SQL
Half a century after its creation, SQL remains the dominant way to work with relational data, seen by many as “good enough” and so entrenched that credible replacements struggle to gain traction. Commenters weigh its strengths — portability, expressiveness for set-based queries, mature tooling — against pain points like awkward syntax, poor modularity, weak constraint and DDL evolution, and lock‑in that hinders innovation in query languages. Alternatives such as Kusto, Malloy, PRQL, ORMs, and dataframe APIs are praised for specific use cases, but most agree that any successor must coexist with SQL and offer clear, practical advantages to overcome its ecosystem and installed base.
Learning and Teaching SQL
- Several commenters say SQL is hard to start with because you need realistic data and problems; toy tutorials stay too simple.
- SQLite and browser-based/Postgres playgrounds are praised as low-friction ways to learn, especially when bundled with guided exercises and shared databases.
- Others argue it’s “not that hard”: abundant data dumps (e.g., Stack Overflow), CSVs, and built‑in SQLite/DuckDB make experimentation easy.
- A recurring point: SQL practice needs real, slightly boring business questions (aggregations, exclusions, edge cases), which beginners don’t invent on their own.
Declarative Mindset vs Imperative Background
- Many note the mental shift from imperative to declarative set‑oriented thinking is the main barrier.
- Using subqueries and especially CTEs is highlighted as making query structure more readable, composable, and debuggable.
- Advice: if you find yourself looping over rows, you’re probably misusing SQL.
Alternatives, DSLs, and Dataframe APIs
- KQL, Malloy, PRQL, Polars, Ibis, dplyr, and others are cited as more elegant or composable for analytics, often compiling to SQL.
- Reasons they don’t “take off”: limited backend support, extra learning/setup, lack of write/update support, immaturity, and the huge installed base of SQL knowledge.
- Some prefer SQL over Pandas for complex OLAP because SQL is a language, not a library, and its composability (subqueries, GROUP BY) feels cleaner.
Critiques of SQL vs Defenses
- Criticisms: non‑modular, context‑dependent features; awkward syntax; hard to reason about advanced queries; bug‑prone joins; stagnation in DDL constraints; perceived failure of the original “just declare what you want” vision.
- Defenses: SQL is “good enough,” ubiquitous, highly expressive, and consistent across decades and vendors; optimizers are powerful when queries are written relationally; worst SQL arises from imperative thinking.
- Some see SQL, C, and JavaScript as “good enough” incumbents that are too entrenched to replace without overwhelming benefits.
Constraints, DDL, and Integrity
- Complaints about decades‑old constraint sets (PK, FK, UNIQUE, CHECK) and desire for richer, more expressive, yet performant invariants (non‑unique FKs, NOT‑EXISTS constraints).
- Others note many modern systems don’t even enforce PK/FK at scale, and complex constraints can be prohibitively expensive.
- Triggers are seen as powerful but inferior to declarative constraints for stating and reasoning about invariants.
SQL in the Application Stack
- Some want tighter integration: DB schema in source control, easier testing, and type‑safe query DSLs (e.g., jOOQ‑style).
- Others argue for doing more logic inside the database (constraints, views, triggers, stored procedures), sometimes even collapsing the “application tier,” though experiences here are mixed, especially on larger teams.