SQL is syntactic sugar for relational algebra

Original Article ↗ Hacker News Discussion ↗

SQL’s awkward, English-like syntax remains deeply entrenched despite widespread agreement that it poorly reflects the underlying rigor of relational algebra and predicate logic. Commenters weigh whether better-designed query languages (from PRQL, LINQ and Pandas-style APIs to Datalog and the “Third Manifesto”’s D language) can offer clearer semantics, composability and optimization without sacrificing SQL’s power or ecosystem. Many conclude that SQL is “good enough” in practice—especially with strong tooling and database design—yet its complexity and non-relational features complicate formal reasoning, implementation, and automatic query generation.

Overall view of SQL

  • Widely used and powerful, but many see the syntax as messy, inconsistent, and “backwards,” especially the SELECT-before-FROM ordering and odd scoping rules.
  • Others find it reasonably learnable, expressive, and preferable to JSON-based or proprietary query syntaxes; for many, problems stem more from poor schema design and misuse than from SQL itself.
  • Comparison to C: good to know deeply, but some prefer “managed” abstractions; critics counter that ORMs are leaky and often underpowered.

Syntax, ergonomics, and tools

  • Complaints: non-intuitive parse order, difficulty reading complex nested queries, hard autocomplete because sources come after projections, and dangerous commands like DELETE FROM without guardrails.
  • Mitigations: use of CTEs, table-valued functions, temp tables, transactions, and client safeguards (WHERE-required deletes, special flags).
  • Layout, comments, and ER diagrams are seen as crucial for maintaining complex SQL.

Relational algebra, theory, and the standard

  • Many agree SQL is not clean syntactic sugar over relational algebra: bags vs sets, NULL semantics, ordering, and many “non-relational doodads.”
  • References to Codd’s relational model, predicate calculus, Datalog, MonetDB’s IR, and the “Third Manifesto” highlight a desire for languages closer to formal relational theory.
  • The SQL standard is viewed by some as overly complex and effectively a moat that raises the barrier for new database implementations.

Alternatives and related languages

  • Mentioned alternatives or complements: PRQL, XTQL, LINQ-style comprehensions, Malloy, CozoDB, dataframe libraries (Pandas, Polars, Ibis), and D-style languages (though no popular implementation).
  • These often improve composability, left-to-right reading, and integration with host languages, but typically lack full DML support, vendor-specific features, or maturity.

Learning, pedagogy, and practice

  • Several recount taking years to “really get” SQL, often triggered by performance-heavy or large-scale work.
  • Formal DB education is uneven; some criticize highly theoretical teaching (including some relational-theory texts), others praise accessible introductions and practical design books.
  • Strong theme: understanding relational theory and good schema design drastically improves SQL, but SQL’s warts still limit what well-designed RDBMS engines could expose.