PostgreSQL 19 Beta 2 was released on July 16, 2026, and it is the point where the version 19 feature set stops moving and starts asking to be tested. Three changes will reach almost every installation. REPACK replaces VACUUM FULL and CLUSTER under a single name, and it can rebuild a table without an access exclusive lock. JIT is now disabled by default, because its costing proved unreliable. Default TOAST compression moves from pglz to lz4. There is also native SQL Property Graph Query support, which is the feature few people saw coming in Postgres. The incompatibility list is longer than usual, so read it before you plan the upgrade.
The short answer
PostgreSQL 19 Beta 2 was released on July 16, 2026. The version 19 cycle brings REPACK, which unifies VACUUM FULL and CLUSTER and can rebuild tables without access exclusive locking, native SQL Property Graph Query support, JIT disabled by default after its costing proved unreliable, and a default TOAST compression change from pglz to lz4. Beta 2 itself is mostly fixes, including several for the new SQL/PGQ and FOR PORTION OF features. Final release is expected around September or October 2026. The incompatibility list is unusually long, so plan the upgrade rather than assume it.
Most beta announcements are a formality. This one is worth reading, because the interesting part of PostgreSQL 19 is not a feature you opt into, it is two defaults that change underneath you and a maintenance command that finally has a sensible name.
REPACK, and the end of a naming accident
For years Postgres shipped two commands that did roughly the same job with names that told you nothing about the difference. The release notes are refreshingly blunt about the fix: the two former commands did similar things, but with confusing names, so the project unified them as REPACK. VACUUM FULL and CLUSTER are retained for compatibility, so existing scripts and cron jobs keep working.
The part that matters operationally is not the rename. REPACK can rebuild tables without access exclusive locking, using a CONCURRENTLY option. Anyone who has ever scheduled a VACUUM FULL knows why that line is the most valuable sentence in the release notes. Reclaiming space from a bloated table has historically meant taking it offline, which on a large table means negotiating a window with people who would rather you did not. Doing the same work without an access exclusive lock changes that conversation.
Two defaults that will find you
JIT is now disabled by default. The reasoning given is that JIT was previously enabled by default and activated based on optimizer costs, but this costing has been determined to be unreliable. That is a notable admission, and it matches what a lot of operators found in practice, which is that JIT compilation sometimes triggered on queries where it cost more than it saved. The consequence is stated plainly in the notes: sites doing many large analytical queries must now manually enable JIT.
So this cuts both ways. If your workload is transactional, you likely benefit from the new default without doing anything. If you run heavy analytical queries and JIT was genuinely helping, you need to turn it back on explicitly, and you should confirm with measurements rather than habit.
The second default is quieter. The default TOAST compression method changes from pglz to the more efficient lz4, implemented by changing the default for the default_toast_compression variable. Because it is a default rather than a migration, your existing data is not rewritten and stays readable. New compressed values get lz4.
Property graphs arrive in Postgres
The headline feature is support for SQL Property Graph Queries, the SQL/PGQ standard, contributed by Peter Eisentraut and Ashutosh Bapat. It is worth being precise about what this is, because graph support in a relational database invites inflated expectations. The release notes note that internally these are processed like views, so they are written as standard relational queries. This is graph semantics expressed over your existing relational data, not a new storage engine competing with a dedicated graph database. For a lot of teams that is the useful version, since the alternative was moving data into a second system to ask one kind of question.
Beta 2 includes several fixes for the new SQL/PGQ property graph feature, which is precisely what a beta is supposed to produce.
What Beta 2 itself fixed
Beta 2 is a fix release on top of Beta 1, and the list reads like a healthy beta. There is a fix for a regression in vacuumdb with analyze-in-stages for partitioned tables, a fix for REPACK workers not being cleaned up on a FATAL exit, several fixes for the new FOR PORTION OF temporal syntax that adds temporal range operations to UPDATE and DELETE, a fix for a race condition when logical decoding activation is concurrently interrupted, and a fix for autovacuum's multixact age score calculation, which could become infinite. Non text output formats for pg_dumpall were reverted.
The incompatibilities are the real homework
This is where to slow down. PostgreSQL 19 carries a longer than usual list of hard breaks, and several are enforced by pg_upgrade refusing to proceed, which is better than discovering them later.
Dumps created with pre version 19 pg_dump or pg_dumpall using standard_conforming_strings set to off will not properly load into version 19 and later servers. Carriage returns and line feeds are disallowed in database, role and tablespace names, and pg_upgrade will refuse to upgrade clusters using such names. The default index opclasses for inet and cidr change from btree_gist to GiST, and pg_upgrade will refuse clusters that have btree_gist inet or cidr indexes. Beyond upgrade blockers, the default for max_locks_per_transaction doubles from 64 to 128, and because lock size allocation changed, existing settings must be doubled to match the capacity they had before. CREATE SCHEMA no longer reorders non schema objects, using your specified ordering except for foreign keys which are created last. System columns can no longer be used in COPY FROM with a WHERE clause.
What to do with this now
The project's own guidance is the right frame. Beta versions are not advised for production, but you are encouraged to find ways to run your typical application workloads against this beta. Upgrading to Beta 2 from an earlier version needs a strategy similar to a normal major version upgrade, meaning pg_upgrade or a dump and restore cycle.
The practical move is to take your least glamorous staging database, point your real query patterns at 19 Beta 2, and check three things specifically: whether disabling JIT by default changed your analytical query times, whether your inet or cidr indexes and any exotic object names will block pg_upgrade, and whether your max_locks_per_transaction setting still means what you think it means. Finding that out in July is free. Finding it out in October is not.
Sources and further reading
Frequently asked questions
When does PostgreSQL 19 actually ship?
Beta 2 arrived on July 16, 2026. The project states it will release additional betas as required for testing, followed by one or more release candidates, until the final release around September or October 2026. That gives you roughly two to three months to test your own workloads against it, which is exactly what the beta period is for. Nothing here is meant for production yet.
What is REPACK and does it replace VACUUM FULL?
REPACK is a new command that replaces both VACUUM FULL and CLUSTER. The release notes explain the reasoning plainly: the two former commands did similar things but with confusing names, so the project unified them as REPACK. The old commands are retained for compatibility, so nothing breaks on upgrade. The genuinely useful part is that REPACK can rebuild tables without access exclusive locking through its CONCURRENTLY option, which is the difference between a maintenance window and a normal Tuesday.
Why is JIT disabled by default now, and should I turn it back on?
The release notes are direct about it. JIT was previously enabled by default and activated based on optimizer costs, but that costing has been determined to be unreliable. In practice this meant queries that got JIT compiled when it did not pay off, adding latency rather than removing it. The change requires sites doing many large analytical queries to manually enable JIT. If you run a data warehouse style workload and you measured a real benefit from JIT, turn it back on deliberately and keep measuring. If you run ordinary transactional queries, the new default is likely what you wanted all along.
What does the TOAST compression change mean for existing data?
PostgreSQL 19 changes the default TOAST compression method from pglz to the more efficient lz4, by changing the default for the default_toast_compression server variable. It is a default, so it governs newly compressed values rather than rewriting what you already stored. Existing pglz compressed data stays readable. Worth noting that lz4 must be available in your build, so if you compile Postgres yourself or rely on a minimal package, confirm that before assuming the new default applies.
Which incompatibilities should I check before upgrading?
Several, and this is the part to read carefully rather than skim. Dumps created by pre version 19 pg_dump or pg_dumpall using standard_conforming_strings set to off will not properly load into version 19 and later servers. Carriage returns and line feeds are now disallowed in database, role and tablespace names, and pg_upgrade will refuse clusters that use them. The default index opclasses for inet and cidr move from btree_gist to GiST, and pg_upgrade will refuse clusters with btree_gist inet or cidr indexes. The default for max_locks_per_transaction doubles from 64 to 128, and because lock size allocation changed, settings must now be doubled to match their previous capacity.