PostgreSQL 19 Release Candidate 1 Drops With Native REPACK, Parallel Autovacuum, and a Host of Changes That Aren't a No-Op Upgrade
The first candidate for the next major PostgreSQL version is out, but a few default flips mean you should think before you upgrade.
The PostgreSQL Global Development Group has announced the release of the first release candidate for PostgreSQL 19. If the release notes read like a shopping list, that's by design. The project is counting roughly 200 new features and enhancements, and the community is calling 19 one of the most significant "operational" releases in recent memory.
GA is set for November 19, 2026. That's about five weeks out. But here's the thing you should know before you start scheduling maintenance windows: several default changes in 19 mean the upgrade is not a no-op.
The headline grabber is a new native REPACK command. It unifies the old VACUUM FULL and CLUSTER commands, and it now supports an online CONCURRENTLY mode. That lets you rewrite a table without blocking reads and writes, which quietly undercuts the whole business model of the popular third-party pg_repack extension. Not bad for a feature that shows up once a year.
There's also parallel autovacuum, the ability to enable logical replication without a restart, sequence replication, and a new WAIT command that gives you read-your-writes consistency on standbys by waiting until a replica has replayed up to a chosen LSN.
The Operational Story
The real reason people are talking about 19 isn't any single feature. It's that the release touches nearly every workflow a database person actually does all day. Table bloat, lock waits, vacuum prioritization, replication footguns, query-plan stability, that's the whole runway.
Snowflake's Craig Kerstiens put it most cleanly. In his read of 19, the standout quality is breadth across personas. Operators get REPACK CONCURRENTLY, parallel autovacuum, and better monitoring. Developers get richer SQL, window-function IGNORE NULLS, improved upserts. Performance-focused users get the big planner batch, SIMD parsing, and async I/O visibility.
His takeaway was essentially that PostgreSQL is getting better as an application database, not just for one workload. Fair assessment.
Crunchy Data's Christopher Winslett took a more cautious, operator-first tack. He's right that native REPACK (CONCURRENTLY) is the clean path to reclaim bloat without a long exclusive lock, but it does come with fine print. It needs a primary key or replica identity, it won't run on partitioned parents, and it needs roughly two times the disk footprint during the rewrite. That last part bites people.
The "operations upgrade" framing keeps coming up in commentary, and it's earned. This isn't a case of the database quietly getting faster. It's a case of the tooling around the database catching up.
The Details That Will Make or Break Your Upgrade
Not everything in 19 is a shiny new feature. Some of it is a landmine disguised as a default change.
JIT is now off by default. It had been on since PostgreSQL 12, but the cost model that triggered it was deemed unreliable enough that the team pulled the plug. If you run a lot of large analytical queries, you'll need to manually re-enable jit and re-check your plans. Sites that silently depended on JIT being on may see performance drift they don't understand until they dig in.
TOAST compression defaults to LZ4 now, flipping off the old pglz. New data compresses faster. Existing data keeps the old algorithm until you rewrite or update it. So the immediate win is real but bounded.
RADIUS support is gone. The reasoning is defensible: PostgreSQL only supported RADIUS over UDP, which is "unfixably insecure." Say the word.
Then there are the compatibility landmines that make you double-check your toolchain. standard_conforming_strings is now always forced on, and escape_string_warning was removed. Dumps made with a pre-19 pg_dump under the old off setting will not load cleanly. The btree_gist inet/cidr opclasses are broken and can exclude rows, so pg_upgrade will actually refuse to upgrade a cluster still using them. Carriage returns and line feeds in database, role, or tablespace names are now disallowed, and pg_upgrade will reject those too.
Oh, and one thing people miss: max_locks_per_transaction doubled from 64 to 128. Lock size allocation changed as well, so if you were running at the old cap you may need to roughly double the setting to match prior capacity. A silent lock-limit regression is a fun way to spend a weekend.
For what it's worth, the good news is that RC 1 itself is a finished-feeling build. The team folded a big batch of fixes in since Beta 4, including several rounds on REPACK (CONCURRENTLY), pg_plan_advice, parallel autovacuum, and the automatic enablement of logical replication. There's also a fix so COPY (query) TO ... (FORMAT json) now uses the query's column names as JSON keys instead of the underlying table's.
What Was Cut
It's worth being explicit about what 19 isn't getting, because some third-party summaries list features that never made the final cut.
Partition splitting and merging (ALTER TABLE ... SPLIT/MERGE PARTITIONS) was reverted. The temporal FOR PORTION OF UPDATE/DELETE work is gone too. And yes, SQL/PGQ graph queries, which have shown up in a bunch of roundup articles as a headline feature, were pulled during the beta cycle. RC 1 does not include them. Some DDL-extraction functions (pg_get_role_ddl, etc.) were added in an early beta and then reverted in Beta 4 as well.
That's not a sign of flailing. It's the schedule discipline the project has been chasing since development began on July 1, 2025. Reliability first, predictable schedule second.
The Timeline and Your Next Steps
The schedule is tight and deliberate:
- RC 1: October 15, 2026 (today)
- RC 2: November 12, 2026. The team is folding the normal November maintenance fixes into 19 before GA, which is why a second candidate exists.
- GA: November 19, 2026, unless something turns up that forces a delay or another RC.
If you're planning to move, test against the RC before GA and specifically watch how the JIT-off and LZ4 flips affect your workloads. Re-check query plans for any heavy analytical traffic. Audit extensions against the new hooks, build_simple_rel_hook replaces get_relation_info_hook. And sanity-check that your clusters don't have btree_gist inet/cidr indexes or CR/LF in object names, since those block a clean pg_upgrade.
Head here to the release announcement.
