PostgreSQL 19 GA Date Moves to November 19 After New RC2

PostgreSQL 19's general availability date has moved. The project's release team now plans to ship PostgreSQL 19 on November 19, 2026 — three weeks later than the October 29 target that followed the release candidate 1 (RC1) announcement on October 15. The delay comes because the team decided to fold the fixes from the November 12 scheduled minor-version update release into PostgreSQL 19 first, which means a second release candidate, RC2, is now also due on November 12, 2026.

Why the GA date moved

When PostgreSQL 19 RC1 shipped on October 15, 2026, the release notes pointed to general availability arriving around the end of October. That timeline has since changed. According to the official PostgreSQL news page, the release team is now planning a second release candidate, RC2, for November 12, 2026 — the same day the project ships its regular quarterly round of scheduled minor updates for every supported PostgreSQL branch (18 down through 14).

Rather than let PostgreSQL 19 go to general availability a week or two ahead of that update release and then immediately need a point release to catch up, the release team chose to pull the November 12 fixes into PostgreSQL 19 itself via RC2. That pushes general availability out to November 19, 2026, which the announcement describes as the plan "unless a problem requires a delay or another release candidate" — standard release-team language that leaves room for a further slip if RC2 turns something up.

RC2 and the November 12 scheduled update

PostgreSQL's release cadence normally keeps new-feature work and bug-fix maintenance on separate tracks: a major version (like 19) goes through alpha, beta and RC stages on its own schedule, while every supported existing version (currently 14 through 18) gets quarterly minor updates on fixed dates regardless of what's happening with the next major release. November 12, 2026 happens to be one of those fixed update dates.

By timing RC2 to land on the same day, the project can carry the same fixes into PostgreSQL 19's first stable release instead of shipping 19.0 without them and issuing 19.1 soon after. For anyone tracking the release purely by date, the practical upshot is simple: RC2 is a checkpoint, not a sign of a major new problem, and general availability is still expected one week after it, on November 19.

PostgreSQL 14 reaches end-of-life the same day

November 12, 2026 carries a second piece of news for anyone running an older PostgreSQL install: it's also the final scheduled release date for PostgreSQL 14, according to the project's official versioning policy page. PostgreSQL follows a five-year support window for each major version, and 14 — first released in September 2021 — ages out of community support on that date, receiving no further security or bug-fix updates afterward.

The coincidence of dates means teams still on PostgreSQL 14 effectively get one more maintenance release before the branch closes out, on the very day PostgreSQL 19's RC2 appears. Anyone on 14 who hasn't already planned a major-version upgrade should treat November 12 as the real deadline, not November 19.

What changed since Beta 4

The RC1 announcement also lists a set of fixes and refinements made since PostgreSQL 19's Beta 4, ahead of the stable release. The project doesn't spell out every change in the announcement text itself — it points to the PostgreSQL 19 Open Items wiki page for the full list — but it does call out several specific areas:

• REPACK (CONCURRENTLY): several fixes to the new concurrent repack command.
• pg_plan_advice: several fixes to the new planner-advice feature.
• Query planner optimizations: fixes for new optimizations that depend on whether an expression can be NULL.
• Automatic logical replication enablement: fixes for automatically enabling logical replication when wal_level is set to replica (see effective_wal_level).
• postgres_fdw statistics import: importing statistics for a foreign table now runs as the table's owner instead of as the user who ran ANALYZE — a change worth noting for anyone relying on foreign-data-wrapper permissions.
• Parallel autovacuum: several fixes related to autovacuum_max_parallel_workers.
• COPY (query) TO ... (FORMAT json): JSON keys in the output now use the query's column names, including aliases, instead of the underlying table's column names.

None of these are new headline features — they're refinements to capabilities that were already part of PostgreSQL 19's beta cycle, which Pandromeda covered when RC1 first shipped. The pattern is normal for a release candidate stage: tightening up new features like pg_plan_advice and parallel autovacuum rather than introducing anything further.

What PostgreSQL 19 brings, briefly

With the release itself still a few weeks out, it's worth a quick recap of what PostgreSQL 19 actually changes, based on the project's own beta announcement and release notes. The headline performance item is the new REPACK command and its nonblocking REPACK CONCURRENTLY variant, which let administrators rebuild a table with less operational overhead than the existing combination of VACUUM FULL, CLUSTER, and the third-party pg_repack extension. Alongside it, autovacuum gains the ability to use parallel workers through the new autovacuum_max_parallel_workers setting, plus a new scoring system to prioritize which tables get vacuumed first, and a strategy that can mark pages visible while they're being queried to cut down future vacuum work.

The planner and executor pick up several changes too: new anti-join optimizations, broader use of incremental sorts, eager aggregation, and faster reads during parallel sequential scans. The project's own figures describe up to 2x better insert performance when foreign key checks are present. For query tuning specifically, the new pg_plan_advice extension lets administrators stabilize and control planner decisions, with a companion pg_stash_advice tool to apply that advice automatically by query identifier — useful for locking in a good plan after an upgrade or a statistics change.

On the developer-experience side, PostgreSQL 19 adds SQL/PGQ support for property-graph queries using standard SQL syntax, a GROUP BY ALL shorthand, ALTER TABLE ... MERGE PARTITIONS and SPLIT PARTITIONS for reorganizing partitioned tables in place, and a new WAIT FOR LSN command that makes "read-your-writes" patterns against replicas easier to implement. Logical replication now carries sequence values along with table data, and publications can use the new CREATE PUBLICATION ... EXCEPT syntax to publish everything except a specified set of tables. The postgres_fdw foreign data wrapper — the same extension behind the statistics-ownership fix noted above — also picks up performance work, including pushing array operations down to the remote server.

A few changes are worth flagging precisely because they alter defaults: just-in-time (JIT) compilation is now disabled by default, default_toast_compression switches to lz4, and support for RADIUS authentication is removed outright. Anyone testing RC1 or planning to test RC2 against an existing workload should check whether any of those default changes affect their setup before relying on the new release.

Upgrade path: there is no in-place upgrade

As with every past major PostgreSQL release, RC1 (and the upcoming RC2) cannot be upgraded in place from PostgreSQL 18 or any earlier version. The official documentation directs administrators to a major-version upgrade method such as pg_upgrade or a pg_dump/pg_restore cycle. Teams testing against the release candidates now should plan on repeating that upgrade process again once 19.0 ships, since RC builds are not meant for production data.

For shops running a mixed toolchain alongside PostgreSQL — Python-based migration or ETL scripts, for instance — it's worth keeping the rest of the stack current too; Pandromeda's recent look at the uv Python package manager covers one popular option for keeping those dependencies pinned and reproducible while a database upgrade is in flight.

A later-than-usual release, by the project's own earlier estimate

PostgreSQL has shipped a new major version every year for over a decade, and the project's own beta documentation framed PostgreSQL 19 the same way: the first beta announcement described the plan as "additional betas as required for testing, followed by one or more release candidates, until the final release around September/October 2026." A November 19 general-availability date is a few weeks past even that original window, on top of the three-week slip from the RC1-era October 29 estimate.

None of this is unusual for an open-source database with PostgreSQL's testing standards — release candidates exist specifically so the project can catch exactly the kind of fix (the November 12 scheduled-update batch) that prompted RC2, rather than shipping it as an urgent point release right after GA. But it does mean anyone who had penciled in an October or early-November upgrade window, based on the RC1 announcement alone, now has a firmer date to work from: November 19, assuming RC2 doesn't surface anything that pushes things further.

What this means for teams planning upgrades

For most PostgreSQL users, the three-week slip changes planning more than it changes substance. Nothing in the official announcement suggests a serious defect pushed the date — the explanation given is entirely about release sequencing, folding one set of already-scheduled fixes into PostgreSQL 19 before calling it stable. Teams that had blocked out time around October 29 for a GA upgrade should move that window to on or after November 19, and build in the usual buffer for a .1 patch release that typically follows a few weeks after any major PostgreSQL GA.

Teams still running PostgreSQL 14 have a more concrete decision to make before November 12: either complete a major-version upgrade (to 18, the current stable release, or wait for 19's GA) or accept that the branch will stop receiving official security and bug fixes after that date.

Why this matters beyond the calendar

A slipped release candidate schedule rarely makes news on its own, but PostgreSQL's unusually large install base — from small side projects to managed offerings run by every major cloud provider — means a three-week shift in a major-version GA date has knock-on effects. Cloud vendors that pre-announce support timelines for new major versions, consultancies scheduling client upgrade windows, and teams that budgeted downtime around the original October 29 estimate all need to adjust. The fact that the project chose to delay rather than ship PostgreSQL 19.0 without the November 12 fixes is also a small data point about how the release team weighs stability against calendar targets: given the choice, they added a release candidate instead of promising a near-term point release to clean things up after GA.

What next

Watch the official PostgreSQL news page for the RC2 announcement on or around November 12, 2026 — it will confirm whether the November 19 general-availability date holds or needs to move again. If RC2 turns up nothing further, PostgreSQL 19.0 should become the new stable release exactly one week later. Pandromeda will update this coverage if the release team announces another slip or an additional release candidate.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage