With PostgreSQL 19 on the horizon, query planning could get smarter thanks to new query tools and faster maintenance. The release is still a few months away, but Beta 1 already shows where PostgreSQL is headed.
Released on June 4, 2026, PostgreSQL 19 Beta 1 previews most of what’s planned for the final release. The PostgreSQL Global Development Group notes that some details can still change during the beta period, so nothing here is final until general availability, expected in the second half of 2026. Anyone tracking the PostgreSQL 19 release date now has a much clearer timeline to plan around.
This article covers the biggest changes, including PostgreSQL 19 pg_plan_advice, native REPACK, parallel autovacuum, sharper monitoring, new SQL features, and what to validate before PostgreSQL 19 reaches general availability.
- What’s new in PostgreSQL 19?
- Query plan advice and query hints in PostgreSQL 19
- Native REPACK and online maintenance improvements
- Autovacuum and performance improvements
- Monitoring and observability improvements
- Developer features in PostgreSQL 19
- PostgreSQL 19 vs PostgreSQL 18: What changed?
- How dbForge Studio can help you
- Bottom line
- Frequently asked questions
What’s new in PostgreSQL 19?
The PostgreSQL 19 new features that matter most to DBAs and developers cluster around six areas: query optimization, maintenance, autovacuum, monitoring, logical replication, and SQL surface. They’re summarized below before we go deeper on each one.
| Area | PostgreSQL 19 improvement |
|---|---|
| Query optimization | Query plan advice / planner guidance |
| Maintenance | Native REPACK and REPACK CONCURRENTLY |
| Autovacuum | Parallel autovacuum and better visibility |
| Monitoring | New statistics views and better query analysis |
| Logical replication | Sequence replication and easier configuration |
| SQL features | SQL/PGQ, GROUP BY ALL, JSONPath updates |
| Security | SNI support and authentication-related changes |
Every one of the PostgreSQL 19 features above is confirmed in Beta 1, though the PostgreSQL Project cautions that minor behavior can still shift through the release candidates that follow.
Query plan advice and query hints in PostgreSQL 19
PostgreSQL 19 query hints don’t look like Oracle’s. PostgreSQL has historically refused native optimizer hints, on the grounds that a hint hard-codes today’s data distribution into tomorrow’s query plan. The new PostgreSQL 19 pg_plan_advice extension changes that calculus by giving the planner a controlled, revisable way to accept guidance instead of a permanent override.
What is pg_plan_advice?
pg_plan_advice generates and applies planner advice when the optimizer picks a bad execution plan. It’s the kind that looks fine against yesterday’s statistics and falls apart against today’s skewed data or a complex join.
In practice, DBAs use it for a single query that’s performing poorly, not across the whole database. They apply a better execution plan as a temporary fix while addressing the underlying cause, such as stale statistics, a missing index, or an inefficient table design.
What is pg_stash_advice?
pg_stash_advice stores plan advice and applies it automatically based on query identifiers, so a stabilized query stays stabilized without a human re-running the fix after every deployment. Advice is keyed by stash name and query ID and injected at planning time, which means application SQL never has to change—the correction lives outside the query text entirely.
When query plan advice is useful
Query plan advice earns its place in three situations: stopping a specific regression from recurring, stabilizing a report the business depends on, and testing an alternative execution plan.
It is not a substitute for proper indexing, current statistics, or query tuning. Treat it as a targeted patch for a known problem, not a default applied across a workload. Used that way, it closes a gap that existed in PostgreSQL long before PostgreSQL 19 roadmap discussions began.
Native REPACK and online maintenance improvements
PostgreSQL 19 REPACK delivers the maintenance operation DBAs have needed for years. REPACK and REPACK CONCURRENTLY replace what used to require the pg_repack extension or a dedicated maintenance window, making this one of the most consequential DBA-facing changes in the release.
Why REPACK matters
Bloated tables and indexes quietly erode performance long before anyone notices: index scans slow down, sequential scans read more pages than the live data warrants, and disk usage climbs without a corresponding growth in actual rows.
The traditional fixes, VACUUM FULL and CLUSTER, both work, but both take heavy locks that make them impractical on a table anyone is actively querying. Native REPACK closes that gap by rebuilding a table with less locking overhead, and REPACK CONCURRENTLY pushes that further into genuinely online territory.
REPACK vs VACUUM FULL vs CLUSTER
The following table lines up REPACK against the maintenance operations DBAs already know, so it’s clear where each one fits.
| Operation | Main purpose | Blocking behavior | Best use case |
|---|---|---|---|
| VACUUM | Reclaims space internally and updates visibility | Usually non-blocking | Routine cleanup |
| VACUUM FULL | Rewrites a table and returns disk space | Blocking | Deep cleanup during a maintenance window |
| CLUSTER | Reorders a table based on an index | Blocking | Physical table reordering |
| REPACK | Rebuilds a table with less overhead | Less disruptive | Scheduled rebuilds with a short window |
| REPACK CONCURRENTLY | Online rebuild with lower locking impact | Nonblocking | Production maintenance with minimal downtime |
What DBAs should test
Before relying on REPACK in production, test it against the workloads where it matters most: large tables, high-write tables, and heavily indexed tables. Watch four things specifically: total runtime, WAL generation during the rebuild, replication lag on any downstream replicas, and disk usage while the old and new copies of the table briefly coexist.
A table that rebuilds cleanly in a quiet staging environment can behave very differently under a live write load.
Autovacuum and performance improvements
Autovacuum has been single-threaded for its entire history, which becomes a real constraint once a database has more large or high-churn tables than one worker can keep up with. PostgreSQL 19 addresses that directly, alongside giving DBAs far better visibility into what autovacuum is actually doing at any given moment.
Parallel autovacuum
Parallel autovacuum lets PostgreSQL 19 use multiple workers against large tables and indexes, configured through the new autovacuum_max_parallel_workers setting. For databases where autovacuum has historically fallen behind (large fact tables, heavily updated queues, anything with a high dead-tuple churn rate) this is the difference between vacuum keeping pace with write load and vacuum permanently chasing it.
Better vacuum visibility
A new autovacuum scoring system helps PostgreSQL 19 prioritize which tables to vacuum first, and expanded progress reporting gives DBAs a clearer picture of what autovacuum is doing right now rather than a guess based on table size and the last-vacuum timestamp. Troubleshooting a stalled or lagging autovacuum run gets meaningfully easier.
Monitoring and observability improvements
PostgreSQL 19 adds several statistics views that answer questions DBAs have historically had to piece together from logs, extensions, or trial and error: particularly around locks, replica recovery state, and I/O-heavy queries.
Better lock and recovery monitoring
New and improved statistics views give PostgreSQL 19 first-class visibility into lock contention and standby recovery status, both of which used to require correlating multiple system views or reading logs line by line during an incident. Diagnosing why a query is blocked or how far behind a standby it actually is becomes a direct query rather than a guessing exercise.
EXPLAIN ANALYZE I/O
Improved query analysis through EXPLAIN surfaces I/O activity per plan node, making it far easier to spot the specific step in a query (a sequential scan, a sort spilling to disk, a bloated index) that is driving excessive reads. For I/O-bound workloads, this closes a long-standing blind spot in PostgreSQL’s built-in capabilities.
Developer features in PostgreSQL 19
Alongside the operational changes, PostgreSQL 19 features expand what developers can express directly in SQL, several of them closing the gaps that previously pushed teams toward a second database or an application-side workaround. The following table covers the additions that developers are most likely to use.
| Developer feature | What changed in PostgreSQL 19 | Why it matters |
|---|---|---|
| SQL/PGQ Graph Queries | Newly added support for SQL Property Graph Queries over relational data | Analysis of relationships, paths, and hierarchies (fraud patterns, dependencies, recommendations) without a separate graph database |
| GROUP BY ALL | Auto-grouping by every non-aggregate, non-window output column | Shorter, less error-prone aggregation queries, especially in reporting and analytics |
| JSONPath Improvements | Addition of lower(), upper(), initcap(), replace(), split_part(), and trimming functions | More flexible filtering and transforming of JSON payloads, configs, and API responses stored in PostgreSQL |
| DDL Extraction Functions | New SQL functions retrieve the DDL needed to recreate databases, roles, and tablespaces | Simplified migrations, documentation, auditing, and environment comparison |
| ON CONFLICT DO SELECT … RETURNING | Upsert workflows can return the conflicting row during conflict handling | Cleaner handling of duplicates in application logic, imports, and deduplication |
| IGNORE NULLS / RESPECT NULLS | Addition of NULL-handling options for lead, lag, first_value, last_value, and nth_value | More expressive analytical SQL over sparse data: time series, activity logs, incomplete records |
None of these require moving data out of PostgreSQL or standing up a second system—they extend what a single PostgreSQL 19 database can already do on its own.
PostgreSQL 19 vs PostgreSQL 18: What changed?
The operational shift is bigger than any single headline feature. PostgreSQL 19 logical replication now includes sequence support and can be enabled without a server restart, closing a long-standing gap in zero-downtime upgrade workflows. The following table lines up both releases across the areas covered in this article.
| Area | PostgreSQL 18 | PostgreSQL 19 |
|---|---|---|
| Async I/O | Introduced async I/O foundation | Improves I/O worker scaling |
| Query planning | No native plan advice framework | Adds pg_plan_advice and pg_stash_advice |
| Maintenance | VACUUM, VACUUM FULL, CLUSTER, extensions | Adds native REPACK and REPACK CONCURRENTLY |
| Autovacuum | Single-threaded autovacuum behavior | Adds parallel autovacuum support |
| Observability | Existing pg_stat views | Adds pg_stat_lock, pg_stat_recovery, better progress detail |
| Logical replication | Table-focused replication improvements | Adds sequence replication and easier logical replication |
| SQL features | PostgreSQL 18 SQL improvements | Adds SQL/PGQ, GROUP BY ALL, new JSONPath functions |
Reading the full PostgreSQL 19 release notes before planning an upgrade is still worth the time: this table only covers the highlights, not every behavioral change that can affect an existing application.
How dbForge Studio can help you
Testing a major PostgreSQL upgrade is about making sure nothing breaks. That means comparing schemas and data, checking query performance, and confirming that your applications behave as expected before moving a production database to a new version.
dbForge Studio for PostgreSQL is an AI-powered IDE for database development, management, and reporting across PostgreSQL, Supabase, AWS, and a wide range of cloud services. Its integrated tools help teams analyze query performance, compare database schemas and data, synchronize database changes, generate reports, and streamline everyday administration from a single environment.
These capabilities make it easier to validate upgrade readiness, identify differences between environments, and prepare for a smooth migration once PostgreSQL 19 reaches its official release.
Bottom line
PostgreSQL 19 is shaping up to be a practical release rather than a flashy one. Features like pg_plan_advice, native REPACK, parallel autovacuum, and improved monitoring solve everyday problems DBAs and developers have been working around for years.
With Beta 1 now available, it’s worth taking the time to test these changes in your own environment. Running a few upgrade tests and checking how your workloads behave now can save a lot of surprises when PostgreSQL 19 reaches general availability.
Frequently asked questions
When will PostgreSQL 19 GA be released?
PostgreSQL 19 Beta 1 was released on June 4, 2026, with general availability expected around September or October 2026, following additional betas and one or more release candidates.
Is PostgreSQL 19 production-ready?
Not yet. Beta releases are for testing only: behaviors, catalog definitions, and APIs can still change before general availability, and there is no guaranteed upgrade path between betas.
What are the main new features in PostgreSQL 19?
The main new features include pg_plan_advice for query plan control, native REPACK for online table maintenance, parallel autovacuum, expanded monitoring views, sequence support in logical replication, and new SQL capabilities including SQL/PGQ and GROUP BY ALL.
Does PostgreSQL 19 support query hints?
Not in the traditional Oracle-style sense. pg_plan_advice and pg_stash_advice give PostgreSQL 19 a controlled way to influence planner decisions without permanently hard-coding a hint into the query itself.
What is REPACK in PostgreSQL 19?
REPACK and REPACK CONCURRENTLY rebuild a bloated table with less locking overhead than VACUUM FULL or CLUSTER, bringing an operation that previously needed the pg_repack extension directly into PostgreSQL 19 core.
