Pipe Syntax in SQL

Original Article ↗ Hacker News Discussion ↗

Google researchers are proposing a new “pipe” syntax for SQL that lets queries be written as top‑to‑bottom dataflows (e.g. `FROM … |> WHERE … |> AGGREGATE …`) rather than in SQL’s traditional clause order. Commenters compare it to languages like KQL, PRQL and R’s dplyr, saying it can make complex analytical queries more readable and reduce the need for chained CTEs, but others argue it adds unnecessary syntax sugar, risks confusing SQL’s declarative model with an execution plan, and is unlikely to become an ISO standard without broad vendor support. There is broader agreement that tooling, accessibility (e.g. HTML vs PDF papers) and interoperable SQL dialects matter at least as much as new syntax for improving real‑world workflows.

Paper format & accessibility

  • Many complain that research is only published as two-column PDFs, which are hard to read on mobile, less accessible, and harder to deep-link or copy from than HTML.
  • Others defend PDFs for layout quality, printability, and TeX typesetting; some reviewers even render web articles to PDF for editing.
  • Accessibility concerns are raised (e.g., photophobia, need for dark mode and reader modes), where HTML is clearly superior.
  • There’s discussion of offline, self-contained web bundles. Existing options (base64 assets, WARC) are seen as unsatisfying; people want an explicit “offline-only” format browsers enforce.
  • One commenter demonstrates converting the PDF to semantic HTML using an LLM, with surprisingly good results.

Pipe syntax proposal: enthusiasm

  • Many long-time SQL users say complex queries are hard to express and debug; pipe syntax maps better to how they think about stepwise transformations.
  • Pipes align well with how query planners already think (tables flowing through unary operators), so the written order now matches the conceptual execution order.
  • Pipes can reduce the need for multiple CTEs, especially for “top N then aggregate” patterns where ORDER/LIMIT need to precede aggregation.
  • Supporters like starting from FROM for better autocompletion and readability, similar to R’s dplyr, KQL, PRQL, Polars, dataframe APIs, and Unix-style pipelines.

Pipe syntax proposal: skepticism & design concerns

  • Some argue SQL is already very successful and the main issues are tooling or user understanding, not syntax.
  • Critics worry pipes add “imperative-feeling” sugar to a declarative language and may obscure the optimizer’s freedom.
  • Multiple WHERE clauses replacing WHERE/HAVING/QUALIFY are seen by some as reducing explicitness and potentially causing confusion.
  • Others feel complex multi-join, graph-shaped queries are better modeled by CTEs/subqueries; pipes are seen as mainly helpful for linear, single-table flows.
  • Concerns are raised about clutter, loss of clause ordering guarantees (e.g., always finding ORDER BY at the end), and queries becoming “alien” to existing SQL users.

CTEs, optimization, and performance

  • Pipe syntax is framed as ergonomically better than stacking CTEs, but not fundamentally more optimizable; engines with weak CTE optimization likely won’t magically improve.
  • Some note CTEs can be optimization barriers or syntactic expansions that complicate plans; others use temp tables instead.
  • Several emphasize that keeping complex transformations in SQL is crucial for performance and avoiding massive data transfers; using an external language for transformations is usually far slower.

Adoption, standards & tooling

  • The proposal currently comes from a single vendor and is seen as unlikely to hit ISO SQL soon without broad buy-in (Postgres, MySQL/MariaDB, SQL Server, Oracle).
  • Some want transpilers/AST tooling (e.g., sqlglot-style) and cross-dialect support before adopting new syntax.
  • Pipe syntax is implemented as an extension in ZetaSQL and can be mixed with standard SQL; some see this incremental, backwards-compatible path as its main strength.