PostgreSQL 19 reaches RC1 with REPACK, pg_plan_advice, and sequence synchronization

The first release candidate of PostgreSQL 19 became available on October 15, 2026. According to the schedule described by Tom Kincaid on Planet PostgreSQL, the community plans a second RC on November 12 and general availability (GA) on November 19, provided no issue requires another round of fixes.

For those running databases in production, the bar doesn't change: PostgreSQL 18 remains the production target until PostgreSQL 19's GA ships. What changes is the urgency of setting up a staging environment with RC1 now, before the testing window closes.

Why so many features fell by the wayside

A significant number of features announced in earlier betas were reverted before this RC. Among those dropped are graph queries over properties via SQL, partition merging and splitting, the ability to turn data checksums on and off while the server is running, GROUP BY ALL, and UPDATE/DELETE ... FOR PORTION OF.

The community's official justification, cited by Kincaid, is direct: reliability comes first, along with the commitment to keep a predictable release calendar. Peter Eisentraut, of EnterpriseDB, described in a recent reflection a set of overlapping pressures: architectural problems in some features, AI-assisted review turning up more edge cases, and senior developers spending time on security fixes that, in another scenario, would have been available to review the beta.

It's worth separating two things that Eisentraut's account carefully distinguishes: AI accelerating the discovery of problems doesn't mean the problematic code was written by AI. The concrete data point illustrating this effect: the August 2026 maintenance release for PostgreSQL 18 addressed 28 CVEs, in a project that historically fixed about two per cycle. More rigorous review finds more flaws, faster, but that only helps if the capacity to investigate, fix, and review keeps pace.

REPACK: reorganizing a table without stopping the application (almost)

The new REPACK command rewrites a table to reclaim unused disk space and can reorganize rows using an index. With REPACK CONCURRENTLY, reads and writes continue during most of the work, because concurrent changes are captured via logical decoding and applied before the operation finishes.

This solves a real pain point for applications with heavy update traffic, where the DBA historically had to choose between leaving the table unavailable or postponing maintenance that would benefit overall performance. But concurrent doesn't mean lock-free: the final swap between the old and new table still requires an ACCESS EXCLUSIVE lock. The operation also consumes temporary disk space, and the documentation warns about visibility behavior for transactions using snapshots taken before the repacking started.

The development brings together Álvaro Herrera (EDB), Antonin Houska, and Mihail Nikalayeu, an example of how the engineering behind a community release crosses company lines.

What to test: pick a representative table, one with frequent updates and deletes. Run REPACK CONCURRENTLY under realistic write activity with long-running transactions in parallel. Measure reclaimed space, temporary disk usage, application latency during the operation, and, above all, the duration of the final lock, not just whether the command finished. Given the amount of revision this feature received, keep a rollback plan ready.

pg_plan_advice: fine-grained control, with risk built in

PostgreSQL 19 introduces the pg_plan_advice module, which lets you describe, reproduce, and constrain specific planner decisions, including join order and scan method. With the module loaded, EXPLAIN (PLAN_ADVICE) generates an advice string describing those choices; the companion extension pg_stash_advice can store that advice by query identifier and apply it automatically.

Robert Haas implemented pg_plan_advice during his time at EDB, and the company already signals it will build additional features on top of this foundation to help customers recover quickly from plan instability.

It's important not to confuse this with a magic performance switch. The advice narrows the universe of choices the planner considers: it doesn't replace the optimizer, nor does it guarantee the same plan under every circumstance. The documentation itself warns: a constraint that helps today may, as the data changes, prevent the planner from choosing a better approach tomorrow.

What to test: start with the queries whose plans have caused problems in the past. Compare the planner's normal choices against advice applied in a tightly targeted way, using data and parameter values representative of your workload. Keep the intervention as narrow as possible, and periodically reassess whether it's still useful as load changes.

Autovacuum with priority and targeted parallelism

Version 19 lets autovacuum use parallel workers for index scanning and cleanup, and introduces a scoring system to prioritize vacuum and analyze work. The pg_stat_autovacuum_scores view exposes these priorities.

This is targeted parallelism, not a promise that every stage of vacuum now runs in parallel. For day-to-day database operators, the relevant question isn't how many workers you can launch, but whether maintenance can keep up with the tables that need it most, within the resources available.

What to test: combine busy tables with constant updates and larger, less active tables. Inspect the scores in pg_stat_autovacuum_scores, observe which work gets prioritized, and compare maintenance duration against application latency and resource consumption. The goal is a healthier workload, not just a busier maintenance subsystem.

Logical replication: synchronizing sequences, with clear limits

PostgreSQL 19 adds the ability to synchronize sequence values from the publisher to the subscriber. Initial synchronization can happen when the subscription is created, and the ALTER SUBSCRIPTION ... REFRESH SEQUENCES command resynchronizes already-known sequences afterward.

Two details matter for anyone planning a migration or cutover based on this:

• The publisher must be running PostgreSQL 19 or newer; upgrading only the subscriber doesn't enable the feature for an older publisher.
• Sequence values can drift out of sync again as the publisher advances the sequence: this isn't continuous synchronization, and it doesn't remove the need to think through the cutover procedure itself.

What to test: rehearse the sequence-handling part of your migration or cutover procedure end to end. Check whether sequence definitions match, whether synchronization actually completes, and what values the application will generate after the cutover. Test the whole flow, not just whether the command runs without error.

What else deserves attention before GA

These four areas are a starting point, not a complete upgrade checklist. Compatibility and default-behavior changes matter too: PostgreSQL 19 disables JIT compilation by default, so teams running analytical workloads that depend on JIT for performance need to explicitly evaluate this setting, rather than assume current behavior will hold.

Other smaller additions are worth noting: ON CONFLICT DO SELECT lets upserts return already-existing rows, and window functions gain support for IGNORE NULLS.

It's worth remembering that EDB has funded testing packages for the community for more than 15 years, including the RPM packages and the Beta 4 packages for the PostgreSQL Global Development Group, a reminder that community testing infrastructure doesn't appear on its own.

The practical work before November

A release candidate is still a test version, not a production recommendation. Set up a non-production environment that reflects your actual deployment: application queries, extensions, drivers, data distribution, and maintenance routines. Include upgrade and recovery rehearsals, not just isolated feature demos.

The community gathers in Valencia for PGConf.EU between October 20 and 23, days after this RC1. The question worth bringing there, and back home, isn't just which features made it into version 19. It's which operational problems it helps solve, where the new capabilities demand careful configuration, and what your own testing reveals before someone finds out in production.