Pql, a pipelined query language that compiles to SQL

Original Article ↗ Hacker News Discussion ↗

A new pipelined query language called Pql, inspired by tools like Kusto and Splunk’s SPL, aims to offer a more readable, security-focused alternative to SQL while compiling down to standard SQL for execution. Commenters debate whether this extra abstraction brings real benefits over mature options like PRQL, LINQ-style libraries, or just writing SQL directly, raising concerns about performance, missing features (e.g., window functions), and the long-term cost of maintaining yet another DSL. Others argue that SQL’s complexity, inconsistent dialects, and awkward handling of concepts like nulls justify experiments like Pql, especially if they integrate cleanly with existing databases and tooling.

Motivation and Target Users

  • Designed as a small, pipelined language that compiles to SQL, inspired heavily by Kusto / SPL-style query languages.
  • Targeted especially at security engineers and analysts who dislike SQL and are already accustomed to KQL, Splunk SPL, Sumo, etc.
  • Seen as a way to get KQL-like ergonomics on top of general SQL engines and reduce vendor lock‑in from proprietary log-query DSLs.

Comparison to SQL

  • Supporters like the linear, left‑to‑right pipeline style and shorter, KQL-like syntax.
  • Critics argue examples compare “pretty” Pql against deliberately convoluted SQL; idiomatic SQL could be nearly as simple.
  • Some argue SQL’s stability and ubiquity outweigh the benefits of learning yet another DSL; others see SQL as fundamentally awkward or “awful.”

Relation to Other Query Languages (PRQL, LINQ, etc.)

  • Strong comparisons to PRQL: both are compile‑to‑SQL with pipeline syntax.
  • Questions why not reuse PRQL; responses cite different audience, syntax preferences, and a desire for a pure‑Go implementation.
  • Also compared to LINQ, dbplyr, CoffeeScript/TypeScript over JS, and multiple similar “post-SQL” projects (TQL, XTQL, Preql).

Performance and Query Planning

  • Concern that Pql’s CTE-heavy output (WITH subqueries) may be slow or force poor join orders.
  • Others note modern engines often inline CTEs, so simple cases shouldn’t be an issue; but impact on complex queries is unclear.
  • General skepticism that another abstraction layer can be “more efficient” than writing SQL directly, aside from developer productivity.

Implementation Choices (Go, Bindings, Parsing)

  • Debate over using Go vs wrapping Rust-based PRQL: Go+C bindings work, but some see Go’s FFI as clumsy; others say overhead is now minor.
  • Author hand‑wrote a parser; other commenters share experiences of building recursive‑descent parsers as educational and flexible.

Null Handling and Semantics

  • Pql inherits SQL’s NULL behavior since it just transpiles; it doesn’t fix three-valued logic issues.
  • Some argue a better design would use Option/Maybe types, but that would require a fundamentally different language, not just a SQL frontend.

LLMs vs DSLs

  • Several note LLM‑to‑SQL tools are promising but unreliable: fine for first drafts, not for correctness‑critical queries.
  • Pql is presented by some as a more deterministic bridge: easier than SQL for certain users, but still explicit and checkable.

Limitations and Skepticism

  • Commenters note missing advanced SQL features (window functions, aggregate filtering, data-type-specific functions, parameters).
  • Some fear added complexity, a second “hood” over the query planner, and yet another short‑lived query language.
  • Others are enthusiastic about KQL-like ergonomics on standard SQL backends and welcome more experimentation in this space.