PostgreSQL 19 release date: GA moves to November 19

The PostgreSQL 19 release date has moved. In an October 10 update to the pgsql-hackers list, Jonathan S. Katz wrote for the release team that general availability shifts to November 19, 2026, three weeks past the October 29 date set on September 28. Release candidate 1 keeps its October 15 slot, and a second candidate is added for November 12. The new date is the half of the story everyone will quote. The other half is that the release those dates describe has changed shape on the way: Beta 4 reverted more planned features than most cycles lose end to end, and the pages ranking for Postgres 19 today were almost all written before the cuts.

The schedule now runs through a second release candidate

The September 28 plan was the project's usual two-step: RC1 on October 15, then GA on October 29 "unless there are significant issues found during the release candidate period." Katz noted the timing logic too: a late-October GA leaves a couple of weeks of bug fixes before the November update release, "which is typically how we try to time the GA."

The October 10 update rearranged that sequence rather than just stretching it. "Given the volume of fixes that have been added to the back branches," Katz wrote, the team wants those fixes in testers' hands as a second release candidate, RC2, scheduled for November 12. GA then lands on November 19, one week after the planned update release instead of two weeks before it. The closing line names the reason plainly: "We know this has been an atypical major release cycle, but we want to ensure we keep delivering a PostgreSQL that's stable and reliable."

If you go looking for these dates on postgresql.org, you will not find them on a rendered page. The draft release notes for 19 still read "Release date: 2026-??-??", carrying an "AS OF 2026-09-14" stamp, and the newest 19 item in the project's news feed is Beta 4 from September 24. The mailing list runs ahead of every page the project renders, including its own.

Beta 4 cut features that most coverage still promises

The schedule is not the only thing that moved during this cycle. The Beta 4 announcement on September 24 carries a "Changes Since Beta 3" section that reads like a changelog in reverse. Gone from PostgreSQL 19:

• SQL/PGQ, the SQL-standard property graph query syntax, the headline feature of most early 19 coverage
• Online enabling and disabling of data checksums, which would have ended the offline pg_checksums dance
• Temporal updates and deletes through the FOR PORTION OF clause
• ALTER TABLE ... MERGE PARTITIONS and SPLIT PARTITIONS
• The pg_get_role_ddl(), pg_get_tablespace_ddl() and pg_get_database_ddl() functions, removed outright
• A behavior change that forced LC_COLLATE to C in the postmaster process, reverted

The announcement frames the mechanism without drama: the community chose to remove features "so they can be potentially be included in a later major release after more time working through the community development and review process." Reverting late is how this project protects a GA, and it is the right call every time. What is unusual here is the volume, several of the cycle's most quotable features at once. For operators, the two additions that matter most came through the cull intact: the REPACK command and the pg_plan_advice module, which we covered in depth in our Postgres 19 analysis.

Pages ranking for Postgres 19 describe a release that no longer exists

Search for Postgres 19 features today and the top results are overview articles written in the beta 1 window. One representative example: Devart's July 9 overview lists "newly added support for SQL Property Graph Queries over relational data" among the release's capabilities and expects general availability "around September or October 2026." Both claims were reasonable on July 9. Both are now wrong, and the page shows no update.

Nothing about that is specific to one vendor. Version coverage gets written when news value peaks, at the first beta. The reverts arrive at betas 3 and 4, when attention has moved on, and nothing in how the web works makes a published page notice that the project changed course. So search serves June's answer in November, with June's feature list and June's date. Anyone grounding a decision on those pages, whether a human planning an upgrade window or an AI assistant answering "what's new in Postgres 19," inherits the drift. The project's mailing list is the only channel that moves at the speed the facts do.

Postgres 14 now leaves support a week before 19 arrives

One date in this schedule did not move. The PostgreSQL versioning policy has Postgres 14 receiving its final release, 14.24, on November 12, 2026, the same day as RC2 and the November update release. General availability for 19 follows a week after 14's support ends.

That week matters for one specific plan: teams on 14 that looked at the calendar this summer, saw 19 landing around their deadline, and decided to wait and skip a major. The arithmetic no longer works even on paper, and in practice the gap is wider than a week, because running a brand-new major on production from day one is a choice few teams make. The width of the jump from 14 does not shrink by waiting either; everything 15 through 18 changed underneath you still applies, and the quiet behavior shifts in that list cost more than the loud removals. The supported path is unchanged: move to 18 now, on a major that has been in production for a year, and keep 19 as a later single-major hop made from inside a support window.

A schedule caveat belongs here too. The September date carried an explicit condition and did not survive it; the new one is a target, not a promise. RC2 exists because fixes were still arriving in volume, and the same mechanism that moved GA once can move it again. Treat November 19 as current as of this writing, October 15, and check the pgsql-hackers announcements before you commit a maintenance window to it.

Where Datapace fits

This post is a correction of pages that were accurate when published and stale within a quarter, which is the normal lifecycle of written facts about moving systems. Databases have the same problem one layer down: the schema documentation, ownership notes and version assumptions a team writes down drift from the estate they describe, and anything reasoning over them, people or AI agents, inherits the gap. Datapace is building the context layer that keeps that knowledge resolved and current: owner-validated meaning about your databases, workload evidence beside it, and a policy gate over what an agent may do and access, served over MCP. If your upgrade planning starts with finding out what is actually true about your own estate, that is the estate documentation use case.

Sources

1. Jonathan S. Katz for the PostgreSQL release team, Updated PostgreSQL RC / GA dates, pgsql-hackers, October 10, 2026 (RC1 continuing October 15; RC2 scheduled November 12; GA moved to November 19; back-branch fix volume as the reason).
2. Jonathan S. Katz, PostgreSQL 19 RC1 and GA release dates, pgsql-hackers, September 28, 2026 (RC1 October 15; GA October 29 unless significant issues; timing relative to the November update release).
3. PostgreSQL Global Development Group, PostgreSQL 19 Beta 4 Released!, September 24, 2026 (reverts of SQL/PGQ, online checksum toggling, FOR PORTION OF, MERGE and SPLIT PARTITIONS; removal of the DDL-generation functions; LC_COLLATE revert; rationale for removals).
4. PostgreSQL, Release 19 draft notes (release date placeholder "2026-??-??", AS OF 2026-09-14).
5. PostgreSQL, Versioning Policy (Postgres 14 final release 14.24 on November 12, 2026).
6. Rosemary Asufi, Devart, PostgreSQL 19 release overview, July 9, 2026 (SQL/PGQ listed as a 19 capability; GA expected September or October 2026).