PostgreSQL 19 Beta 4: Pulled Features and New Defaults

PostgreSQL 19 will not ship with SQL/PGQ graph queries. On September 24, 2026, Beta 4 reverted six planned features so the project could keep an October release target. If you read the Beta 1 coverage and put graph queries or online checksum changes on a roadmap, take them off.

This is a follow-up to our earlier look at REPACK and parallel autovacuum in Beta 1. What is new here is the cut list, two default changes, and a short test plan. Sources are the official Beta 4 announcement and PlanetScale’s feature summary.

What was pulled

PostgreSQL 19 beta 4 reverted several features: SQL/PGQ property graph queries, online data checksum changes, FOR PORTION OF temporal updates and deletes, and MERGE and SPLIT PARTITIONS. Plan around version 19 without them. The project says features that needed more review time can return in a later major version.

The announcement lists these as reverted:

• SQL/PGQ (property graph queries)
• Online enabling and disabling of data checksums
• Temporal updates and deletes through FOR PORTION OF
• ALTER TABLE ... MERGE PARTITIONS and ALTER TABLE ... SPLIT PARTITIONS
• The pg_get_role_ddl(), pg_get_tablespace_ddl() and pg_get_database_ddl() functions
• A change that forced LC_COLLATE to C in the postmaster process

The project’s stated reason is that Postgres has to be reliable and keep a predictable release schedule, so features that needed more review time can return in a later major version. That is the right call. It also means anything built around those features, from a graph-query proof of concept to a partition-merge runbook, has no 19 target to aim at.

Defaults that change without a query change

JIT is off by default. It had been on since PostgreSQL 12. PlanetScale’s summary says compilation overhead now outweighs the benefit for typical OLTP queries that sit near the cost threshold, which made timings unpredictable. You can still enable it. If you run long analytical queries on the same cluster, test with jit = on for those sessions or roles only:

ALTER ROLE analytics_reader SET jit = on;

A query that crosses the JIT cost threshold today will, after upgrading, simply not compile. That usually means more stable latency and sometimes slower big scans. Compare EXPLAIN (ANALYZE) output from before and after on your slowest ten queries.

TOAST compression defaults to lz4. The default compression for large values moves from pglz to lz4, which trades a little storage for faster compression and decompression. Existing data keeps whatever it was compressed with. New values use lz4. You can see which a column’s values use with pg_column_compression():

SELECT pg_column_compression(payload) AS method, count(*)
FROM events
GROUP BY 1;

Expect a mixed result for a while after upgrading, and don’t be alarmed by it.

Authentication cleanup

PlanetScale reports RADIUS authentication is removed and MD5 password authentication now emits deprecation warnings. Before you test an upgrade, grep your pg_hba.conf for radius and md5. A host entry that uses RADIUS will stop working, and MD5 entries should move to scram-sha-256 now rather than under deadline pressure. Existing MD5 password hashes need to be re-set as SCRAM to make that switch.

Query planner changes to benchmark

Two planner changes are likely to move your numbers, per PlanetScale. Eager aggregation can pre-aggregate before a join when that cuts the row count by a large factor (the post cites 8x or more). And NOT IN can now run as an anti-join in cases where nulls can be ruled out, which helps large-table queries that used to fall back to slow plans.

Both are planner behavior, so the only honest test is your own query set. Capture your top queries from pg_stat_statements before the upgrade and replay them after. If you want a refresher on reading plans, our query optimization guide for application developers walks through it.

REPACK: read the caveat before you use it

REPACK folds VACUUM FULL and CLUSTER into one command, and REPACK (CONCURRENTLY) rewrites a bloated table while reads and writes continue. It takes an ACCESS EXCLUSIVE lock only for the final file swap. Requirements: wal_level at replica or higher, a primary key or replica identity index, and enough disk for a second copy of the table.

The caveat is the one that matters. It is not MVCC-safe for older snapshots. Per the PlanetScale summary, once the swap commits the table looks empty to any transaction on a snapshot from before it. A long-running report or a REPEATABLE READ job that spans the swap can see nothing. Lock upgrades can also deadlock when other transactions hold conflicting locks. Schedule it away from long transactions, and don’t run it where you can’t tolerate a retry. For the wider approach to schema work under load, see zero-downtime database migrations.

A beta test plan that fits in a day

1. Restore a recent production backup into a staging instance on Beta 4. Don’t test on an empty database.
2. Replay your top queries from pg_stat_statements and diff plans and timings.
3. Check pg_hba.conf for radius and md5.
4. Run your migrations, extensions and ORMs against it. Extension compatibility is where upgrades usually stall.
5. Try REPACK (CONCURRENTLY) on a bloated non-critical table, with a long snapshot open in another session, to see the caveat yourself.

Then wait. First-minor releases of a new major are where many teams move production, and a release that already cut six features late is a reason to be patient. If you are still on 17 or earlier, our PostgreSQL 18 upgrade guide is the safer stepping stone.

The takeaway: test Beta 4 for the JIT and compression defaults, cross SQL/PGQ off your roadmap, and treat REPACK as a tool with a sharp edge.