"Was GROUP BY ALL Removed from PostgreSQL 19?"
Was group by all removed from postgresql 19? Yes — reverted before beta 3 over an ORDER BY wrong-results bug. The full story, the DuckDB/Snowflake comparison, and the workaround.
Short answer first: was group by all removed from postgresql 19? Yes — reverted before beta 3 (July 2026) after a post-commit review found it producing wrong results in some queries. Any tutorial, video, or beta-era roundup telling you GROUP BY ALL is a PostgreSQL 19 feature is outdated. This post covers the full story: what the syntax was supposed to do, the ORDER BY bug that killed it, which databases actually have it today (DuckDB, Snowflake, BigQuery, ClickHouse, Databricks — Postgres isn't among them), the explicit-column-list workaround you'll write instead, and the honest PG20 outlook. Status: This is an explainer, not a tutorial — you can't run GROUP BY ALL on PostgreSQL 19 because the syntax doesn't exist there. PostgreSQL 19 itself is still in beta (beta 4 shipped 2026-09-24; RC1 scheduled 2026-10-15; GA scheduled 2026-10-29). Last updated: October 4, 2026 What you'll learn What GROUP BY ALL does and why people want it The revert timeline: group by all postgres 19 reverted before beta 3 The ORDER BY nondefault-equality bug that produced wrong results Which engines support GROUP BY ALL (DuckDB, Snowflake, BigQuery, ClickHouse, Databricks) and which don't (Postgres, MySQL, Dremio) The explicit-column-list workaround for Postgres today The real PG20 outlook — reported, not confirmed What GROUP BY ALL Even Does The idea is simple. In standard SQL, every non-aggregated column in your SELECT list must appear in GROUP BY : -- Standard Postgres today: you repeat yourself SELECT title, type, COUNT(*) FROM movies GROUP BY title, type; GROUP BY ALL means "group by every non-aggregated SELECT expression, automatically": -- DuckDB / Snowflake / BigQuery: this works today SELECT title, type, COUNT(*) FROM movies GROUP BY ALL; Add a column to…