PostgreSQL 19 introduces native table repacking, more control over query plans and improvements to replication and maintenance. With general availability planned for November 19, 2026, teams should evaluate the benefits alongside important compatibility and operational limitations.
A major PostgreSQL upgrade can change how an application queries, maintains and replicates its data. Those changes can improve performance and reduce operational work. They can also expose dependencies that were not obvious under an earlier version. PostgreSQL 19 makes that assessment timely.
The PostgreSQL Global Development Group released PostgreSQL 19 RC1 on October 15, 2026. RC2 is scheduled for November 12, with general availability planned for November 19, provided no release-blocking issues arise. A release candidate is mostly identical to the planned final release, though some fixes may still be applied before general availability.
As of November 6, PostgreSQL 19 remains a release candidate. It is a pre-release version, and teams should test it outside production. The useful question for database teams is which changes deserve testing before the final release.
What is changing?
PostgreSQL 19 brings improvements across table maintenance, query planning, replication and database operations.
| Capability | What changes | What teams should evaluate |
|---|---|---|
Native REPACK | Rewrites tables to reclaim disk space | Locking, storage needs and transaction visibility |
pg_plan_advice | Influences selected planner decisions | Query performance and risk of outdated advice |
| Improved vacuum operations | Parallel index maintenance and prioritization improvements | Maintenance resource usage |
| Logical replication | Sequence synchronization and more flexible activation | Migration and switchover behavior |
Standby WAIT command | Waits for a specified write-ahead-log (WAL) position | Read consistency, latency and timeout handling |
| Compatibility changes | Modified defaults and removed functionality | Application, authentication and extension dependencies |
These capabilities serve different needs. Teams should prioritize those that address an actual operational problem rather than test every feature equally.
Source: PostgreSQL 19 preliminary release notes.
1. Native REPACK offers a new maintenance option
PostgreSQL tables can accumulate unused space as rows are updated or deleted. Ordinary VACUUM makes much of this space reusable, but usually does not return it to the operating system. PostgreSQL 19 introduces the native REPACK command, which rewrites a table and its indexes to reclaim space. It can also reorganize rows according to an index.
The CONCURRENTLY option permits ordinary table activity during much of the operation, avoiding the long exclusive lock required by a conventional table rewrite. That is useful, but concurrent repacking has important limitations.
It is not MVCC-safe. MVCC (multiversion concurrency control) is the mechanism that lets each transaction work from a consistent snapshot of the data. PostgreSQL warns that transactions using snapshots taken before the repacking operation began may see the table as empty after the repacking transaction commits.
Concurrent repacking also uses an exclusive lock during its final file-swap phase. It requires enough temporary disk space to hold another copy of the table and its indexes, with additional storage potentially required for sorting and concurrent modifications.
Other restrictions apply. For example, concurrent repacking is unavailable for partitioned tables, unlogged tables and certain tables without suitable identity information. A repack can also fail if DDL commands, which change a table’s structure, run on the table during the repacking, or under other documented conditions.
For these reasons, it should not be treated as a drop-in replacement for routine VACUUM. Database teams should first test representative tables, available disk capacity, transaction behavior, locking and recovery procedures. Where transaction ID wraparound prevention is the concern, PostgreSQL continues to recommend VACUUM, not REPACK.
What it offers
PostgreSQL 19 introduces the native REPACK command, which rewrites a table and its indexes to reclaim space. The CONCURRENTLY option permits ordinary table activity during much of the operation, avoiding the long exclusive lock required by a conventional table rewrite.
Limits to know
It is not MVCC-safe. PostgreSQL warns that transactions using snapshots taken before the repacking operation began may see the table as empty after the repacking transaction commits. Concurrent repacking also uses an exclusive lock during its final file-swap phase. It requires enough temporary disk space to hold another copy of the table and its indexes, with additional storage potentially required for sorting and concurrent modifications.
Test first
Database teams should first test representative tables, available disk capacity, transaction behavior, locking and recovery procedures. Where transaction ID wraparound prevention is the concern, PostgreSQL continues to recommend VACUUM, not REPACK.
Source: PostgreSQL 19, REPACK command documentation.
2. Query planning becomes more controllable
PostgreSQL normally chooses execution plans using statistics, cost estimates and optimizer rules. Occasionally, its estimates lead to a plan that performs poorly for a particular workload. PostgreSQL 19 introduces the pg_plan_advice module, which allows teams to describe and influence selected planner decisions. The related pg_stash_advice extension can associate stored advice with individual queries.
These tools can help teams investigate plan regressions or stabilize a known useful plan. However, plan advice does not replace the query optimizer. It works by constraining the planner’s available choices. It cannot force PostgreSQL to use a plan that the planner considers invalid or does not generate.
Advice can also become harmful when data distribution, indexes or workload characteristics change. For example, advice that favors a particular index might help a query today but become inefficient after the underlying table grows substantially.
The right approach is to begin with reliable statistics, appropriate indexes and query analysis. Planner advice should be introduced only where repeatable evidence justifies it. Teams should also monitor whether supplied advice remains applicable over time.
Sources: PostgreSQL 19, pg_plan_advice documentation and PostgreSQL 19 preliminary release notes.
3. Replication becomes more flexible
PostgreSQL 19 introduces changes that could simplify selected replication and migration workflows. One improvement allows logical replication subscribers to maintain sequence values in alignment with the publisher. That can be useful during migrations where generated identifiers must continue correctly after a switchover.
PostgreSQL 19 also permits logical replication to be enabled under supported conditions when wal_level is set to replica, without the restart previously associated with changing that configuration. These changes reduce some configuration and migration work, but they do not remove the need to verify synchronization, data consistency or failover behavior. Another significant improvement concerns read consistency on standby servers.
The WAIT command and read-your-writes consistency
In asynchronous replication, a write can commit on the primary before a standby has replayed it. An application that immediately reads from the standby may therefore see older data. PostgreSQL 19 introduces WAIT FOR LSN, allowing an application to wait until a specified write-ahead-log position has been reached. A log sequence number (LSN) identifies a position in the write-ahead log.
For read-your-writes behavior, the application must obtain an appropriate WAL location from the primary after the relevant transaction commits, then wait for that location to be replayed on the standby. The distinction between WAL being written, flushed and replayed matters. Only successful replay establishes that the relevant committed changes are available to subsequent reads on that standby.
Commit on the primary
In asynchronous replication, a write can commit on the primary before a standby has replayed it. An application that immediately reads from the standby may therefore see older data.
Get the WAL position
For read-your-writes behavior, the application must obtain an appropriate WAL location from the primary after the relevant transaction commits, then wait for that location to be replayed on the standby.
Wait on the standby
PostgreSQL 19 introduces WAIT FOR LSN, allowing an application to wait until a specified write-ahead-log position has been reached. Waiting may also add latency. The command supports timeout handling, but an omitted or zero timeout can result in an indefinite wait.
Then read
Only successful replay establishes that the relevant committed changes are available to subsequent reads on that standby. Applications must handle timeouts, standby promotion and recovery interruptions appropriately.
Waiting may also add latency. The command supports timeout handling, but an omitted or zero timeout can result in an indefinite wait. Applications must handle timeouts, standby promotion and recovery interruptions appropriately. This is a useful consistency mechanism, not a replacement for replication monitoring or application-level failure handling.
Source: PostgreSQL 19, WAIT documentation.
4. Maintenance and performance improvements
PostgreSQL 19 also improves how databases perform background work. Changes include more flexible autovacuum prioritization and parallel index maintenance, along with planning, execution and I/O enhancements.
These improvements can help particular workloads, but their effects depend on table sizes, index counts, configuration and available resources. Parallel vacuuming, for example, primarily concerns index vacuuming and index cleanup phases. It does not make all vacuum operations parallel or guarantee faster completion.
Similarly, more sophisticated autovacuum prioritization does not remove the need to monitor table growth and maintenance progress. Teams should measure maintenance duration, I/O utilization, query latency and resource contention before and after the upgrade. The release notes describe the capabilities, but production performance must be demonstrated against representative workloads.
Source: PostgreSQL 19, Routine Vacuuming.
5. Compatibility changes deserve particular attention
Several PostgreSQL 19 changes may affect existing applications and operational tooling.
| Change | Potential consequence |
|---|---|
| JIT (just-in-time) compilation disabled by default | Some analytical workloads may require explicit JIT configuration |
| RADIUS authentication removed | Installations using RADIUS must migrate to another supported authentication method |
standard_conforming_strings forced on | Older SQL scripts or database dumps relying on the previous behavior may need changes |
Default index operator classes for inet and cidr changed | pg_upgrade refuses clusters that have btree_gist indexes on these types, so they need corrective work first |
| Changes to system interfaces and configuration | Monitoring tools, extensions or automation may need compatibility updates |
One particularly important issue concerns database dumps. PostgreSQL warns that dumps created using older pg_dump or pg_dumpall versions with standard_conforming_strings disabled may not load correctly into PostgreSQL 19. Teams should use a supported dump process and verify restoration rather than assume an old backup is compatible.
The release notes also identify cases where pg_upgrade will refuse to upgrade clusters containing particular incompatible indexes or object names. A major-version upgrade requires an appropriate migration strategy, such as pg_upgrade, dump and restore, or a suitable logical-replication approach. Updating packages as though this were a minor release is insufficient.
Source: PostgreSQL 19, Migration and Compatibility Notes.
What should database teams test now?
A useful release-candidate evaluation can remain focused.
Application compatibility: Run representative application and integration tests against PostgreSQL 19 RC1. Include SQL behavior, authentication, extensions and database drivers.
Critical queries: Compare execution plans and actual performance for queries that affect business operations.
Maintenance behavior: Test REPACK and vacuum improvements on representative data. Include disk usage, locking, old-snapshot behavior and failure conditions.
Replication: Validate sequence synchronization, standby WAIT behavior, latency and error handling where those features are relevant.
Migration and recovery: Rehearse the supported upgrade method, confirm that backups can be restored and document the recovery path if the migration fails.
Application compatibility
Run representative application and integration tests against PostgreSQL 19 RC1. Include SQL behavior, authentication, extensions and database drivers.
Critical queries
Compare execution plans and actual performance for queries that affect business operations.
Maintenance behavior
Test REPACK and vacuum improvements on representative data. Include disk usage, locking, old-snapshot behavior and failure conditions.
Replication
Validate sequence synchronization, standby WAIT behavior, latency and error handling where those features are relevant.
Migration and recovery
Rehearse the supported upgrade method, confirm that backups can be restored and document the recovery path if the migration fails.
Outside production
These tests should take place outside production. The RC1 announcement says further fixes may still be applied before general availability, so a release candidate is not a basis for production workloads.
These tests should take place outside production. The RC1 announcement says further fixes may still be applied before general availability, so a release candidate is not a basis for production workloads.
What about existing PostgreSQL installations?
Not every organization needs PostgreSQL 19 immediately. Teams already running supported PostgreSQL versions should maintain current security updates while evaluating whether the major upgrade provides meaningful operational value.
PostgreSQL 14 requires more immediate attention. The PostgreSQL project has scheduled the end of community support for version 14 on November 12, 2026.
Organizations still using PostgreSQL 14 should prioritize moving to a supported version. That does not necessarily mean waiting for PostgreSQL 19 or adopting it on its first release day.
Source: PostgreSQL versioning policy.
The practical significance of PostgreSQL 19
PostgreSQL 19 offers useful improvements in database maintenance, query-planning control and replication. It also introduces behavioral changes that require deliberate testing. Native repacking can reclaim space, but concurrent operation has important transaction-visibility and resource constraints. Planner advice can address difficult queries, but can become harmful when workloads change. Replication improvements offer more control, but still require careful consistency and failure handling.
Database teams should use the release-candidate period to verify which improvements benefit their workloads and which changes require preparation before a production upgrade.
References and further reading
- PostgreSQL Global Development Group, PostgreSQL 19 RC1 Released. October 15, 2026.
- PostgreSQL 19 Release Notes. Preliminary feature and compatibility details.
- PostgreSQL 19 REPACK Documentation. Operational requirements and MVCC warning.
- PostgreSQL 19 pg_plan_advice Documentation. Planner behavior and limitations.
- PostgreSQL 19 WAIT Documentation. Standby consistency and timeout behavior.
- PostgreSQL 19 Routine Vacuuming. Vacuum and parallel maintenance behavior.
- PostgreSQL Versioning Policy. Supported versions and end-of-support dates.
Source verification: November 6, 2026. PostgreSQL 19 remains a release candidate, and the PostgreSQL 19 documentation pages cited here are pre-release versions. The November 12 RC2 and November 19 general-availability dates are planned, not confirmed releases. Features and compatibility details should be rechecked against the final release documentation before public publication.