PostgreSQL 19: What’s New and How to Test the Beta

Build an isolated PostgreSQL 19 beta on macOS

tar -xf postgresql-19beta2.tar.bz2
cd postgresql-19beta2

./configure --prefix="$HOME/pg19"
make -j"$(sysctl -n hw.ncpu)"
make install

"$HOME/pg19/bin/initdb" -D "$HOME/pg19-data"
"$HOME/pg19/bin/pg_ctl" \
  -D "$HOME/pg19-data" \
  -l "$HOME/pg19-data/server.log" \
  -o "-p 5419" start

Install Apple's command-line developer tools and any required build dependencies first. Use a throwaway data directory and stop the server with the matching pg_ctl binary.

Treat the beta label as a contract

The PostgreSQL project says beta releases are not for production or active development data. Catalog formats, behavior, and features can change before release. A beta cluster should be easy to delete and rebuild.

PostgreSQL 19 is currently planned for September 2026. Keep the version number out of long-lived infrastructure defaults until the release candidates settle and your extensions publish compatible builds.

SQL changes developers will notice

The draft adds SQL property graph queries, GROUP BY ALL, IGNORE NULLS and RESPECT NULLS for several window functions, FOR PORTION OF for temporal updates and deletes, and a form of INSERT ON CONFLICT that can return the conflicting row.

These are good candidates for small compatibility tests because they are visible at the query layer. Keep test SQL next to its expected output so later beta releases can be rerun without guesswork.

Try two PostgreSQL 19 query features

select department, status, count(*)
from tickets
group by all;

select
  happened_at,
  last_value(value) ignore nulls over (
    order by happened_at
    rows between unbounded preceding and current row
  ) as latest_value
from readings;

The exact feature set is still pre-release. Verify syntax against the documentation for the beta build you install.

Operations and performance changes deserve rehearsal

PostgreSQL 19 expands asynchronous I/O controls, adds parallel autovacuum workers, makes LZ4 the default TOAST compression method, enables log_lock_waits by default, and adds views for lock, recovery, and autovacuum statistics. JIT is disabled by default because its previous cost trigger was not reliable for every workload.

None of those changes guarantees a faster application. Capture a PostgreSQL 18 baseline, restore the same data into 19, and compare the same query set, maintenance jobs, and bulk loads.

Check compatibility before performance

The draft notes include changes to authentication warnings, RADIUS removal, standard-conforming strings, index operator classes for inet and cidr, lock sizing, extension APIs, and utility behavior. An extension that compiles on 18 is not automatically ready for 19.

Inventory extensions, procedural languages, custom data types, foreign data wrappers, authentication methods, and backup tooling. Run pg_upgrade --check against a copy when the surrounding tools support the beta.

Use a repeatable beta test

Restore a fresh database, run migrations, execute application tests, compare important EXPLAIN plans, validate backups, and review logs. Repeat that process for each beta or release candidate rather than carrying a beta data directory forward indefinitely.

Use a separate saved-query folder in your database client for version checks and plan comparisons. The EXPLAIN ANALYZE guide covers the plan fields worth comparing.