The Order SQL
Actually Runs Your Query

SQL runs a query in a fixed logical order that is different from how you write it: FROM and JOIN first, then WHERE, GROUP BY, HAVING, SELECT, ORDER BY, and finally LIMIT. You write SELECT at the top, but it is evaluated fifth, after the rows have been filtered and grouped. This order is why a column alias created in SELECT cannot be used in WHERE, and why aggregates and window functions cannot be filtered there either.

The logical execution order is: 1) FROM and JOIN, 2) WHERE, 3) GROUP BY, 4) HAVING, 5) SELECT, 6) ORDER BY, 7) LIMIT / OFFSET. So the database builds and filters the row set first, groups it, filters the groups, then computes the SELECT columns, sorts them, and finally trims to the LIMIT. The clause you write first, SELECT, is the fifth thing to actually run.

Because WHERE runs at step 2 and the alias is not created until SELECT at step 5. When WHERE is evaluated, the alias simply does not exist yet, so the database throws an unknown-column error. The fix is to repeat the full expression in WHERE, or to compute the alias in a CTE or subquery and filter it in the outer query. An alias does work in ORDER BY, because ORDER BY runs at step 6, after SELECT.

Window functions are calculated during the SELECT step (step 5), which runs after WHERE (step 2). At the point WHERE is evaluated, the window result, such as a ROW_NUMBER or RANK, has not been computed yet, so you cannot filter on it. Wrap the query in a CTE or subquery and filter in the outer query, or use QUALIFY in databases that support it (Snowflake, BigQuery, DuckDB).

WHERE filters individual rows before grouping (step 2), so it cannot see aggregates. HAVING filters whole groups after grouping (step 4), so it can use COUNT, SUM and other aggregates. Rule of thumb: filter raw rows with WHERE, filter aggregated groups with HAVING. Writing WHERE COUNT(*) > 1 fails because WHERE runs before GROUP BY has produced any groups to count.

It comes down to timing. ORDER BY runs at step 6, after SELECT has created the alias at step 5, so the alias exists and is usable. WHERE runs at step 2, long before SELECT, so the alias does not exist yet. Same alias, different steps: that is the whole reason one works and the other errors.

Not exactly. The order described here is the logical query processing order that defines what a query means. The actual engine is free to reorder operations for speed, for example applying a filter earlier using an index, as long as the final result matches what the logical order would produce. So you reason about correctness with the logical order, while the optimiser handles physical performance behind the scenes.

Window functions run in the SELECT step (step 5), after WHERE, GROUP BY and HAVING, and before ORDER BY and LIMIT. That placement is the reason you cannot reference a window function in WHERE or GROUP BY, but you can sort by one in ORDER BY. To filter on a window result you compute it first (in a CTE or subquery) and filter in an outer query.

No. The logical order of execution is part of the SQL standard and is the same in PostgreSQL, MySQL, SQL Server, SQLite, BigQuery, Snowflake and Redshift. The only differences are surface syntax for the final step, such as LIMIT versus TOP or OFFSET ... FETCH, and extras like QUALIFY for filtering window results. The order the clauses evaluate in does not change.

DISTINCT runs after SELECT has computed the columns (so, between SELECT at step 5 and ORDER BY at step 6). It removes duplicate rows from the projected result, which is why DISTINCT applies to the full set of selected columns, not just the first one. Because it runs after SELECT, a SELECT alias is visible to it.