PostgreSQL 19 Targets November 19, With RC2 Due First
PostgreSQL 19 was due October 29 and now targets November 19, with a second release candidate first. What changed, and is RC1 fit for your production upgrade?
- PostgreSQL 19 now targets November 19 for general availability, replacing the earlier October 29 target.
- A second release candidate is planned for November 12, incorporating fixes from supported branches.
- RC1 is for testing. Production migration requires a supported upgrade path and application compatibility checks.
November 19 replaces the October target
The October 15 RC1 announcement sets November 19 as PostgreSQL 19's planned general availability date. That remains conditional on testing: a significant issue could require another candidate or a delay. As of October 26, version 19 has not reached GA.
Jonathan S. Katz's September 28 schedule had targeted October 29. Teams working from that announcement need to revise their release assumptions before scheduling a production cutover.
| Milestone | Date | Status on October 26 |
|---|---|---|
| RC1 | October 15 | Released |
| RC2 | November 12 | Planned alongside supported-version updates |
| General availability | November 19 | Target, subject to testing |
RC2 brings existing fixes into the release process
In the October 10 schedule update, Katz attributed the decision to the volume of fixes added to supported branches. The team wants those changes in RC2 before proceeding to GA.
RC1 already includes corrections to concurrent REPACK, pg_plan_advice, and parallel autovacuum, among other areas. A feature's presence in a candidate does not establish that a particular application's use of it has been tested.
RC1 is a compatibility-testing opportunity
The project's beta information page explicitly excludes beta and release candidates from intended production use. Candidates are close to the initial final release, but further changes can still occur.
The useful work now is testing applications, drivers, and tools against the upcoming version. Starting the server is only an initial check. Running representative workloads helps expose regressions before a production migration and gives the project useful feedback.
Plan the data move and compatibility checks
The upgrade documentation distinguishes minor updates from major migrations. Major versions can change storage formats and application behavior. A move from 18 to 19 needs a migration method such as dump and restore, pg_upgrade, or replication.
The version 19 migration notes identify changes worth checking early. Successful MD5 password authentication now produces a warning; RADIUS support is removed. A warning about MD5 is not the same as removal of MD5 authentication.
The server also forces standard_conforming_strings to on. Dumps produced with older tools while using off have a documented loading incompatibility. Affected installations need to consider the specified remedies: newer dump tools or the on setting.
For an operations team, that suggests a concrete preparation sequence: identify authentication dependencies, choose the data migration path, and test the application's extensions and clients. Incorporate RC2's changes when it arrives before committing to the cutover date.
Frequently asked questions
Is November 19 guaranteed?
No. It is the current target, conditional on no issue requiring a further delay or release candidate.
Can version 19 simply use an existing version 18 data directory?
Do not treat a major upgrade as an executable replacement. Use a documented migration method and check the relevant compatibility changes.
Update both the release calendar and the migration plan: RC2 is expected on November 12, followed by the November 19 GA target.