Postgres 19 finally reorganizes tables without locking, and borrows GROUP BY ALL from DuckDB

What actually changes when you upgrade

Craig Kerstiens, a director of software engineering at Snowflake, walks through the Postgres 19 beta feature by feature. The headline for operators is REPACK CONCURRENTLY: built-in table reorganization that reclaims bloat without taking a heavy lock, folding into core what people reached for the pg_repack extension to do. Partition management gets real too — you can now merge and split partitions in place, evolving schema without a full rebuild.

The rest is a broad quality-of-life sweep. Autovacuum gains parallel workers and a scoring system to prioritize what to clean. Logical replication learns to sync sequence values and publish ALL SEQUENCES. COPY can skip header lines, coerce bad values with ON_ERROR SET_NULL, and emit JSON. There's SQL/PGQ, property-graph querying over ordinary relational tables so you can run graph-shaped queries without standing up a separate graph database, plus planner wins like anti-join optimization and constant folding. And a batch of SQL sugar: GROUP BY ALL, IGNORE NULLS in window functions, INSERT … ON CONFLICT DO SELECT, and temporal UPDATE/DELETE FOR PORTION OF.

The thread argued about what's not in the release

For a feature roundup, the discussion spent surprisingly little time celebrating and a lot naming gaps. The most credentialed worry came from long-horizon data work:

"Speaking as long-term (>15 years) user of Postgres in science, I am getting worried about the lack of columnar type of storage in Postgresql. As the datasets become bigger and bigger, the limitations of PG's storage are becoming more and more significant." — an astrophysicist and data scientist using Postgres for 15+ years

Others piled on with their own missing-feature lists: synchronously-updated materialized views (SQL Server's indexed views), which one engineer called elegant and trivially correct for complex data situations; a pluggable storage-engine API à la MariaDB, so a RocksDB-style OLTP/OLAP backend could drop in; and, from the devops side, in-place upgrades between major versions, still a genuine pain inside Docker where pg_upgrade wants old and new binaries side by side.

The DuckDB asterisk, and the LLM-prose complaint

One of the most-liked additions came with a footnote. GROUP BY ALL is a real convenience, but a reader traced its origin:

"It's great to see GROUP BY ALL introduced which, AFAIK, was a concept introduced by DuckDB." — a commenter citing DuckDB's friendly-SQL docs

That's a small but telling reversal on a Postgres-is-leading narrative: several of the SQL niceties landing in 19 were first popularized by newer systems, DuckDB among them, and are only now being adapted upstream. And in a very Hacker News turn, a chunk of the thread ignored the database entirely to complain about the blog's writing — lines like "None of these change the world. All of them make day-to-day data workflows better" struck readers as LLM-polished, one joking that Orwell would learn Klingon to avoid reading them. For the practicing DBA, though, the substance is unglamorous and welcome: the release that finally lets you defragment a hot table without a maintenance window is worth the upgrade on its own.