Cool story Hansel, but what can I actually do with PRQL now?

We’re still early, and the opportunities for using PRQL are focused on two integrations:

Beyond these two integrations, it’s very easy to add PRQL to your own apps with our bindings for Rust, Python & JS.

Something here reminds me of another project, did you take the idea from them?

Yes, probably. We’re standing on the shoulders of giants:

And there are many projects similar to PRQL:

If any of these descriptions can be improved, please feel free to PR changes.

How is PRQL different from all the projects that SQL has defeated?

Many languages have attempted to replace SQL, and yet SQL has massively grown in usage and importance in the past decade. There are lots of reasonable critiques on these attempts. So a reasonable question is “Why are y’all building something that many others have failed at?”. Some thoughts:

In the same way that “SQL was invented in the 1970s and therefore must be bad” is questionable logic, “n languages have tried and failed so therefore SQL cannot be improved.” suffers a similar fallacy. SQL isn’t bad because it’s old. It’s bad because — in some cases — it’s bad.

Which databases does PRQL work with?

PRQL compiles to SQL, so it’s compatible with any database that accepts SQL.

A query’s dialect can be explicitly specified, allowing for dialect-specific SQL to be generated. See the Dialect docs for more info; note that there is currently very limited implementation of this, and most dialects’ implementation are identical to a generic implementation.

What’s going on with this aggregate function? What’s wrong with SELECT & GROUP BY?

SQL uses SELECT for all of these:

These are not orthogonal — SELECT does lots of different things depending on the context. It’s difficult for both people and machines to evaluate the shape of the output. It’s easy to mix meanings and raise an error (e.g. SELECT x, MIN(y) FROM z).

PRQL clearly delineates two operations with two transforms:

aggregate can then be used in a group transform, where it has exactly the same semantics on the group as it would on a whole table — another example of PRQL’s orthogonality.

from employees
group department (
  aggregate [total_salary = sum salary]

While you should be skeptical of new claims from new entrants Hadley Wickham , the developer of Tidyverse commented in a discussion on PRQL:

“FWIW the separate group_by() is one of my greatest design regrets with dplyr — I wish I had made by a parameter of summarise(), mutate(), filter() etc.”

For more detail, check out the docs in the PRQL Book .