Home / Documentation / Comparison and scope
Comparison and scope
UNSeQueL is not the first language to make data transformations read like a pipeline, and it does not claim to be better than the established tools. This page is the honest version of where it sits and what it is for.
Existing ordered and pipelined syntax
| Tool | What it is |
|---|---|
| DuckDB FROM-first SQL | Put FROM first and defer or omit SELECT: FROM tbl SELECT * WHERE x > 1. |
| PRQL | A pipelined relational language that compiles to many SQL dialects, with variables, functions, and an embedded-SQL hatch. |
| Malloy | A semantic modeling and query language with composable queries (-> pipelines) over existing SQL engines. |
| Kusto (KQL) | A pipe-oriented analytics language for logs and telemetry, with operators like where, summarize, and project. |
| BigQuery GoogleSQL pipe syntax | |> pipe operators (WHERE, EXTEND, AGGREGATE, JOIN, ...) in any order, any number of times. |
| Spark SQL pipe syntax | The same idea for Spark: any query plus chained pipe operators. |
| Databricks SQL pipeline syntax | Pipeline operators in Databricks SQL and Runtime, including AGGREGATE with GROUP BY. |
If you already use one of these, its own documentation is the place to start. UNSeQueL is a small, independent implementation aimed at a narrower use: reading and teaching the relation stages with local files.
What this project actually is
- A compact stage model compiled to DuckDB SQL, with a CLI and a REPL.
- A way to run self-contained query files against local CSV, JSON, and Parquet data without flags.
- A stage-by-stage preview (
unsequel preview --stage N) that shows the relation at each point. - An editor workflow where selecting lines and running them behaves like a SQL client.
What it is not
- Not a replacement for SQL. Users still need to read and write SQL for real databases and warehouses; UNSeQueL compiles to SQL and inherits DuckDB's behavior.
- Not portable yet. The compiler targets DuckDB only. A second SQL target is deferred until feedback shows portability matters.
- Not a complete SQL implementation. DDL/DML, recursive queries, scalar subqueries inside expressions, window frames, user-defined functions, and streaming are out of scope today.
- Not proven to improve learning. The design goal is to make the supported pipeline easier to reason about, but no controlled study has tested that claim.
- Not a big project. It is a small open-source experiment with a small feature set and a small test suite, and it says so.
Why it still exists
- The stage list itself is a compact teaching artifact: read it top to bottom and the data flow is the query.
- Self-contained query files plus selection-based execution make the editor workflow feel like a database client rather than a program build step.
- Every stage has an explicit lowering (one CTE per unit), so the generated SQL is inspectable with
unsequel compile.
The learning benefit has not yet been measured. That sentence is repeated on purpose.