Repack Took a Decade To Graduate Into Postgres Core. The Features Still Waiting Could Take Longer.

The Postgres 19 release notes read less like a feature announcement and more like a graduation ceremony. Capabilities that lived for years as third-party extensions are set to ship in the core engine when PG19 goes GA later this year. The headline is online table reorganization, a feature the community has waited on for over a decade. But the real story is the pattern PG19 confirms: Postgres is systematically absorbing the operational tooling its ecosystem had to build because the core wouldn't.

What that absorption cycle actually changes for operators, and where it still falls short, depends on who you ask.

Pavlo Golub is a PostgreSQL expert at Cybertec and the maintainer of pgwatch, one of the more widely used Postgres monitoring tools. He organizes community developer events at PGConf EU and contributes to the pg_timetable project.

Boris Pinsky is the CTO of Experda, an Israeli consultancy specializing in database performance and operations. He spent six years as a SQL Server DBA before moving to Postgres full-time, giving him a cross-platform lens on what Postgres still makes harder than it should be.

Repack finally graduates

The online table reorganization command in PG19 solves one of Postgres' longest-standing operational headaches. VACUUM FULL locks the entire table. For production workloads, that's a non-starter, and the community has relied on third-party tools like pg_repack and pg_squeeze to work around it for years.

"This is like winning a championship," Golub told The Read Replica. The patch that brings repack into core was co-authored by Antonin Huska, who built pg_squeeze as the third-party workaround, and Alvaro Herrera. "Your name is always going to be near the repack. 'Done by that guy.' This is forever."

From the consulting side, Pinsky considers repack the most likely reason organizations will prioritize upgrading to PG19. But he advises patience. "Every new major version, I usually wait for a few minor updates before running it in production," he said. "The first version is never the most stable."

Beyond repack: partitioning, planning, and graph queries

PG19's smaller improvements won't drive upgrade decisions on their own, but they add up for teams willing to tune.

Pinsky flagged split and merge partition support, which lets teams restructure partitioned tables without rebuilding them, and pg_plan_advice, a new capability that suggests plan alternatives.

Golub is watching something further out. "We already have most of the features you'd want to see. Now we're going very deep inside specific areas where we want to improve something tenfold." The area that has his attention is graph queries. The SQL/PGQ standard, which brings graph query capabilities into the relational model, is now landing in Postgres and will receive sustained attention across the next several major releases.

The cycle of absorption

Repack's graduation follows a pattern that's defined Postgres development for years. The ecosystem builds the tooling operators need. Core eventually absorbs the foundational layer. The ecosystem tools either retire or reposition on top of the new baseline. "Everything we have in core is always complemented with other tools," said Golub. "Those tools are in a good position. They can move at their own speed without being frozen, waiting for the next major release."

The evidence is everywhere. Postgres added native partitioning, but pg_partman still thrives because it handles scheduling and lifecycle management the core deliberately excludes. pg_dump and pg_basebackup exist in core, but pgBackRest and WAL-G handle the workflows production environments actually require. Core provides the foundation; the ecosystem builds on top. When a foundation piece is missing, the ecosystem builds that too, and eventually it gets absorbed.

That cycle only works if the absorption pipeline keeps moving. Right now, the pipeline has a bottleneck.

Stuck in review

AI has accelerated Postgres development on the authoring side. Contributors now use AI tools to test proof-of-concept ideas in a day or two instead of shelving them for months. The reviewing side hasn't kept pace. "We don't have problems with the coding, with providing new ideas, with testing something. But as a community we're still limited to reviewers, and we don't have more of those," said Golub.

Committer status in Postgres is earned through years of sustained contribution and trust-building. The review process covers everything from variable naming conventions to subtle interactions between subsystems in a codebase that's been under active development for over three decades. AI-generated reviews, in Golub's view, aren't useful at this level of complexity. "AI is good at feedback, but what part of it is good for you? You have two pages of text, and the first page says your comma should be on the previous line. That's not significant."

The community's workaround is the conference circuit. PGCon in Vancouver, FOSDEM in Brussels, PGConf EU in Valencia. Face-to-face events compress months of mailing list gridlock into a conversation over beer. "You grab a colleague, find the person who has the objection, buy them a beer, and explain what you agreed on," Golub said. "He goes, 'Yeah, that makes sense, let's do that.' You just jumped over a hundred emails."

That dynamic works, but it can't scale to match the volume of patches AI-assisted development is producing. Growing more reviewers still requires the old-fashioned inputs: time, mentorship, and trust earned over years.

The gaps PG19 doesn't touch

Two operational pain points came up unprompted in separate conversations, and neither is addressed in this release.

The first is high availability. Pinsky named it as Postgres' single biggest gap. Setting up replicas and automated failover still requires third-party tooling like Patroni, and the complexity is considerable. "Every time I need to set up high availability," he said, "I lose a little more hair." He pointed to MySQL's simpler built-in HA and hopes the community does for availability what it just did for repack.

Pinsky also sees teams repeatedly confusing availability with disaster recovery. "If someone drops a table, it drops on the replica too. If you lose data, you lose it in both places." Combine that with Postgres' default asynchronous replication, which means failover events can result in data loss even in correctly configured setups, and the HA surface area is larger than most teams realize.

The second is the monitoring internals. Golub has been trying to add a single column to pg_stat_statements tracking when a query was last executed. The attempt exposed how brittle the current architecture has become. "One tiny column caused a lot of stress inside the community because we're already at the margin, and we can't add another column without breaking things," he said. A full redesign is underway. Golub expects it in PG20.

What PG19 tells us about PG20

The absorption pipeline is working. But the throughput is constrained by the reviewer pool, and the gaps that remain, HA and the monitoring internals, require exactly the kind of deep architectural review work that's hardest to staff.

PG20 will be where those threads converge. If pg_stat_statements gets its redesign and the HA conversation gains enough momentum to produce a serious proposal, Postgres' trajectory as the default enterprise database stays on track. If the reviewer bottleneck slows that work down, the ecosystem will keep building the workarounds. It always has. The question is how long that needs to keep running before the core catches up.