GoKawiilEvery Postgres release has a personality.
Some releases are about one big headline feature. Some are about removing a long-standing pain point. Some are full of those "oh, nice" improvements that you don't fully appreciate until you upgrade and suddenly your day-to-day workflow is just a little bit smoother. Oh, and of course almost every release has some performance improvements sprinkled in.
Postgres 19 feels like one of those releases that has a bit of everything. REPACK CONCURRENTLY is a big quality-of-life upgrade for larger production databases and it's built in. There are some big-ticket features, yes. SQL property graph queries are going to get a lot of attention. Logical replication keeps getting more complete. And then there are the steady improvements across VACUUM, EXPLAIN, COPY, partitioning, monitoring, performance and planner behavior that continue to make Postgres better not in a flashy way, but in the very practical "this helps me run production systems" way.
As always with a beta, details can change before GA. But with Postgres 19 now in beta, it's a good time to start looking at what is coming and, more importantly, what it means for people building and operating on Postgres.
REPACK out of the box
If you have operated Postgres for long enough, you have probably had a moment where you wanted to reclaim table bloat, rewrite a table or reorganize data — but you very much did not want to take the lock that came with VACUUM FULL or CLUSTER .
There has long been an extension ecosystem around this problem, most notably pg_repack . That alone tells you something: Users had a real need, and the ecosystem filled the gap.
Postgres 19 brings a new REPACK command into core, including support for REPACK CONCURRENTLY .
I expect REPACK CONCURRENTLY to be one of those features that production Postgres users care about more than the average release-note reader might expect.
Partitioning gets more practical
... continue reading