PostgreSQL 19 was gonna be big. Graph queries. Online partition stuff. A 2x speed boost on foreign key inserts.
Then they pulled almost all of it. Not because things broke. Because they found problems before shipping. And that's the whole story here.
The Numbers Are Kind of Crazy
Postgres 18 pulled 44 features during beta. Everyone thought that was wild.
Postgres 19 is at 53 reverts. And it's still going.
One week in September? Six reverts. Seven days. 74 commits gone.
There's no RC date yet. Postgres 18 had its RC on September 4 last year and shipped three weeks later. Postgres 19? Nothing on the calendar.
So yeah, it's late. Weeks. Maybe months.
What Got Cut
These weren't small things either.
SQL/PGQ Property Graphs: gone. September 7. 47 commits removed.
ALTER TABLE MERGE/SPLIT PARTITION: gone. August 27. The bugs were scary. Dropped constraints. Broken generated columns. Replication doing weird stuff.
UPDATE/DELETE FOR PORTION OF: gone. September 15. Had security issues too.
Online data checksums: gone. September 16. 30 commits.
The 2x foreign key speedup: mostly gone. September 10.
That's a lot of work down the drain. Except it's not. More on that later.
The Bug That Killed the 2x Speedup
This one's interesting.
Postgres checks foreign keys by running a real query. Slow but correct.
Version 19 tried a shortcut. Just probe the index directly. Way faster.
Problem? Wrong collation. On tables with non-default collations, it could reject valid inserts.
Not crash. Not slow. Just wrong. Silently.
Amit Kapila found it. The batching part got pulled. The per-row path stayed.
Nobody's saying "2x" anymore.
"The RI fast path uses the wrong collation for the index probe." Amit Kapila
Learn MongoDB vs PostgreSQL
vs PostgreSQLoDB vs PostgreSQL
The "Scary Patch Contest"
Robert Haas did something unusual on August 25.
He asked Claude (the AI) to rank PG19 features by how many bugs got fixed after freeze.
Then he posted the top six and asked: should we pull these?
Here's the list:
Feature | Fixes |
|---|---|
FK batching | ~16 |
REPACK CONCURRENTLY | 28 |
Online checksums | ~25 |
FOR PORTION OF | 17 |
SQL/PGQ | 17 |
postgres_fdw stats | 7 |
People got fired up. Tom Lane and Andres Freund wanted SQL/PGQ gone. Daniel Gustafsson said he could revert checksums in 90 minutes.
Melanie Plageman said: "Bad alternatives aren't the bar for core."
By September 16, four of six were gone.
AI Is Changing How This Works
You can't skip this part.
Haas used AI to find the scary patches. Someone else started using AI to find bugs and suggest fixes.
Is AI helping? Probably. It's catching stuff people missed.
But it's also creating more work. More bugs found means more decisions to make.
One example: Postgres 18's August 2026 patch had 28 CVEs. Used to be a couple per release.
No official AI policy yet. One's coming.
"In an age of ship-ship-ship and AI rush, the human rigor of the Postgres core team is admirable." Elizabeth Garrett Christensen.
What I Learned Switching From SQL to MongoDB
What's Actually Coming
Postgres 19 isn't empty. Good stuff survived.
REPACK in core, no more pg_repack extension. REPACK CONCURRENTLY rewrites tables online. Scope got cut but it's there.
New SQL stuff:
INSERT ... ON CONFLICT DO SELECT ... RETURNINGIGNORE NULLSfor window functionsGROUP BY ALLerror_on_null()
Planner wins:
Eager aggregation
Faster anti-joins
pg_plan_advice
Parallel autovacuum
New views:
pg_stat_lock
pg_stat_recovery
pg_stat_autovacuum_scores
pg_dsm_registry_allocations
Stuff that might break your upgrade:
JIT off by default
lz4 becomes default TOAST compression
inet/cidr GiST needs reindex
max_locks_per_transaction doubled
Why This Is Actually Good
Most projects would ship anyway. Just push it out and fix it later.
Postgres didn't.
They deleted 15,859 lines of code six weeks before release. Years of work. Gone. Because it wasn't ready.
Lauren McGuire said it perfectly:
"Ask honestly whether your organization could do that. Can a staff engineer, in week eleven of a twelve-week cycle, revert the feature that was in the launch email, and have that be a normal Tuesday? If the answer is no, you do not have a release process. You have a schedule with tests attached."
That's the whole thing right there.
What You Should Do
On Postgres 14? Upgrade before November 12, 2026. That's end of life. Go to 18.
Planning for 19? Wait. Go to 18 now. Move to 19 after the first minor releases.
Lost features you wanted? They're coming in Postgres 20. Property graphs. Partition merging. Most of it.
Watch the wiki, not the press releases. The open items wiki tells you what's actually happening.
The Bottom Line
Postgres 19 is late. It's smaller than planned. And it's gonna be solid because of it.
The team pulled four of their six scariest features in three weeks. They chose correct over on time.
That's not failure. That's how it should work.
