Things I want in a modern relational query language

Original Article ↗ Hacker News Discussion ↗

SQL’s awkward syntax, poor composability, and hard-to-debug behavior are leading many engineers to question whether it should remain the dominant way to query relational data. Commenters weigh the benefits of its ubiquity and battle-tested ecosystem against newer ideas like Datalog-based systems, PRQL-style pipelined syntax, live/streaming queries, and language-integrated or IR-based approaches that compile down to SQL or a lower-level core. Large language models further complicate the landscape: they make SQL easier to generate from prose, reducing pressure to change, yet also lower the barrier to experimenting with entirely new query languages.

SQL ergonomics & composability

  • Many commenters see SQL as cognitively heavy: non-composable, hard to refactor, and awkward for incremental query building.
  • Joins are described as an “unnatural” way to express relationships, especially compared to pointer-like navigation or graph-style APIs.
  • Others push back, arguing SQL syntax is simple, widely known, and that fear of SQL is more cultural than technical.
  • Isolation levels, locking behavior, and optimizer plan shifts are seen as major pain points that typical developers struggle to understand.

ORMs, raw SQL, and tooling

  • ORMs are valued for safety (parameterization against SQL injection) and higher-level ergonomics.
  • Critics say ORMs encourage avoiding powerful SQL features (CTEs, window functions, partitioning, stored procedures) and can hide transactional pitfalls.
  • Some advocate making raw SQL/stored procedures easier to deploy, treating the database more like a “scriptable” component.
  • Debugging logic split between app code and stored procedures is frequently described as painful.

LLMs and query languages

  • One thread argues SQL will become like assembly: mostly generated by tools/LLMs, making syntax complaints less relevant.
  • Others counter that LLMs can also quickly learn and design new languages and runtimes, potentially lowering the barrier to experimentation.
  • There’s disagreement on whether LLMs perform significantly worse on novel languages vs high-data languages like SQL.

Alternatives and experiments

  • Datalog and Datalog-based systems (e.g., CodeQL, various open-source engines) are repeatedly cited as more composable and expressive.
  • Other mentioned efforts: PRQL, graph-style querying (GraphQL, Cypher), compact LLM-oriented query syntaxes, Mongo-style document queries, and databases exposing an IR for multiple front-end languages.
  • Some compare SQL unfavorably to more “relationally pure” systems that already exist, arguing SQL’s dominance is historical, not technical.

Desired improvements

  • Better error messages and diagnostics for complex SQL.
  • First-class support for nested/relational structures rather than flat tables.
  • Live/continuous queries or streaming deltas instead of repeated polling.
  • Column deprecation warnings, schema versioning, and safer schema evolution.
  • Typed, language-integrated queries that compile to a shared relational IR, letting different syntaxes coexist.

Adoption & inertia

  • Replacing SQL is seen as extremely hard because:
    • Expertise, tooling, and ecosystem are all SQL-centric.
    • New languages must be vastly better to justify migration.
  • Some conclude SQL is “the worst except for all the others tried,” with many attempts either re-embedding SQL or adding SQL compatibility over time.