Postgres Is Removing Features. Here's Why (Postgres 19 Update)

0:00 In the Postgres 19 beta, you could build a property graph, a way to query ordinary tables as a graph that needs a primary key on its table. Then you could drop the key. Postgres let you. The

0:11 graph stayed with nothing under it. Ship that in 19.0 and that version gets supported whole and all for 5 years. Postgres developer Robert Haas put it bluntly on the mailing list. This class

0:24 of problem, he wrote, seems completely unacceptable in a committed feature. So the feature came out. Property graphs weren't alone. The beta 4 announcement lists four more removals. Online data

0:35 checksums, four portion of, which updates just part of a time range, merge and split partitions, and new pg_get functions that print the SQL to recreate an object. That's a lot of release notes

0:46 going back in the drawer. If you run Postgres, the support policy is what makes this matter. Each major version gets 5 years of support and minor releases don't add features.

0:57 Whatever ships in 19.0 is the version you live with. There's a stranger detail, too. One feature on that list was already pulled from Postgres 17 back in 2024. Now it's out again. So why

1:09 would a project keep deleting something it obviously wants? Postgres 19 is still in beta. Beta 4 landed on September 24th, 2026. The announcement says minor behavior changes are still possible and

1:22 user testing helps decide when the final release happens. It doesn't give a release date, just a plan to move to release candidates next. Picture every feature as a beam going into a building.

1:33 People move in, put their furniture on those beams, and live there for 5 years. With an ordinary app, a bad beam is a Friday problem. You ship a fix, users refresh, and the incident channel goes

1:44 back to arguing about lunch. A database gets heavier tenants, schemas, data, and backups, all built on the behavior of that exact version. Moving to the next building is no refresh, either. A major

1:56 upgrade means dump and reload or pg_upgrade. And the fixes that reach 19 later are for bugs, security issues, and data corruption, not redesigns. Back to that

2:07 missing key, slowly this time. Create property graph checks its requirements like a primary key when you create the graph, once at the door. After that, ordinary schema changes, the DDL

2:20 commands like alter table could take those requirements away, drop the key, and the graph keeps existing on top of something that no longer holds. The inspector signed off on the beam, then

2:30 left a saw next to it. The Haus's rule is simple. If creating an object requires something, later DDL that would break it should be blocked, too. That's a design

2:39 question, how the feature protects itself from every future change. He wanted it settled before commit, not patched afterwards. Taking it out wasn't small, either. The command prompt blog

2:49 reports that the property graph revert on September 7th removed 47 commits, the feature plus every fix built on it since. The next crack reaches your data more directly. Foreign keys. Say every

3:01 order row has to point at a real customer. Postgres checks that for you, every single time. An optimization added for Postgres 19 batch those checks for speed, buffering them to run together.

3:13 Amit Langote's commit removing it spells out the risk. Miss one edge case and a buffered check never runs. Then the transaction can commit a permanent foreign key violation with no

3:23 error. That's an order pointing at a customer who doesn't exist and nothing ever told you. The commit also says there wasn't enough time to gain confidence before release. And that's

3:33 the scary part for a database. A later fix could stop the next bad row. The rows already committed would still be wrong. Checksums are third and the most ironic. Data checksums exist to catch

3:45 corruption on disk. The online version turned them on by walking the catalog, the list of tables and indexes Postgres has on record. Haas, as quoted on the build blog,

3:55 explains the catch. A crash before commit can leave orphaned files behind, and the catalog walk never touches them. So, after any crash in the cluster's history, a base backup, the full copy

4:06 you'd restore from, fails checks on verification. So, you'd have a corruption detector reporting corruption that isn't there. It's a smoke alarm that goes off for every piece of toast

4:15 you've ever burned. You'd stop trusting it by Tuesday. All three cracks showed up late. The Snowflake engineering blog describes the reverts the same way. Mostly design

4:25 flaws, wrong results, or compatibility concerns found late in the cycle. Some of that hunting happened out in the open. On August 25th, 2026, Haas started a thread on pgsql-hackers, the main

4:37 Postgres developer mailing list, called the scary patch contest. It's the one contest where you'd rather not place. He'd asked Claude to rank version 19 patches by how many bugs and what kind

4:48 were fixed in them after feature freeze, the point where new features stop going in. Then, he asked the list whether any were still in bad enough shape to revert before 19 ships. Claude's part was that

4:58 ranking, built from bugs developers had already fixed. The flaws in the story, the missing key, the skipped FK check, and the checksum false alarm come from developers' own emails and commits, and

5:09 developers did the reverting. The official reason in the beta 4 announcement is short. Postgres must be reliable first and foremost, and the community wants a predictable schedule.

5:19 Snowflake's blog puts the order the same way. Quality first, timing second. Merge and split partitions lets you combine partitions of a table or break one apart. In August 2024, it came out of

5:31 Postgres 17 over security issues with repeated name lookups, where looking up the same name twice might not find the same object. The remaining issues couldn't even be carefully analyzed

5:42 before the release candidate deadline. Two years later, it's out of 19, too. Command Prompt reports that revert landed on August 27th, 14 commits citing multiple design issues too late to

5:53 address this cycle. That's two farewell tours for one feature. At least this one never claimed it was retiring. So, why keep deleting something the project wants? Because right now, deletion is as

6:04 cheap and reversible as it'll ever be. Even 47 commits can be pulled out before anyone moves in. The code stays in history and it can come back once the design holds. Whether any of these land

6:15 in 20 is still open. The official wording only says potentially. Before anyone moves in, you can pull a cracked beam and wait for a better one. After move in, minor releases can still patch

6:26 bugs. But, closing a design gap like DDL breaking a graph means changing behavior people already rely on and doing it around their furniture while they still live there. If you run Postgres in

6:37 production, these reverts are the release process doing its job. If you are planning around anything on that list, property graphs, partition merging, online checksums, fear a

6:47 portion of or the new PG_Get functions, plan 19 without it. PostgreSQL 19 beta is still open for testing and that testing helps decide when it ships. So, which beta features are you testing

6:59 against your own workload and what's still on the open items list where the project tracks what has to be settled before the release candidate.