Show HN: PRQL in PostgreSQL

Original Article ↗ Hacker News Discussion ↗

A new PostgreSQL extension brings PRQL, a pipelined query language that compiles to SQL, into the database, prompting debate over whether higher-level DSLs are worth adopting when SQL is already ubiquitous and powerful. Supporters argue PRQL’s functional, composable syntax, better autocompletion potential, and terseness for complex analytical patterns can improve developer experience, especially for non-experts. Skeptics counter that it adds another abstraction layer, risks performance misunderstandings, and faces structural barriers to adoption given existing SQL tooling, training, and cross-database differences.

What PRQL Is and How It Works

  • PRQL is presented as a higher-level, more regular query language that compiles to SQL.
  • It’s not an ORM and doesn’t add capabilities beyond SQL; it’s largely syntactic sugar with a functional / pipeline style.
  • The Postgres extension is built on pgrx and currently only supports Mac/Linux because pgrx lacks Windows support.

Motivations: DX, Readability, Autocomplete

  • Proponents emphasize developer experience: faster expression of analytical queries, more functional thinking, and pipelined “from-first” syntax.
  • Autocomplete and type-checking are key selling points; SQL’s SELECT-before-FROM ordering is seen as awkward for tooling.
  • Some see it as a clearer way to think in transformations/relational algebra, especially for complex analytics and EDA.

Skepticism: SQL Is Enough / Abstraction Costs

  • Many argue SQL is rich, ubiquitous, well-documented, and supported everywhere; adding another layer increases complexity, training cost, and potential for confusion.
  • Some feel PRQL doesn’t fix SQL’s hardest part: thinking in sets/relational terms. It mainly tidies syntax.
  • Concern that another abstraction could hide performance implications, especially around join/filter/order choices.

Example Debate: “Longest Track Per Album”

  • A central debate: is PRQL materially simpler for “top N per group” queries?
  • Thread shows several SQL solutions (Postgres-specific DISTINCT ON, window functions, QUALIFY, subqueries) and notes this pattern is non-trivial but well-known.
  • Some admit they can’t write the canonical SQL from memory; others say any moderately experienced SQL user can.

Composability, Debugging, and Tooling

  • Some criticize SQL’s lack of composability; others counter that CTEs, views, and functions already provide composition.
  • Debuggability of stored procedures/functions is widely seen as painful.
  • There’s discussion of function inlining, volatility (STABLE/IMMUTABLE), and surprising planner behavior in Postgres.

Adoption and Ecosystem Concerns

  • Organizations often prioritize reliability and shared knowledge over incremental syntax improvements.
  • LLMs that generate SQL reduce the pain of verbose SQL and may blunt the incentive to adopt PRQL-like layers.
  • Database-agnosticism is questioned; many argue tuning to a specific engine (e.g., Postgres, Oracle) matters more.

Related DSLs and Future Directions

  • Comparisons are made to Ecto, EdgeQL, jq, awk, Kusto, Malloy, and other DSLs/semantics-on-top-of-SQL efforts.
  • Some see Postgres as a promising host for multiple embedded DSLs via extensions.

HN Meta: Styling and UX

  • Separate subthread explains HN’s grey text for text posts and downvoted comments as intentional de-emphasis, plus notes on green usernames and downvote thresholds.