PostgreSQL 19 slips to October as SQL/PGQ, GROUP BY ALL and partition merge are cut

PostgreSQL 19 has missed its usual late-September release window. The project shipped Beta 4 on September 24, 2026, and its announcement now points to a release candidate in early October, with general availability possible later the same month. According to a dev.to writeup of the cycle, the delay is a deliberate trade-off: the community pulled features that were not ready so the release stays dependable.

Where the release stands

PostgreSQL major versions normally arrive each autumn, in late September. As summarised on dev.to, the Beta 4 announcement plans a release candidate for early October and says GA may also happen in October, with the stated reason being that maintainers chose to strip out some features rather than ship them half-finished.

Snowflake's engineering post, published about a week before Beta 4, counted 53 reverts since the beta programme began, against roughly 44 across the whole PostgreSQL 18 cycle. What makes this year unusual, per Snowflake, is not the count but the timing: many reverts landed late and several hit headline features, often after reviews that used AI tools to hunt down bugs and build reproducible test cases.

What got cut

The Beta 4 announcement lists the changes since Beta 3: SQL/PGQ property graph queries, online enabling and disabling of data checksums, the temporal UPDATE/DELETE ... FOR PORTION OF syntax, ALTER TABLE ... MERGE PARTITIONS and SPLIT PARTITIONS, and the new pg_get_role_ddl(), pg_get_tablespace_ddl() and pg_get_database_ddl() functions are all out.

Earlier in the cycle, Snowflake's writeup records further reverts, including GROUP BY ALL, which a post-commit review found could return wrong results when ORDER BY entries used nondefault equality semantics. Non-text output formats for pg_dumpall, JSON_TABLE ON ERROR handling cascading to columns, fast defaults for domains with nonvolatile constraints, database-specific logical replication snapshots and nested query tracking in pg_stat_statements were also removed. Snowflake expects property graphs, GROUP BY ALL and partition merge/split to resurface as PostgreSQL 20 work.

The lz4 question

One item is genuinely unresolved. Snowflake reports that switching the default TOAST compression method from pglz to lz4 was reverted over missing buildfarm coverage, but the official release notes dated September 14 still list the change. The dev.to article advises treating the two sources as conflicting and checking the final notes at GA; in the meantime, the default_toast_compression setting can be configured explicitly.

What survived

The current release notes still include REPACK, which reclaims disk space and reorganises a table by combining VACUUM FULL and CLUSTER, with a concurrent option; pg_plan_advice, a new extension for stabilising query planner decisions; and parallel autovacuum, controlled via autovacuum_max_parallel_workers and a per-table autovacuum_parallel_workers setting. On the SQL side, INSERT ... ON CONFLICT DO SELECT ... RETURNING can now return conflicting rows, and IGNORE NULLS / RESPECT NULLS support has been added for lead(), lag(), first_value(), last_value() and nth_value().

Snowflake had flagged REPACK, the fast-path foreign key checks and the postgres_fdw statistics import as at-risk. Beta 4 subsequently shipped fixes for both REPACK and the foreign key check performance work, which the dev.to article reads as a sign both are still in, though nothing is final until GA.

Why it slipped

Snowflake attributes much of the churn to AI-assisted review: more contributors are using AI tools to surface bugs and produce reproducible cases, and the resulting fixes were large enough that deferring features to a later release made more sense than patching them in place. The company draws a parallel with security work, noting that PostgreSQL once averaged a couple of CVEs per release while the August 2026 patch drop for PostgreSQL 18 carried 28. Snowflake also observes that the project had no official policy on AI contributions at the time of writing.

The dev.to article's verdict is that the process is working as designed: unready features came out, and the reasoning is public on the project's hackers mailing list.

What to do before GA

Snowflake calls PostgreSQL 18 the safe production upgrade target today, and the dev.to article recommends staying there until 19 goes final. Its practical checklist: grep migrations, ORM-generated SQL and internal tools for the removed syntax, such as GROUP BY ALL, GRAPH_TABLE, FOR PORTION OF and MERGE/SPLIT PARTITIONS, and test the features you actually intend to use, especially REPACK and the foreign key changes, against real workloads on the beta.

Why it matters

The schedule slip itself is a matter of weeks, but the reverts rewrite upgrade plans for anyone who had budgeted around graph queries or partition merging in 19; that work now waits for the next major version. The cycle also shows how AI-assisted review is changing release dynamics, with heavier scrutiny surfacing more defects, later reverts and larger security drops. And the disagreement over the lz4 default is a reminder that until the GA release notes land, even documented features should be treated as provisional.