Postgres 19 Ships REPACK CONCURRENTLY, Partition Merges, and Sequence Sync

Postgres 19 finally gives production DBAs a built-in REPACK CONCURRENTLY command, eliminating the reliance on the pg_repack extension for online table reorganization.

REPACK CONCURRENTLY Ends a Long-Standing Workaround

Anyone who has operated Postgres at scale has faced the choice: let table bloat grow or take a heavy lock with VACUUM FULL. The ecosystem filled the gap with pg_repack, but external extensions add deployment and compatibility friction. Postgres 19 brings REPACK CONCURRENTLY into core. That means you can now reclaim space and reorganize tables without blocking writes — no extension required. This is the kind of quality-of-life upgrade that makes a release stick in the memory of anyone running production databases.

Partition Merges and Splits Fix a Real Operational Problem

Partitioning strategy is rarely right on the first try. Data volume shifts, retention windows change, and some partitions grow lopsided. Postgres 19 tackles this with ALTER TABLE ... MERGE PARTITIONS and SPLIT PARTITION. You can now combine January and February into a single quarterly partition or split an oversized quarterly partition into monthly chunks:

ALTER TABLE customer_orders MERGE PARTITIONS (orders_2026_q1, orders_2026_q2) INTO orders_2026_h1;
ALTER TABLE customer_orders SPLIT PARTITION orders_2026_q3 INTO (
 PARTITION orders_2026_07 FOR VALUES FROM ('2026-07-01') TO ('2026-08-01'),
 PARTITION orders_2026_08 FOR VALUES FROM ('2026-08-01') TO ('2026-09-01'),
 PARTITION orders_2026_09 FOR VALUES FROM ('2026-09-01') TO ('2026-10-01')
);

This moves partitioning from a set-and-forget decision to something you can evolve with your workload.

Logical Replication Catches Up to Production Needs

Logical replication has been maturing over several releases. Postgres 19 fills three specific gaps. Sequence values now synchronize to subscribers — no more cutover headaches where generated IDs jump unexpectedly after migration. Publications gain an EXCEPT clause, so publishing "all tables except these few" is a one-liner. And wal_level = replica can now enable logical replication on demand, with a new effective_wal_level view to report what's actually active. These are small changes that remove configuration footguns and align the feature with how operators actually want to use it.

Autovacuum also gets parallel workers (controlled globally and per table), giving Postgres more muscle to keep up with bloat on large indexes.

With Postgres 19's beta out, the feature set suggests this release will be remembered as the one where the database's operational tooling finally caught up with the demands of running it at scale.

Source: Looking Ahead to Postgres 19
Domain: snowflake.com