PRQL compiles pipelines into SQL, and names what it cannot do yet

Every line in a PRQL pipeline rewrites the line above it

PRQL stands for Pipelined Relational Query Language and is pronounced Prequel. The organizing rule is visible in the smallest example the project publishes: each line transforms the result of the previous line. You read a query from top to bottom in the order the work happens, which is the reverse of nested SQL, where the clause you wrote last runs first.

from tracks
filter artist == "Bob Marley"                 # Each line transforms the previous result
aggregate {                                   # `aggregate` reduces each column to a value
  plays    = sum plays,
  longest  = max length,
  shortest = min length,                      # Trailing commas are allowed
}

`from tracks` names the relation, `filter` applies a single condition with plain equality, and `aggregate` collapses columns down to one value each. The names on the left of each equals sign become the output column names, and the comma after the final entry is accepted. None of these three lines touches a database, because PRQL compiles to SQL and the target is any database that already runs SQL.

derive and group are where PRQL parts ways with SQL shape

The larger example in the project's documentation shows where the shape changes rather than the vocabulary.

from employees
filter start_date > @2021-01-01               # Clear date syntax
derive {                                      # `derive` adds columns / variables
  gross_salary = salary + (tax ?? 0),         # Terse coalesce
  gross_cost = gross_salary + benefits_cost,  # Variables can use other variables
}
filter gross_cost > 0
group {title, country} (                      # `group` runs a pipeline over each group
  aggregate {                                 # `aggregate` reduces each group to a value
    average gross_salary,
    sum_gross_cost = sum gross_cost,          # `=` sets

Three mechanisms sit in that block. `derive` introduces names later lines reuse, so gross_cost is computed from gross_salary inside the same brace block that declares it. `??` supplies a default when tax is null, written inline instead of through a separate case expression. `group {title, country} (` opens a pipeline that runs once per group, so the aggregate nested inside it is scoped to each title and country pair. A `@` prefix marks the date literal, and the project lists functions and variables as supported abstractions. The published snippet also stops mid-statement, with no closing braces, which tells you the block is a fragment of a larger query rather than a runnable program on its own.

What the July 2026 status note rules out

The status section in the README is dated July 2026 and reads like a scope document rather than a launch note. It says PRQL is ready to use by the intrepid, either through the supported integrations or inside your own tools using one of the supported language bindings, and then narrows that immediately: bugs and missing features remain, and rollout to non-technical teams is described as suited to fairly simple queries only.

Three concrete gaps come out of that paragraph. Modules and multi-file projects are only being added, as experimental support. Coverage is incomplete on purpose: the stated goal is to make PRQL usable for almost all standard SQL queries, an explicit admission that some standard SQL has no PRQL equivalent yet. And bug volume is rising with adoption, since more users have produced more reports against open priority bugs.

For a reader the consequence is practical. PRQL is a migration target for the simpler half of a workload, not a full replacement.

Window functions outside a window transform are an open question

One item in the project's thinking-out-loud list deserves more attention than it usually gets. The maintainers are re-checking whether their initial decisions were correct, and they name a specific example: how window functions are handled outside of a `window` transform, tracked as issue 2723. That is not a bug report. It is an admission that part of the language's semantics may still change.

The consequence for code already written is direct. A query relying on an implicit window in today's form may need rewriting once the decision lands, and the rewrite is not a find-and-replace, because it changes how the pipeline is expressed rather than one clause inside it. Version pinning matters for that reason. The newest tagged release is 0.13.14 from 2026-07-24, while the workspace manifest already reads 0.13.15, so what you install and what the default branch builds are not always the same compiler.

If you adopt PRQL while 2723 is open, keep windowed queries in a handful of files instead of spreading them across the codebase. That turns the pending decision into a few edits rather than a search across every query you own.

The workspace manifest pins the toolchain, not the databases

The root Cargo.toml is the only manifest in the repository root, and it says more about constraints than about features. It fixes the Rust floor, the edition, the license and the version, and it lists every crate in the workspace, including bindings for Elixir, Java, JavaScript, C and Python:

[workspace.package]
authors = ["PRQL Developers"]
edition = "2021"
license = "Apache-2.0"
rust-version = "1.85.0"
version = "0.13.15"

resolver = "2"

Release builds are tuned for size over speed, with `lto = true` and `opt-level = "s"` under [profile.release], and the prqlc-c package strips its debuginfo symbols. The Python binding uses pyo3 with the `abi3-py310` feature, which targets the stable ABI from Python 3.10 upward.

Now the gap. Nothing in the manifest records which SQL dialects, database products or server versions the generated SQL is checked against, and the root README does not publish a support matrix either. The declared Rust floor is also verified by a different route: a comment states that it is not tested with cargo-msrv because cargo-msrv does not support workspaces, and that metadata.msrv in prqlc is tested instead. For a reader, version and dialect expectations have to be established by compiling your own queries, not by reading a published table.

Adoption runs through the editor and notebook integrations

PRQL's route into a team is its tooling rather than its syntax. The project lists a VS Code extension, Jupyter integration, a QStudio integration, the pyprql Python bindings with Jupyter magic, the prqlc-js JavaScript bindings published on npm, the Book, and a browser Playground for trying a query without installing anything. The Jupyter path is the widest of these: the magic runs PRQL either against a database or against a Pandas DataFrame, CSV or Parquet file through DuckDB.

The same strategy is stated in the status section, where making PRQL easy to start is equated with integrating with tools people already use, and the maintainers invite requests for other integrations in an issue. That tells you what happens when your tool is missing from the list. The root README documents no command line for the compiler binary; the prqlc crate is described as holding the CLI along with the bindings, and build instructions live in the development documentation instead.

So the honest evaluation question is whether your editor, notebook or business intelligence tool already appears there. If it does, a trial is cheap, since the Playground and the extension remove the build step. If it does not, you are writing a language binding yourself or compiling to SQL and checking the result by hand, and that cost lands on whoever maintains the pipeline.

The resolver is the bottleneck the maintainers name themselves

Development has slowed, and the repository says why: the team is deciding how to work on a new resolver. The stated goals for that resolver are to squash many bugs, simplify the compiler code, and let the language grow without the compiler's complexity growing with it. The same section notes that contributions to the compiler are quite concentrated even though the project has a wide group of contributors, and that the maintainers are increasingly open to bigger rewrites of the resolver precisely because they are bottlenecked on it.

For a reader the effect lands on latency rather than on features. A defect inside the resolver will not be fixed on the schedule a commercial vendor offers, and issue 1840 exists to collect feedback on exactly that constraint. Around the compiler there are ordinary contributor entry points: a good first issue label, development documentation, and an issue or Discord thread where resolver work is explicitly welcomed.

Commit activity is not the problem. The last push to the repository was on 2026-11-02, and tagged releases 0.13.14, 0.13.13 and 0.13.12 landed on 2026-07-24, 2026-06-14 and 2026-04-27. The code is moving. The constraint is how much of it a small review group can absorb at once.

Editorial conclusion

Adopt PRQL if your team writes the same shapes of query every day and can keep hand-written SQL running beside it while the maintainers work out the new resolver. Hold off if your workload leans on window functions outside a window transform or needs multi-file query libraries, since one is an open design question and the other is experimental. Before committing, compile your hardest existing query in the browser Playground rather than a toy example, read the open priority bug list for anything touching your database, and pin the compiler version, because the newest tag is 0.13.14 while the manifest already reads 0.13.15.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. PRQL/prql on GitHub
4. README
5. Releases