PostgreSQL 19 Beta 2: what to test before the final release

PostgreSQL 19 is moving closer to its final form. Released on July 16, 2026, Beta 2 fixes issues found in the first beta and gives engineering teams a more stable base for evaluating the performance, observability and compatibility changes expected in the final release.

The project is explicit: this development build must not be run in production. Its value lies elsewhere. By testing anonymised copies of real schemas, queries and data volumes now, a team can find regressions and prepare its next migration cycle without putting production data at risk.

The short answer

Beta 2 is not a signal to schedule an immediate cutover. It is the time to build a reproducible report that will support a decision after the stable release, which the project expects around September or October 2026.

What Beta 2 specifically fixes

The second beta collects fixes made since Beta 1. The project highlights corrections for temporal FOR PORTION OF operations, SQL/PGQ property graph queries, a race condition in logical decoding and a regression when analysing partitioned tables.

It also adjusts the score used by autovacuum and addresses several errors and crashes. These changes illustrate the purpose of a beta: interfaces and behaviour can still change before the final release. Any result gathered today should therefore record the exact server build and be repeated on later versions.

Testing Beta 2 still has practical value. A problematic query plan, an extension incompatibility or a behavioural change reported during this period can be investigated before PostgreSQL 19 becomes stable.

Measure performance changes on your workloads

The release notes describe several optimisations, but none guarantees a universal improvement. PostgreSQL 19 can transform some NOT IN expressions into anti joins, move aggregates before a join and improve semijoin strategies. Those choices may dramatically reduce work for some analytical queries and barely affect others.

A useful comparison starts with real plans. For every critical query, retain EXPLAIN (ANALYZE, BUFFERS, WAL, SETTINGS), execution time, reads, temporary writes and variance across several runs. A single average on a cold machine is not enough.

The engine also adds read-ahead to asynchronous I/O. The potential benefit depends on storage, dataset size and cache ratio. Local SSDs, network volumes and databases that fit almost entirely in memory will behave differently.

Text and CSV COPY gain SIMD optimisations on supported processors. Teams ingesting large files should measure throughput, CPU use and WAL pressure together. A faster import may simply move the bottleneck to storage or replicas.

Parallel autovacuum and better visibility

PostgreSQL 19 adds the ability to run multiple autovacuum operations in parallel. This targets installations where maintenance falls behind across a large set of tables. It does not remove the need to monitor dead tuples, freeze age and contention with application transactions.

The new pg_stat_autovacuum_scores view exposes the scores used to rank work. It can help explain why one table is processed before another and reveal a relation monopolising maintenance capacity. A good test must simulate normal write traffic instead of running a manual VACUUM against an idle database.

Lock waits also become more visible because the release notes say log_lock_waits is enabled by default. The pg_stat_lock view adds another diagnostic surface, while pg_stat_recovery reports on recovery. Before production adoption, teams should estimate the extra log volume and adjust collection accordingly.

LZ4 by default: compare size and CPU cost

The default TOAST compression changes to LZ4. TOAST stores and compresses values too large to fit directly in a row, including some text, JSON documents and binary content. LZ4 generally favours speed, but the outcome depends heavily on the data.

A representative test database should compare table and index size, insertion time, reads and CPU consumption. The compression setting does not magically rewrite every existing value, so the protocol needs to distinguish a fresh load, a restore and the gradual modification of existing data.

This deserves particular attention where storage is expensive or large JSON fields are frequently accessed. A synthetic table filled with a repeated string is much more compressible than typical production data and cannot support a useful conclusion by itself.

Inventory compatibility issues before migration

PostgreSQL 19 includes operationally relevant changes. The server expands warnings around MD5 authentication, removes RADIUS, makes standard_conforming_strings permanently active, disables JIT by default and raises the default max_locks_per_transaction value to 128.

Some applications may also see different handling of empty JSON arrays. Users of btree_gist indexes on inet or cidr columns need to read the migration notes carefully because certain indexes can block pg_upgrade and require rebuilding.

The inventory should cover:

• extensions and the versions available for PostgreSQL 19;
• authentication methods and pg_hba.conf rules;
• settings explicitly changed by the team;
• non-standard types and indexes;
• drivers used by every application;
• backup, replication, monitoring and connection-pooling tools.

A database that starts is not necessarily compatible. Application migrations, integration tests, scheduled jobs and operational procedures all need to run.

A six-step testing laboratory

The PostgreSQL project asks users to test typical workloads. A practical protocol can be organised in six steps:

1. create an isolated environment that cannot receive production traffic;
2. restore a recent backup after anonymising sensitive data;
3. install the same extensions and settings as the current version;
4. replay critical queries and a representative write profile;
5. compare performance, plans, locks, logs and storage size;
6. document every difference with a reproducible case and exact version.

Tests should include a controlled failure, restore, restart, replication lag and connection saturation. A successful migration is not only about nominal throughput; it must preserve the ability to diagnose problems and restore service.

Choose a migration path and test the rollback

A PostgreSQL major upgrade requires a dedicated strategy. Documented options are dump and restore, pg_upgrade, or logical replication. The right choice depends on data volume, downtime tolerance, extensions and the ability to operate two environments temporarily.

pg_upgrade often shortens the cutover, but it requires precise preparation of binaries, extensions and indexes. Logical replication can reduce visible downtime at the cost of additional architecture and careful verification of replicated objects. A full restore is easy to reason about but may take too long for large databases.

Rollback must be tested before change day. Once the application has written data to the new version, restoring the old server without data loss is not automatic. The runbook should define the point of no return, abandonment criteria and the person responsible for the decision.

What teams can prepare now

PostgreSQL 19 Beta 2 must not host production data, but it provides a useful schedule. Teams can establish their compatibility matrix, qualify extensions, create a query corpus and automate measurements that will be repeated on the release candidate and final build.

The desired outcome is not a premature migration date. It is a package containing measured gains, regressions, configuration changes, a cutover procedure and a rollback plan. When PostgreSQL 19 is stable, the decision can then rely on evidence from the organisation's own infrastructure instead of a generic list of new features.