PostgreSQL 19 is not going to ship in September. The project’s open items wiki now lists Beta 4 for September 24, 2026 with no date at all for RC 1 or GA — a break from the fall cadence of recent years. PostgreSQL 18 hit RC 1 on September 4, 2025 and went GA three weeks later. For 19, the Release Management Team’s stated goal is GA “by the end of October,” and Robert Haas, announcing the extra beta on pgsql-hackers, attributed the delay to “the influx of issues that have been reported that have taken additional time to handle.”

If your team penciled in an October upgrade window, revisit it this week.

The PostgreSQL 19 schedule, as it stands today

Feature freeze    April 8, 2026
Beta 1            June 4, 2026
Beta 2            July 16, 2026
Beta 3            August 13, 2026
Beta 4            September 24, 2026
RC 1              TBD
GA                TBD ("by the end of October")

PostgreSQL 18 had no fourth beta at all. With RC 1 still undated after September 24, a realistic GA lands in the last week of October — after PGConf.EU season, not before it.

Features that were reverted after the beta list was published

Every “what’s new in 19” post written since June — ours included — is now partly wrong. Since August 25, the project has backed out:

• SQL/PGQ property graphs. The headline feature of Beta 1 was reverted on September 7. Haas documented the cause: CREATE PROPERTY GRAPH checked its prerequisites once at creation time and then allowed them to be dropped, so dropping a primary key or column could silently break a graph. The revert removed roughly 124 files.
• ALTER TABLE ... MERGE / SPLIT PARTITION, reverted August 26–27 for “multiple design issues which are too late to address in this release cycle.”
• Foreign-key fast-path batching, removed from the 19 branch on September 10 after the “scary patch contest” thread Haas opened on pgsql-hackers flagged five distinct classes of incorrect FK enforcement. The per-row fast path remains.
• GROUP BY ALL and non-plain pg_dumpall output formats, withdrawn before Beta 3 and Beta 2 respectively.
• The CREATE SCHEMA subcommands, reverted by Tom Lane in the second week of September because they changed the meaning of statements version 18 already accepts.
• Provider-specific identifier casefolding and the LC_COLLATE postmaster change, reverted one at a time by Jeff Davis.

The pattern is a schedule that rewards landing features in the final five weeks before the April 8 freeze cliff: REPACK, pg_plan_advice, SQL/PGQ, COPY TO ... FORMAT JSON, FOR PORTION OF and online data checksums all landed in that window. Committed that late, they have no room to be fixed properly before GA, so they get reverted instead. The open items list, not the release notes, is what tells you what actually ships.

Still in the tree, and still being argued about

• REPACK (CONCURRENTLY) is the big operational win if it survives: native online table rebuilds without the pg_repack extension or a VACUUM FULL lock. As currently scoped it is limited to one REPACK process per cluster, rejects non-heap access methods, user catalog tables and materialized views, and refuses REPACK ANALYZE inside a transaction block as a stopgap. Its MVCC-safety patch set is already queued for the next cycle.
• Online data checksums (pg_enable_data_checksums() / pg_disable_data_checksums()) — the transition runs asynchronously and reports intermediate states, so read SHOW data_checksums carefully during migration.
• UPDATE/DELETE ... FOR PORTION OF and pg_get_*_ddl(): both partially cut back, both with open items against them.

Practical rule: test them on Beta 4 in staging, but do not write your Q4 migration plan around any of them.

Meanwhile, patch pgAdmin this week

The one item on this list that is not a wait-and-see: pgAdmin 4 v9.18 shipped September 17 with 29 fixes, four of them security issues graded CVE-2026-86861 through CVE-2026-86864. Two matter for anyone running pgAdmin in server mode:

• CVE-2026-86863 — authentication bypass in Webserver mode. The identity from WEBSERVER_REMOTE_USER could be asserted purely from an inbound request header whenever the WSGI environment lacked it, so any client that could reach pgAdmin could claim to be an administrator without a credential. Header-asserted identity is now opt-in, restricted to configured trusted proxies.
• CVE-2026-86864 — backup tool argument and connection-string injection. A client-supplied database name was appended to the pg_dump argument vector as a bare positional value, so a name beginning with a dash could override options such as --file, and a name containing an equals sign expanded into a full libpq connection string — redirecting the connection, and the password in PGPASSWORD, to a host of the caller’s choosing. The same class of bug hit Restore and Maintenance (CVE-2026-86862). Database names now travel through PGDATABASE, which libpq never expands.

v9.18 also fixes a symlink time-of-check/time-of-use flaw in the File Manager write path and stops following HTTP redirects on LLM API requests. Supported servers are 14 through 18, bundled client utilities 18.4 — if your workstation is still on an older line, treat this as a same-week patch.

Ecosystem notes

pgAssistant 3.8.0 (September 16) repositioned itself from a tuning analyzer to a “continuous improvement loop”: with its Collector component it now stores historical workload and environment measurements, then compares consecutive collections to show which recommendations disappeared, which versions and settings changed, and how call volume and execution time moved. It is explicitly not a monitoring replacement — it is what you run after an incident to prove what actually changed.

Correction to our recent roundup: our previous news post treated SQL/PGQ as a shipping 19 feature. It is not. Neither is REPACK’s logical-decoding companion work in the form it was described.

What Houston DBAs should do with the extra weeks

1. Move the assumption, not just the date. Plan for GA in the last week of October and an RC in the first half of that month. Anything you promised a business owner for “post-19-GA in October” becomes November.
2. Book the freeze now. Q4 is when energy trading, healthcare and logistics stacks are least tolerant of a surprise major-version cutover. A late-October GA lands directly against that. If you need 19 for a specific capability, escalate the dependency; if you do not, upgrade on your own calendar in Q1.
3. Test Beta 4 (Sept 24), don’t design around it. Run your workload against it, capture plan changes, and check the extensions you actually run.
4. Cut over with logical replication, not a hard stop. Our zero-downtime cutover walkthrough covers the sequence for exactly this situation, and it is the safest path when the target release is newer than your production tooling.
5. Watch the open items wiki, not the headlines. It is the only source that tells you whether REPACK or online checksums actually ship.

19 will be a better release for the reverts, and smaller than Beta 1 promised. The willingness to delete six weeks of work six weeks before a release is why a Postgres upgrade is a routine Tuesday for most Houston shops. Just do not schedule that Tuesday until the RC exists.

Sources

• PostgreSQL 19 Open Items (project wiki)
• Beta 4 release date, pgsql-hackers
• 19th Nervous Breakdown (schedule, revert log)
• pgAdmin 4 v9.18 release notes
• pgAssistant 3.8.0