PostgreSQL 19 arrives this fall. Six changes that matter for a small app, and the one that decides when you get them

Correction and update, August 22, 2026. This post said Postgres 19 “reached its second beta on July 16.” That was already out of date when we published it on August 19. Beta 3 shipped on August 13, and we missed it. More importantly, we missed what shipped with it. The same August 13 announcement covered PostgreSQL 18.6, 17.11, 16.15, 15.19 and 14.24, a maintenance release across every supported branch that closes 28 security vulnerabilities and over 110 bugs. That is an unusually large security batch for this project, and it applies to the version you are running in production right now rather than to a beta nobody should be running yet. If you self-host Postgres, updating to the current patch release of your branch is the item from this week, and it outranks everything else in this post. If you are on a managed platform, check whether your provider has applied it and when. The announcement also confirms that PostgreSQL 14 stops receiving fixes on November 12, 2026, so a 14.x instance needs a major-version upgrade plan now rather than next year. The rest of this post, which is about what changes in 19, is unaffected and still stands.

Source: PostgreSQL 18.6, 17.11, 16.15, 15.19, 14.24 and 19 Beta 3 Released, August 13, 2026.

Follow-up, August 23, 2026. We have now written that security release up properly: what the 28 CVEs actually are, and the two fixes that change how your database behaves. Three things from it belong here. Twenty-eight is the largest security batch in the project’s history, more than double the previous record of 11 set in May. Eighteen of the 28 need nothing more than an ordinary database login, so the usual “it is behind a firewall” reasoning does not cover them. And two of the fixes are not silent: logical replication using a non-core output plugin stops working until you add it to a new output_plugin_libraries allowlist, and pgcrypto will refuse to decrypt data encrypted with certain deprecated ciphers because that data was never properly encrypted in the first place. Also note that the fixed version for the 18 branch is 18.6, not the 18.5 the CVE pages list: 18.5 was pulled before release after a regression was found.

PostgreSQL 19 reached its second beta on July 16 and its third on August 13, and the project says the final release is expected around September or October 2026. We wrote in why Postgres is still our default database that the engine matters less than the ecosystem around it. That is still true, and it is exactly why most major Postgres releases are, for a small business application, quietly uneventful. You upgrade eventually, the app behaves the same, and life goes on.

This one has a few items that are worth knowing before you upgrade rather than after. Two of them change defaults, which means they change behaviour on machines where nobody touched a setting. Everything below comes from the project’s own beta announcements and the version 19 release notes. It is beta software: details can still change before general availability, and nobody should be running it in production yet.

1. REPACK, and reclaiming disk space without taking the app down

This is the headline for anyone who has ever watched a Postgres database get fat.

Postgres does not overwrite rows in place. Updates and deletes leave dead tuples behind, autovacuum marks that space reusable, but the file on disk does not shrink. Over years, on a table that gets heavy churn, the gap between “data” and “space this table occupies” becomes real money on a managed plan. The classic fix, VACUUM FULL, rewrites the table compactly but takes an access-exclusive lock, which means the table is unavailable for the duration. On a small app that is a maintenance window. On a table people are using, it is an outage.

Postgres 19 adds a REPACK command that replaces both VACUUM FULL and CLUSTER, and crucially it has a CONCURRENTLY option that rebuilds the table without the access-exclusive lock. Reads and writes keep working while it runs.

If you have been keeping the pg_repack extension around for exactly this, the functionality is moving into core. For a small team, “one less extension whose version has to line up with the server” is a genuine simplification.

2. Autovacuum goes parallel and gets smarter about what to do first

Two related changes. Autovacuum can now use parallel workers, controlled by autovacuum_max_parallel_workers and a per-table autovacuum_parallel_workers storage parameter. And there is a new scoring system for prioritizing which tables to vacuum next.

The scoring is the part that helps small apps most, and it is invisible when it works. The old failure mode is that autovacuum spends its budget on whatever it reached first while the one table that actually needed attention keeps bloating. If you have ever had a busy sessions or events table degrade while everything else looked fine, that is the shape of the problem.

3. JIT is off by default now, and that is a bug fix disguised as a regression

Postgres has had just-in-time compilation enabled by default since version 12, activated when the planner’s cost estimate crossed a threshold. In 19 it is disabled by default. The release notes are unusually blunt about why: the costing that decided when to use it “has been determined to be unreliable.”

For most small applications this is good news you will never notice, or a small speedup on queries where JIT was being switched on for no benefit and charging you the compilation time. If you run large analytical queries where JIT genuinely helps, you now have to turn it on yourself. That is the one case where an upgrade could make something slower, and it is worth checking before you blame the upgrade for something else.

4. The other default that changed: TOAST compression

Large values (long text, JSON documents) get compressed and stored out of line by a mechanism called TOAST. The default compression algorithm moves from pglz to lz4, which is faster. Existing data is not rewritten, so you get this on new data, and old and new can coexist in the same table.

If your application stores anything substantial in text or jsonb columns, which is most applications, this is free and it is in your favour.

5. Logical replication that makes major upgrades less painful

Two changes that matter more than they sound. First, sequence values on a subscriber can now be synced to match the publisher, at CREATE SUBSCRIPTION time and via explicit refresh commands. Anyone who has done a logical-replication cutover knows the specific pain this addresses: everything replicates cleanly except the sequences, and if you forget to fix them by hand, the new primary starts handing out primary keys that already exist.

Second, logical replication can be enabled without a server restart, and can be enabled when wal_level is set to replica, with a new read-only effective_wal_level parameter showing what is actually in force. Previously, deciding you wanted logical replication later meant a restart, which on a small production database means scheduling a downtime window to prepare for the migration you were trying to do without downtime.

Together these make the standard low-downtime major-version upgrade path materially less fiddly.

6. Small developer conveniences that remove real code

• INSERT ... ON CONFLICT DO SELECT ... RETURNING returns the conflicting row on an upsert, which removes the awkward second query you write today when you need the existing record.
• GROUP BY ALL groups by every non-aggregate output column, which kills a class of tedious repetition in reporting queries.
• WAIT FOR LSN lets a query wait until a replica has caught up to a specific point, which is the clean answer to read-your-own-writes bugs when you split reads onto a replica and a user does not see the thing they just saved.
• ALTER TABLE ... MERGE PARTITIONS and SPLIT PARTITION, plus FOR PORTION OF on UPDATE and DELETE for temporal tables.
• New pg_plan_advice and pg_stash_advice extensions for stabilizing planner decisions, which is aimed at the “this query was fast for two years and then one day it was not” problem.
• Data checksums can be enabled and disabled online, without a cluster restart.

There is also a real security cleanup: RADIUS authentication has been removed outright, because Postgres only ever supported it over UDP, which the project describes as unfixably insecure. MD5 authentication now warns clients after a successful login, which is the deprecation signal before removal. Neither affects a typical application using password or certificate authentication through a managed provider, but if you inherited an older self-hosted setup, check both before you upgrade rather than during.

The part that actually decides your timeline

None of the above is your date. Your date is whenever the platform you run on offers it, and that gap is larger than most people expect.

Postgres 18 was released on September 25, 2025. Amazon RDS announced support for it on November 14, 2025, roughly seven weeks later, which is about as fast as managed platforms move. Supabase is the other end of the range: as of the end of August 2026, eleven months after Postgres 18 shipped, its managed platform still had not offered it, its changelog carries no Postgres 18 entry, and the most recent maintainer response in the public discussion thread put it at “eventually in 2026.”

That is not a complaint about Supabase, which we use and recommend. It is a fact about what “we’re on Postgres” means when someone else runs it. It also has a practical consequence worth stating plainly:

• Self-hosted or on a fast-moving managed provider: Postgres 19 is a real decision for late 2026 or early 2027. Our own rule is to skip the .0 unless a specific feature justifies the risk, and upgrade at 19.1 or 19.2 once the first round of bugs has been found by people with more appetite than us.
• On Supabase, or on any platform still catching up: Postgres 19 is a 2027 conversation at the earliest, and there is nothing useful you can do about it except know that. If a feature above is load-bearing for your product, that constraint belongs in your architecture discussion now, not as a surprise later.

Either way, the checklist before you upgrade is short: confirm nothing depends on JIT being on, confirm you are not using RADIUS or MD5 authentication, and test on a copy first. The rest of this release is the kind of change that quietly makes an ordinary database easier to live with, which is the best thing a database release can be.

If you are running a Postgres database that has been growing quietly for a few years and nobody is sure whether it needs attention, send us a note. Most of the time the honest answer is that it is fine, and it is worth knowing which time this is.