PostgreSQL 19 is the next major release of the open source database, now in its fourth beta. The project pulled six planned features from that beta on September 24, 2026, including its long-anticipated SQL/PGQ graph query support. For teams planning an upgrade, the practical question is no longer which features will ship. It is when, and what still needs testing before then.
What Is New in PostgreSQL 19
PostgreSQL 19 adds a new REPACK command that replaces VACUUM FULL and CLUSTER. A CONCURRENTLY option keeps a table readable and writable for most of the operation. That removes a common source of downtime during table maintenance.
Autovacuum gets parallel worker support for index processing. A new scoring system, visible through the pg_stat_autovacuum_scores view, prioritizes which tables need attention first. Five window functions, including lag and lead, now support an IGNORE NULLS option for cleaner time-series queries.
A new WAIT command lets standby servers wait for a specific WAL position before continuing. That supports read-your-writes consistency on read replicas, a pattern teams previously had to build themselves. Logical replication also gained sequence value synchronization, which prevents duplicate key errors after a failover.
Performance and Query Planner Improvements
Foreign key constraint checks run significantly faster in PostgreSQL 19. Asynchronous I/O gets smarter read-ahead scheduling, with worker pools that scale automatically between io_min_workers and io_max_workers. COPY FROM now uses SIMD acceleration for parsing text and CSV data.
The query planner gains two new tools: pg_plan_advice and pg_stash_advice. Both let administrators stabilize planner decisions instead of fighting unpredictable plan changes. That matters most for teams running Postgres across different types of cloud computing, where autoscaling can shift statistics without warning.
The default TOAST compression algorithm switches from pglz to lz4. That trades a small amount of storage space for faster compression and decompression. JIT compilation is now disabled by default too. PostgreSQL’s release notes call this a deliberate change. JIT caused more unpredictable performance than it fixed for many workloads.
Why SQL/PGQ Graph Queries Got Reverted
SQL/PGQ would have let developers query existing relational tables as a property graph, using named edges instead of manual joins. PostgreSQL 19 beta 1 shipped with an early version of it in June 2026. Beta 4 removed it entirely.
PostgreSQL’s official beta 4 announcement explains the reasoning directly. The community “strongly believes that, first and foremost, PostgreSQL must be reliable.” The implementation still lacked core graph capabilities. Path variables and shortest-path search were among the pieces the community judged too unfinished to ship.
Five other features got pulled alongside SQL/PGQ. Those include online enabling and disabling of data checksums, temporal updates throughFOR PORTION OF, and partition merging and splitting. The project cut three DDL retrieval functions for roles, tablespaces, and databases too. Teams that read early PostgreSQL 19 previews mentioning these features should expect to wait for a future release.
Security and Breaking Changes to Plan For
PostgreSQL 19 removes RADIUS authentication entirely, calling the UDP-based protocol inherently insecure. Password expiration warnings now default to seven days before expiry. MD5 authentication still works, but it now triggers a new deprecation warning that administrators can disable.
standard_conforming_strings is now forced on, with no way to turn it off. Old dumps created with that setting disabled need to be recreated using PostgreSQL 19 tools before they will restore cleanly. Check this detail against DevX’s guide to enterprise development tools before scheduling a production upgrade.
A handful of smaller breaking changes round out the list. Carriage returns and line feeds are no longer allowed in database, role, or tablespace names. The default index type for inet and cidr columns also changes, from btree_gist to GiST. Existing indexes on those columns need to be rebuilt after upgrading.
What This Means for Teams Upgrading
PostgreSQL’s release team expects the next milestone, a release candidate, in early October 2026. General availability may follow later that same month, based on how testing goes. That timeline has already slipped once because of the graph query reverts in beta 4.
Managed database providers typically add PostgreSQL 19 support within weeks of general availability. Self-hosted teams face the real testing burden well before then. Treat this beta period as the window to test compatibility, not a reason to wait for GA.
The safest path is testing against a beta or release candidate build in a staging environment now. Focus on anything using inet or cidr indexes. Also check custom dump and restore scripts, plus RADIUS authentication if your organization still relies on it.
Common Mistakes and Tradeoffs to Watch
The most common mistake is assuming PostgreSQL 19 previews from earlier in the beta cycle still apply. Six features described in beta 1 coverage didn’t make it to beta 4. Always check the current release notes, not an article written in June or July.
The second mistake is skipping the JIT compilation change during performance testing. Because JIT now defaults to off, a query that relied on it for speed could regress after upgrading. Benchmark before and after the upgrade rather than assuming performance holds steady.
Teams with heavy inet or cidr index usage should budget real time before the upgrade window. Rebuilding those indexes is not a quick configuration flag. It requires rebuilding indexes on potentially large tables, which can affect write performance during the process.
Key Takeaways
- PostgreSQL 19 beta 4 shipped on September 24, 2026, reverting six previously announced features.
- SQL/PGQ graph query support, temporal
FOR PORTION OFupdates, and partition merging were all cut for this release. - A new
REPACKcommand and parallel autovacuum workers significantly cut maintenance downtime. - JIT compilation is now disabled by default, which can change query performance after an upgrade.
- A release candidate is expected in early October 2026, with general availability likely later that month.
Frequently Asked Questions About PostgreSQL 19
What Is New in PostgreSQL 19?
PostgreSQL 19 adds a REPACK command and parallel autovacuum. It also adds a WAIT command for replica consistency, faster foreign key checks, and planner improvements.
Did PostgreSQL 19 Ship Graph Query Support?
No. PostgreSQL reverted SQL/PGQ property graph queries in beta 4, released September 24, 2026, due to concerns about the feature’s readiness.
When Will PostgreSQL 19 Be Generally Available?
A release candidate is expected in early October 2026. General availability may follow later that month, depending on testing results.
Does PostgreSQL 19 Remove Any Authentication Methods?
Yes. PostgreSQL 19 removes RADIUS authentication entirely. MD5 authentication still works but now triggers a deprecation warning.
Will My Existing Database Dumps Work After Upgrading?
Dumps created with standard_conforming_strings disabled need to be recreated with PostgreSQL 19 tools, since that setting is now forced on.
Is JIT Compilation Still Available in PostgreSQL 19?
Yes, but PostgreSQL 19 disables it by default instead of enabling it automatically. Administrators can still enable it manually for workloads that benefit.
Final Thoughts
PostgreSQL 19 is shaping up as a maintenance and reliability release, not a headline feature release. That holds true despite the reverted graph query support. The REPACK command and parallel autovacuum alone justify early testing. Start staging environment testing now and focus on the breaking changes listed here. Watch for the release candidate in early October.
Photo by Anthony Riera: Unsplash
Priya Nandakumar covers enterprise technology and AI infrastructure for DevX, with a focus on the systems decisions that look fine until they don't. Caching layers, message queues, fault tolerance. She spent seven years as a backend engineer at two Series C startups before moving into technical journalism, and she still reads changelogs for fun.
