Nice project. A few thoughts from someone who writes a lot of SQL and Python against DuckDB.

You are in good company, and it is worth saying so in the README. "Stages in execution order" is exactly what PRQL does (it also compiles to SQL, DuckDB dialect included), what KQL does in Azure Data Explorer (T | where ... | summarize ... | top 10 by ...), what dplyr does in R, and what LINQ, Polars and pandas method chains do inside general-purpose languages. Google published "pipe syntax" for GoogleSQL in 2024 (FROM orders |> WHERE ... |> AGGREGATE ...), and DuckDB itself now accepts FROM-first queries with an optional SELECT. So the industry has mostly voted "yes" on pipeline order already; the open question for a reader is "why this one". I would put a short comparison with PRQL and pipe-syntax SQL near the top of the docs, because that is the first thing an experienced user will look for.

Discoverability vs familiarity. Pipeline order wins in two places. First, teaching: it matches SQL's logical evaluation order (FROM, WHERE, GROUP BY, HAVING, SELECT, ORDER BY, LIMIT), which is the thing beginners trip over. Second, tooling: once from comes first, the editor knows the schema at every later line, so autocomplete and type errors become cheap to implement. Where it loses: everything else in the stack (ORMs, BI tools, dbt, colleagues) speaks SQL, so the language lives or dies on the quality of the escape hatch. Keep the generated SQL readable and stable, and give people a one-command way to "eject" to plain SQL.

A concrete grammar suggestion: you may not need having as a keyword. In a pipeline, a filter placed after aggregate is a HAVING; the position already disambiguates. PRQL does exactly this and it removes one concept to learn.

What I would add next, in this order:

1. Named intermediate pipelines (let paid = from orders | filter status = 'paid') compiled to CTEs. This covers most "nested subquery" needs without nested syntax, and it is where the pipeline model shines.
2. Window functions. This is the hardest part for pipeline languages, because a window is "a group that keeps its rows". Look at how PRQL scopes window inside group before designing it; the simple case is easy, rows between is where it gets painful.
3. Joins with an explicit side (join side:left) and a join-key syntax that cannot be confused with a filter.
4. Write statements last. Read-only is a feature early on: it keeps the compiler small and makes the tool safe to point at production data.

What makes me try a new query language instead of a SQL generator I already have:

• Error messages that point at my source line and column, not at the generated SQL.
• A --show-sql flag so I can learn from and audit what it produces.
• Zero-friction embedding: pip install unsequel, a to_sql(text) function that returns a string, and a Jupyter cell magic. Since you already target DuckDB, a Python API is the shortest path to real users.
• A formatter and an LSP with autocomplete, which the pipeline design makes feasible.
• Semantics documented as "this stage maps to this SQL", so I never have to guess.

I would hold off on anything that does not compile to a plain SQL string, because that is what keeps the language a thin layer rather than a new database.