PostgreSQL 19: New Features and How to Use Them

PostgreSQL 19 Is in Beta — and It’s a Big One

PostgreSQL 19 reached Beta 2 in July 2026, with general availability expected around September–October 2026. It’s a landmark release, and several features land right on the pain points Oracle DBAs feel when they move to PostgreSQL. This is a preview of the ones that matter most and how you’ll use them — with one honest caveat up front: beta is for testing, not production. Details can still shift before GA, so try these on a throwaway PostgreSQL 19 beta instance, not your live database.

pg_plan_advice — Planner Control, at Last

This is the headline for anyone coming from Oracle. PostgreSQL has never had optimizer hints in core, so an Oracle DBA’s reflex — “pin this plan” — had no answer. PostgreSQL 19 introduces the pg_plan_advice extension, which lets you stabilize and steer planner decisions, plus a companion pg_stash_advice that can re-apply saved advice automatically by query identifier. It isn’t Oracle’s hint syntax and it isn’t a licence to override the planner everywhere — but for the rare query the cost model gets stubbornly wrong, you finally have a supported, native tool instead of reaching for a third-party extension. Pair it with the fundamentals (see our join tuning guide) — fix statistics and indexes first, use plan advice for the genuine exceptions.

REPACK — Online Table Maintenance, Built In

Bloat management is one of the first operational surprises for Oracle DBAs on PostgreSQL, and until now removing it without downtime meant the external pg_repackextension. PostgreSQL 19 brings a native REPACK command that rebuilds a table with less overhead, and a non-blocking REPACK CONCURRENTLY variant that lets the table stay available to reads and writes while it’s reorganized:

-- Reclaim bloat and repack a table without taking it offline
REPACK CONCURRENTLY orders;

Parallel Autovacuum

Autovacuum can now use multiple parallel workers on a single table, controlled by the new autovacuum_max_parallel_workers setting. On the large tables a migration produces, that means routine maintenance keeps up instead of falling behind — a direct answer to the “why is autovacuum always chasing my biggest table” problem.

Sequence Replication — A Real Migration Win

Logical replication in PostgreSQL 19 now replicates sequence values. If you’ve done a near-zero-downtime migration with logical replication, you know the classic gap: everything replicates except sequences, so at cutover you scramble to re-sync every sequence to its max value before the application writes. In 19, sequence values come across too, which removes one of the sharpest edges from replication-based upgrades and cutovers.

Quick Hits Worth Knowing

• ON CONFLICT DO SELECT — upserts can now return the conflicting row (INSERT … ON CONFLICT DO SELECT … RETURNING), giving you clean atomic get-or-create.
• MERGE / SPLIT PARTITIONS — ALTER TABLE … MERGE PARTITIONS and … SPLIT PARTITIONS reorganize partitioned tables in place, handy when reshaping tables migrated from Oracle partitioning.
• Online data checksums — enable or disable data_checksums without a cluster restart.
• LZ4 TOAST by default — default_toast_compression moves to lz4 for faster compression/decompression.
• JIT off by default — just-in-time compilation is now disabled by default, avoiding its occasional planning-time surprises.

Should You Wait for It?

For a migration you’re planning to cut over in late 2026 or beyond, PostgreSQL 19 is worth targeting — the sequence-replication and REPACK improvements alone smooth two of the rougher operational edges. But until GA, target the current stable release for anything production, and use the beta to test: stand up a PG 19 beta instance, rehearse your cutover, and confirm your extensions and managed-service provider will support 19 in your region before you commit.