Looking Ahead to Postgres 19

Every Postgres release has a personality.

Some releases are about one big headline feature. Some are about removing a long-standing pain point. Some are full of those "oh, nice" improvements that you don't fully appreciate until you upgrade and suddenly your day-to-day workflow is just a little bit smoother. Oh, and of course almost every release has some performance improvements sprinkled in.

Postgres 19 feels like one of those releases that has a bit of everything. REPACK CONCURRENTLY is a big quality-of-life upgrade for larger production databases and it's built in. There are some big-ticket features, yes. SQL property graph queries are going to get a lot of attention. Logical replication keeps getting more complete. And then there are the steady improvements across VACUUM, EXPLAIN, COPY, partitioning, monitoring, performance and planner behavior that continue to make Postgres better not in a flashy way, but in the very practical "this helps me run production systems" way.

As always with a beta, details can change before GA. But with Postgres 19 now in beta, it's a good time to start looking at what is coming and, more importantly, what it means for people building and operating on Postgres.

REPACK out of the box

If you have operated Postgres for long enough, you have probably had a moment where you wanted to reclaim table bloat, rewrite a table or reorganize data — but you very much did not want to take the lock that came with VACUUM FULL or CLUSTER.

There has long been an extension ecosystem around this problem, most notably pg_repack. That alone tells you something: Users had a real need, and the ecosystem filled the gap.

Postgres 19 brings a new REPACK command into core, including support for REPACK CONCURRENTLY.

I expect REPACK CONCURRENTLY to be one of those features that production Postgres users care about more than the average release-note reader might expect.

Partitioning gets more practical

Partitioning in Postgres has improved a lot over the years. It went from "you can do this, but you probably need to understand a lot of internals and sharp edges" to something much more approachable.

Postgres 19 continues that work with support for merging and splitting partitions.

This sounds straightforward, but it solves a real operational problem. Partitioning strategy is one of those things you often choose with imperfect information. You start with a partitioning scheme that makes sense at the time. Then your workload changes. Your retention window changes. Your data volume grows faster than expected. Or maybe a few partitions become awkwardly large while others are tiny.

Being able to split and merge partitions gives you more room to evolve your design over time.

-- Combine Q1 and Q2 into a single partition 
ALTER TABLE customer_orders MERGE PARTITIONS (orders_2026_q1, orders_2026_q2) INTO orders_2026_h1;

-- Split the Q3 partition into monthly intervals ALTER TABLE customer_orders SPLIT PARTITION orders_2026_q3 INTO ( PARTITION orders_2026_07 FOR VALUES FROM ('2026-07-01') TO ('2026-08-01'), PARTITION orders_2026_08 FOR VALUES FROM ('2026-08-01') TO ('2026-09-01'), PARTITION orders_2026_09 FOR VALUES FROM ('2026-09-01') TO ('2026-10-01') );

Features like this matter because the best database designs are rarely static. Good systems evolve. Postgres giving you more ways to adjust without rebuilding everything from scratch is exactly the kind of incremental improvement that makes it easier to run Postgres for the long haul.

Logical replication continues to mature

Logical replication has been one of the most important areas of Postgres development over the last several releases. It is useful for migrations, upgrades, reporting systems, data movement, selective replication, and increasingly for high-availability and operational workflows.

Postgres 19 continues to round out logical replication in a few important ways.

The big one: Sequence values can now be synchronized so subscribers better match publishers. Anyone who has worked with logical replication for application tables that depend on sequences knows why this matters. Data replication without sequence state can leave you with awkward post-cutover problems. The data moved, but the next generated ID may not be where you need it to be.

Postgres 19 also adds ALL SEQUENCES support for publications, sequence sync error reporting and better subscription refresh behavior around sequences.

Another nice improvement: Publications can use an EXCEPT clause to exclude some tables when publishing all tables. This fits how people actually operate systems. You often want "basically everything, except these few things." Making that easier is a good thing.

And then there is the ability for wal_level = replica to automatically enable logical replication when needed, along with a new effective_wal_level to report what is actually happening. This is another practical improvement: fewer configuration footguns and better visibility when Postgres is doing something on your behalf.

Logical replication still has nuance. It always will. But every release makes it feel less like a specialized feature and more like part of the normal Postgres operational toolkit.

Autovacuum gets smarter and easier to see

Vacuum is one of the most Postgres things there is.

You can use Postgres for years and never care about the internals. Then one day your table bloat grows, wraparound warnings appear or query performance changes, and suddenly you care a lot.

Postgres 19 has several improvements here that are worth calling out.

Autovacuum can now use parallel vacuum workers, controlled globally and per table. For larger tables and indexes, that gives Postgres more ability to keep up with maintenance work.

-- Allow up to 4 parallel workers globally for autovacuum processes 
ALTER SYSTEM SET autovacuum_max_parallel_workers = 4;

There is also a new scoring system to control the order tables are autovacuumed. This is important because autovacuum is always making tradeoffs. Which table is most urgent? Which one should go next? Making that prioritization smarter helps in the exact place where Postgres users need help: keeping the system healthy before it becomes an incident.

-- Adjust the priority scoring just for this table:
-- Give insert-based vacuuming a massive urgency boost (3.0),
-- while dropping the normal update/delete vacuum urgency (0.5) since rows are rarely deleted.
ALTER TABLE application_logs SET (
    autovacuum_vacuum_insert_score_weight = 3.0,
    autovacuum_vacuum_score_weight = 0.5
);

The new pg_stat_autovacuum_scores view gives more visibility into that decision-making. Add in more details in vacuum and analyze progress views, memory usage and parallelism in VACUUM VERBOSE and autovacuum logs, and a separate log_autoanalyze_min_duration, and Postgres 19 feels like a release that is trying to make maintenance more observable.

That is a theme I'm always happy to see. The database doing work in the background is good. The database explaining that work better is even better.

SQL property graph queries come to Postgres

Now for one of the more interesting additions: SQL/PGQ, or SQL property graph queries.

Graph databases have had their moments over the years. And to be clear, there are absolutely workloads where thinking in terms of vertices and edges is a useful model: fraud detection, recommendations, network analysis, permission graphs, supply chains, org charts and plenty more.

-- sample property graph
CREATE PROPERTY GRAPH store_graph
VERTEX TABLES (
    customers LABEL customer,
    orders LABEL "order"
)
EDGE TABLES (
    customer_orders 
        SOURCE customers 
        DESTINATION orders 
        LABEL placed_order
);

But the thing I like about this landing in Postgres is that it is not asking you to throw away the relational model. It is Postgres adding another way to query the data you already have.

That is very Postgres.

Postgres has always had a way of absorbing useful capabilities without forcing an entirely new architecture on you. JSONB did not mean you had to stop using relational tables. Full text search did not mean you needed a separate search database for every use case. Extensions did not mean forking the database. And now SQL/PGQ gives Postgres a graph-shaped way of looking at relational data.

The most interesting part to me is less "Postgres is now a graph database" and more "Postgres continues to make the database you already picked more capable."

That is a subtle but important distinction.

For developers, this means there may be a lot of cases where graph-style queries become available without adding another datastore, another sync path, another operational surface area, and another thing to debug at 2:00 a.m. And as someone who has spent a lot of time around managed databases and production incidents, fewer moving pieces is generally a win.

COPY keeps getting more useful

COPY is one of those Postgres features that is both boring and wonderful. It moves data in and out quickly. It is dependable. And because loading and exporting data is such a common workflow, even small improvements can matter a lot.

Postgres 19 has several nice COPY improvements.

COPY FROM can skip multiple header lines. That sounds minor until you get handed yet another CSV from a vendor, internal tool or "export" process with extra metadata lines at the top.

COPY FROM also gets ON_ERROR SET_NULL, allowing invalid input values to be set to null. This gives you another option between "fail the whole load" and "pre-clean everything elsewhere."

-- Imagine a file where a price column occasionally contains 'N/A' or 'MISSING' instead of a numeric value
COPY product_catalog (product_id, title, price_usd)
FROM '/path/to/dirty_products.csv' 
WITH (
    FORMAT CSV, 
    HEADER, 
    ON_ERROR SET_NULL
);

COPY TO can output JSON format, including as a single JSON array. And COPY TO can now output partitioned tables directly, where previously you needed to use COPY (SELECT ...).

-- Export an entire table directly into a cleanly formatted, valid JSON array 
COPY customers TO '/path/to/customers_export.json' WITH (FORMAT JSON, ARRAY true);

None of these change the world. All of them make day-to-day data workflows better.

SQL quality-of-life improvements

Postgres 19 also brings a handful of SQL improvements that developers will appreciate.

GROUP BY ALL lets you automatically group by all nonaggregate and nonwindow target-list expressions. This is the kind of syntax that can make exploratory SQL and reporting queries cleaner. (Thanks to our own David Christensen for this one.)

-- Using GROUP BY ALL
SELECT 
    category,
    manufacturer,
    COUNT(*) as total_items,
    AVG(price) as avg_price
FROM inventory_products
GROUP BY ALL; 

Window functions get IGNORE NULLS and RESPECT NULLS support for functions like lead, lag, first_value, last_value and nth_value. If you have ever written awkward workarounds to get the previous non-null value in a series, this one should catch your eye.

INSERT ... ON CONFLICT DO SELECT ... RETURNING is another nice addition. Upserts are everywhere in application code, and being able to return conflicting rows more directly gives developers more flexibility.

INSERT INTO tags (tag_name) 
VALUES ('postgres')
ON CONFLICT (tag_name) DO SELECT
RETURNING tag_id;

Postgres also adds UPDATE and DELETE FOR PORTION OF, continuing work around temporal use cases. Time is one of the most common dimensions in real applications, and better temporal syntax in core SQL is a welcome direction.

Expanded RANDOM() temporal functions. (Thanks to our own Paul Ramsey and Greg Sabino Mullane for work on this one.)

Performance improvements across the board

The planner and executor continue to get steady work in Postgres 19. Special thanks to Snowflake's Tom Lane for his efforts in Postgres 19 in performance and many other areas.

There are improvements around anti-joins, semi-joins, constant folding, incremental sort with append paths, aggregate processing before joins, join selectivity computation, function statistics and more.

The easy thing to do here is list planner changes and call it done. But the more useful takeaway is this: Postgres keeps getting better at recognizing the shape of common queries and doing less unnecessary work.

Some aggregate processing can now happen before joins, which can reduce the number of rows processed. More NOT IN and LEFT JOIN cases can become efficient anti-joins. Memoize has more visibility in EXPLAIN. Sort performance improves with radix sort. Foreign key constraint checks get faster. COPY FROM text and CSV input can use SIMD instructions.

These are not always features you change application code to use. In many cases, you upgrade and Postgres simply has a better chance of doing the right thing.

That is one of the best kinds of database improvements.

Why Postgres 19 feels important

The thing that stands out to me about Postgres 19 is not one single feature. It is the breadth.

There is something for application developers: graph queries, better SQL syntax, window function improvements, better upsert behavior.

There is something for operators: REPACK CONCURRENTLY, better autovacuum, better monitoring, online checksum changes, more replication visibility.

There is something for performance-minded folks: planner improvements, SIMD improvements, asynchronous I/O visibility, faster foreign key checks, better sorts.

There is something for people building on top of Postgres: new hooks, planner advice modules, extension improvements, FDW stats retrieval and continued investment in the extension ecosystem.

That breadth is one of the reasons Postgres keeps winning. It is not just getting better for one workload or one persona. It is getting better as an application database, an operational database, an analytical database, an extensible database and a platform.

Postgres 19 is not GA yet, so now is the time to test. Try your application. Run your migration tests. Check your extensions. Look at plans for your most important queries. Exercise logical replication if you depend on it. Run your maintenance workflows. See what breaks while there is still time to fix it.

Postgres releases get better because people test them against real workloads.

And based on what is already in Postgres 19 beta, there is a lot here worth testing.