PostgreSQL 19 Beta 4 landed on September 24, 2026 — right on the date the project’s own schedule named. The headline is not a feature that arrived. It is four that left.

Per the release announcement, this beta reverted SQL/PGQ property graph query support, online enabling and disabling of data checksums, temporal updates and deletes via FOR PORTION OF, and ALTER TABLE ... MERGE PARTITIONS / SPLIT PARTITIONS. The same announcement puts the release candidate in early October, with general availability also possible that month.

If your team has an October upgrade window penciled in, the date did not move. Your scope did.

What Beta 4 took back

The full revert list from the announcement:

• SQL/PGQ (property graph query) support — reverted. One of the marquee items of the cycle.
• Online enabling and disabling of data checksums — reverted. Toggling checksums previously required a full offline rewrite.
• Temporal updates and deletes via FOR PORTION OF — reverted, though the new temporal tables documentation section remains.
• ALTER TABLE ... MERGE PARTITIONS and SPLIT PARTITIONS — reverted. Partition maintenance still means attaching, detaching, and rebuilding.
• pg_get_role_ddl(), pg_get_tablespace_ddl(), pg_get_database_ddl() — removed.
• Forcing LC_COLLATE to C in the postmaster — reverted.

Beta 4 also carried fixes rather than removals: corrections to the foreign key check performance work, fixes for the new REPACK command (crashes, incorrect behavior with invalid indexes and materialized views, permission and error-reporting issues), and fixes for the new WAIT FOR command including a deadlock.

If you sketched a project around property graphs or online checksum toggling after our earlier coverage of the PostgreSQL 19 schedule, those line items come out today — not at RC.

Why a project reverts its own features

The announcement is direct about why:

The PostgreSQL community strongly believes that, first and foremost, PostgreSQL must be reliable. Additionally, the community strives for a predictable release schedule.

The reverted features were removed “so they can be potentially be included in a later major release after more time working through the community development and review process.”

This is the beta process working as designed. Two of the four reverted items are large architectural surfaces: SQL/PGQ added a new query syntax over graph patterns, and online checksum toggling reaches into the storage layer of a live cluster. Pulling them four weeks before GA is not a failure — shipping them and finding the defect in production is.

For operators, the lesson is how you consume betas: the build you benchmarked in August is not the one you deploy in October. Re-run your suite against Beta 4.

What PostgreSQL 19 still delivers

The release notes remain the source of truth, and plenty is still landing:

• REPACK — a new command that reclaims space and reorganizes table contents, absorbing VACUUM FULL and CLUSTER, with a CONCURRENTLY option for non-blocking rewrites.
• WAIT — lets a standby wait for an LSN to be written, flushed, or replayed.
• pg_plan_advice and pg_stash_advice — extensions for stabilizing and pinning planner decisions.
• New observability — the pg_stat_autovacuum_scores view, a started_by column on pg_stat_progress_analyze, and a backup_type column on pg_stat_progress_basebackup.
• log_lock_waits is on by default — cheap, and overdue for the average cluster.
• Compatibility changes to plan for: MD5 authentication now issues warnings (md5_password_warnings), RADIUS support is removed as “unfixably insecure,” standard_conforming_strings is forced on, the default opclasses for inet and cidr move to GiST, and object names may no longer contain carriage returns or line feeds.

Two of those are hard upgrade blockers, not warnings. pg_upgrade refuses to upgrade a cluster using btree_gist inet/cidr indexes (they can exclude rows that should be returned) or with CR/LF in object names. Find them now.

Pre-flight checks to run today

All four are read-only and quick — the last needs superuser because pg_authid requires it:

-- 1. GiST indexes over inet/cidr columns: pg_upgrade will block on these.
SELECT n.nspname AS schema,
       c.relname AS index_name,
       pg_get_indexdef(i.indexrelid) AS definition
FROM pg_index i
JOIN pg_class c     ON c.oid = i.indexrelid
JOIN pg_namespace n ON n.oid = c.relnamespace
JOIN pg_am am       ON am.oid = c.relam
WHERE am.amname = 'gist'
  AND pg_get_indexdef(i.indexrelid) ~* '\y(inet|cidr)\y';

-- 2. Object names containing CR or LF: also blocks pg_upgrade.
SELECT datname AS bad_name FROM pg_database   WHERE datname ~ E'[\r\n]'
UNION ALL
SELECT rolname          FROM pg_roles      WHERE rolname ~ E'[\r\n]'
UNION ALL
SELECT spcname          FROM pg_tablespace WHERE spcname ~ E'[\r\n]';

-- 3. Roles still on MD5, which will start warning in PostgreSQL 19 (superuser).
SELECT rolname FROM pg_authid
WHERE rolpassword LIKE 'md5%';

-- 4. Confirm the server setting whose behavior changes in 19.
SHOW standard_conforming_strings;

Anything the first two queries return is a migration project, not a checkbox: a GiST inet index must be rebuilt, and a CR/LF name must be renamed — easy to under-scope when connection strings carry it.

PgBouncer 1.26.0 closes three CVEs

The news does not stop at the core server. Released September 23, 2026, PgBouncer 1.26.0 fixes three CVEs:

• CVE-2026-19888 — denial of service from a crash, triggerable by unauthenticated clients, caused by a SCRAM client-final-message without a nonce.
• CVE-2026-6668 — denial of service from an infinite loop, triggerable by unauthenticated clients, caused by an integer overflow in packet buffer growth logic.
• CVE-2026-6669 — denial of service from unbounded work during login, triggerable by a malicious PostgreSQL server, caused by an unbounded SCRAM iteration count.

Two of the three need no credentials at all, and the third is triggered from the server side — so teams pooling connections in front of a managed or third-party PostgreSQL server carry exposure they did not choose. If PgBouncer sits anywhere in your stack, patch this week.

It also changes behavior worth testing: it tracks search_path and default_transaction_read_only by default, adds pool_idle_timeout, allows query_wait_timeout per user and database, and removes the deprecated online restart (-R), which will break runbooks that reload without dropping connections.

# Confirm what you are running before and after the patch.
pgbouncer --version

# Debian/Ubuntu
sudo apt-get update && sudo apt-get install --only-upgrade pgbouncer

# Restart — not -R: online restart was removed in 1.26.0
sudo systemctl restart pgbouncer

What to do this week

1. Re-scope PostgreSQL 19. Remove SQL/PGQ, online checksum toggling, FOR PORTION OF, and MERGE/SPLIT PARTITIONS from planning documents; assume they return in a future major release.
2. Run the four pre-flight queries. GiST inet/cidr indexes and CR/LF object names block pg_upgrade outright.
3. Patch PgBouncer to 1.26.0. Test the new default tracking of search_path and default_transaction_read_only, and retire any -R restart workflow.
4. Plan for RC 1 in early October. Re-run your regression suite against it, not against Beta 3 — the revert list is why.

The wider pattern recurs every cycle: PostgreSQL’s release discipline is the product. Not-ready features are removed, the schedule is protected, and that is why upgrades stay predictable — which is what Houston teams running transaction-heavy workloads are actually buying. A shorter feature list in October is a fair trade for a release that does not surprise you in November.

Sources: PostgreSQL 19 Beta 4 Released · PostgreSQL 19 release notes · PgBouncer 1.26.0 released — fixes three CVEs · PgBouncer changelog