By PostgreSQL 19 Beta 3 dropped on August 13 alongside critical security patches for every supported version and a formal end-of-life notice for PostgreSQL 14 (deadline: November 12, 2026). One announcement, three action items — which is not something most database release notes can claim. Here is what matters and what you should actually do about it.
SQL/PGQ: Postgres Learned Graph Querying
The headline feature of PostgreSQL 19 is SQL/PGQ (ISO/IEC 9075-16:2023), which brings native graph query capabilities to your existing relational tables. No new database. No migration. No extension to install. You define a property graph over tables you already have, then query relationships using a GRAPH_TABLE clause with MATCH pattern syntax.
The practical version looks like this. If you have a users table and a friendships table, you can write a friend-of-friend query without a self-join chain:
CREATE PROPERTY GRAPH social_network
VERTEX TABLES (users)
EDGE TABLES (friendships
SOURCE KEY (user_id) REFERENCES users
DESTINATION KEY (friend_id) REFERENCES users);
SELECT person_name
FROM GRAPH_TABLE(social_network
MATCH (a IS users WHERE a.id = 42)
-[IS friendships]->(b IS users)
-[IS friendships]->(c IS users)
COLUMNS (c.name AS person_name));That is a two-hop traversal in standard SQL. For teams currently running Neo4j for recommendation engines, dependency graphs, or social network lookups at known relationship depths — this deserves a serious look. PostgreSQL core contributor Peter Eisentraut called it “a paradigm shift, like document database/JSON was for Postgres.”
There is one important limitation to be clear about: SQL/PGQ in PostgreSQL 19 supports only fixed-depth pattern matching. Queries that find all paths of any length between two nodes are not yet possible. Variable-length path traversal is planned for a future release. For the majority of real-world graph query patterns — which operate at known hop counts — this covers the ground. But if your use case requires arbitrary-depth traversal, Neo4j or a dedicated graph database still wins. See the official property graph documentation for the full syntax reference.
REPACK CONCURRENTLY: The End of the pg_repack Extension
For years, the standard answer to “how do I reclaim bloated table space without downtime” was “install pg_repack.” PostgreSQL 19 makes that recommendation largely obsolete.
The new REPACK command combines the functionality of VACUUM FULL and CLUSTER into a single command. What matters is the CONCURRENTLY mode. Where VACUUM FULL holds an ACCESS EXCLUSIVE lock for its entire duration — blocking all reads and writes, sometimes for hours on large tables — REPACK CONCURRENTLY does the heavy lifting in the background. It creates a replication slot to capture changes during the copy operation, then swaps files with only a brief final lock. Crunchy Data put it plainly: “We used to say ‘use pg_repack.’ Now we can say ‘use REPACK CONCURRENTLY.'”
VACUUM FULL and CLUSTER now use the same repack infrastructure internally, so all paths to table compaction benefit from the new implementation.
The Quiet Wins That Show Up in Production
Two other changes in PostgreSQL 19 are less dramatic but will likely have more day-to-day impact for most deployments.
LZ4 becomes the default TOAST compression. PostgreSQL has supported LZ4 compression since version 14, but pglz remained the default. PostgreSQL 19 finally flips the switch. LZ4 compresses roughly 8x faster than pglz and delivers 80% faster INSERT performance on toasted data (text blobs, jsonb, binary). The compression ratio is slightly lower (2.07 vs 2.23), but for almost every production workload, speed wins that trade. Existing rows stored with pglz stay pglz until updated — no forced rewrites, no configuration change needed on new clusters.
Parallel autovacuum for index-heavy tables. Autovacuum can now recruit parallel workers to handle index vacuuming concurrently. The new autovacuum_max_parallel_workers parameter controls the ceiling. This is not a universal win — it is I/O-bound and benefits most from fast storage. But if you are managing tables with four or more indexes, especially GIN indexes on jsonb columns (historically the autovacuum bottleneck), this change can meaningfully reduce the time those tables spend being vacuumed.
Security Patches and the PG 14 Countdown
The August 13 release included security updates for all supported versions: 18.6, 17.11, 16.15, 15.19, and 14.24. These patches address 30 vulnerabilities including heap buffer overflows and remote code execution risks. If you have not applied the latest maintenance release for your version, that should be the first thing you do. Check the official release announcement for the full vulnerability list.
The more consequential news for many teams: PostgreSQL 14 reaches end of life on November 12, 2026 — 84 days from today. After that date, PG 14 receives no security patches and no bug fixes. PG 14 remains extremely common in managed cloud environments where major version upgrades get deferred indefinitely. That deferral strategy stops working in November. PostgreSQL 17 is the recommended upgrade target, with support extending to 2029. See Neon’s PostgreSQL 19 feature overview for a full breakdown of the new version capabilities as you plan your migration path.
How to Test Beta 3 Today
If you want to experiment with SQL/PGQ or REPACK CONCURRENTLY today, Beta 3 is available via the official PostgreSQL download page. The fastest path is Docker:
docker run --name pg19beta -e POSTGRES_PASSWORD=secret -p 5432:5432 postgres:19beta3The PostgreSQL project expects to release one or more release candidates before the stable release, currently targeted for September or October 2026. The Beta 3 release means the feature set is effectively locked — what ships in stable will look like this.
