Global Indexes, A Reversed Commit, And A Dead Extension Model: How Postgres Features Actually Reach Users

Postgres 19 Beta 1 dropped last month with 212 items in its draft release notes. REPACK CONCURRENTLY. SQL/PGQ. Logical replication of sequences. Parallel autovacuum. By any measure, a heavy release.

But for every feature that made the cut, there are features that have been in development for years and still aren't there. Global indexes, requested since Postgres 12, didn't ship. DDL replication didn't ship. The async I/O subsystem that landed for reads in Postgres 18 is still being extended for writes, with almost no visibility in the release notes.

Core contributions have to survive a distributed review process where each prerequisite must prove its own standalone value before the next layer can land. Extensions, once the fast path for capabilities that couldn't wait for core, are increasingly gated by managed services that decide which ones are available. And a growing number of practitioners have stopped waiting on either channel entirely.

Nine versions and counting

Global indexes are one of the longest-running gaps in Postgres' partitioning story. The feature has been requested since partitioning landed in Postgres 10, and it drew the highest vote count of any topic at a recent PGConf.dev session, with roughly 40 votes.

The constraint it would solve sits at the intersection of partitioning and uniqueness enforcement. "People can use partitioning, but they can't define a unique constraint on a non-partitioning key column," Dilip Kumar, a Software Engineering Manager at Google who works on Postgres core, told The Read Replica. "That's a major drawback, and it's stopping many users from shifting from Oracle or any other database to PostgreSQL just because of this constraint."

Kumar works on partitioning infrastructure and global index development inside the Postgres community. He's tested the vacuum performance implications of proposed global index implementations firsthand, and the numbers explain why the feature hasn't shipped.

The workarounds are painful. An organization partitioning a customer table by customer ID that also needs email uniqueness has to build that enforcement in the application layer. "They need to query each partition before inserting to check that the email doesn't exist in any other partition, or define a trigger that checks all of them," Kumar said. "If you have thousands of partitions, it's a real drawback for performance."

A global index would eliminate that entirely by maintaining a single index structure spanning all partitions. But building one exposes a deeper architectural problem in how Postgres handles vacuum, the process responsible for reclaiming storage and maintaining database health.

In Postgres today, heap and index vacuum are tightly coupled. When you vacuum a table, the associated indexes get vacuumed too. That works fine with local partition indexes, because each partition's index is small. A global index, by definition, spans every partition. And vacuuming it alongside each individual partition creates a performance cliff. "I have tested that with 10,000 partitions, if you have a global index, vacuum performance goes from 15 seconds to 45 minutes. That's the scale we need to address," said Kumar.

The fix isn't optional, and the project can't just patch around it. "You can't just implement those improvements in the vacuum and commit them to core," Kumar explained. "You need to come up with a project that can show its independent value. So we're trying to first get the decoupling of index and heap vacuum, which has its own value irrespective of global index. And once that is running in the code, then you can slowly get the global index in over subsequent versions."

It's an approach that prioritizes long-term stability over near-term delivery. And it means global indexes are still, realistically, multiple major versions away.

Between the commit and the release note

That pattern of layered, prerequisite-driven development isn't unique to global indexes. It runs through the entire core development process.

Xuneng Zhou, a Postgres Hacker at Highgo Software who works on replication and WAL internals, sees this with the async I/O subsystem. AIO shipped as a headline feature in Postgres 18, replacing synchronous I/O for read operations with a more efficient model for sequential scans and prefetching. The write path is the next phase, and arguably the harder one.

"If you search the PG19 release notes, you won't find an item about the progress of this feature," Zhou said. "It's happening under the hood. It's stabilizing what shipped before. And it's done a lot of work in the buffer manager to prepare for the more ambitious parts, like AIO for writes."

Zhou contributed the WAIT FOR command to the Postgres codebase, and its journey through review illustrates why that invisible work often looks different by the time it surfaces. The feature was originally proposed and merged as a function. Then committers identified a potential data lock scenario in the implementation and reversed the commit. "The committers said, 'We don't want these constraints. Maybe we can propose a better interface,'" Zhou said. "At the end of those discussions, the interface was redesigned as a command, so we could avoid the data lock."

The distinction between function and command might sound academic. But the committers who caught the problem were protecting every user who would have encountered that lock in production. And the pattern holds across the project: patches enter review shaped by the team that built them and exit shaped by the people who would have to live with them.

"If you get feedback from various vendors and committers, the shape of a patch is way better than the first version. The risks, the shortcomings, the underlying issues all get discussed publicly in the mailing list." The cost is speed. Zhou was direct about it: the pace of community development is always slower than vendor development. But the output is universally accessible, which matters for the organizations that can't afford a proprietary layer on top.

That tradeoff doesn't always play out predictably. Nikolay Samokhvalov, Founder of PostgresAI and Co-Host of the Postgres FM podcast, expected REPACK CONCURRENTLY to take years to reach core. Online table reorganization without locking has been a long-standing pain point, addressed externally by tools like pg_repack and pg_squeeze. When the initial REPACK command landed without the CONCURRENTLY option, Samokhvalov assumed the concurrent version was still far off.

"I thought, 'OK, this is at least a two or three year project,'" Samokhvalov told The Read Replica. "But then a few weeks later, another commit lands: REPACK CONCURRENTLY. I was super impressed with the pace." The pace of core development may be accelerating. But for practitioners who need capabilities now, the core path still can't always deliver on their timeline. So they look to the next channel: extensions.

The extension model has a gatekeeping problem

Extensions have been Postgres' answer to the breadth problem for decades. If a capability didn't belong in core, or couldn't survive the review process on a useful timeline, someone could build an extension and distribute it independently. pgvector for vector search. PostGIS for geospatial. pg_repack for bloat management. The extension model is what let Postgres stretch into workloads it was never explicitly designed for.

That model depended on an assumption that no longer holds: that users could install whatever extensions they needed. Samokhvalov has been contributing to Postgres core for six years. He helped companies including Chewy and GitLab scale their Postgres deployments through IPO. And over the past decade, he's watched the extension model erode as managed services replaced self-hosted deployments.

"The idea of extensions has died, basically," Samokhvalov said. "Managed services have only a strict set of extensions, and that's it. If you develop your own extension, you need to be super lucky. Like it happened to pgvector. That's the exception to the picture."

Samokhvalov's response has been to stop writing extensions entirely. "I quit," he said.

Instead, he's built tools as pure SQL files that can be dropped into any Postgres instance without requiring extension support from the hosting provider. His PgQue, a queue system based on architecture originally developed at Skype 20 years ago, is approaching 2,000 GitHub stars. It provides durable, append-only log functionality similar to Kafka, implemented as a single SQL file.

AWS recognized a version of this problem with Trusted Language Extensions, a framework that lets users create and install extensions using SQL and trusted languages without requiring access to the underlying file system. Supabase supports PG TLE as well. "The core of that idea, basically, is that we don't need extensions. We just need SQL," Samokhvalov said.

It's a pragmatic workaround, but it also represents a narrowing of what's possible. Extensions written in C can reach deeper into Postgres internals than anything built in SQL or PL/pgSQL. The capabilities that made pgvector and PostGIS transformative (custom index types, new data types, storage-level optimizations) require that kind of access. Pure SQL tools solve the distribution problem but trade away a layer of capability that extensions were specifically designed to provide.

The channels that shape the database

Postgres 19's 212-item release notes are the visible output of a development process that moves at its own pace for defensible reasons. Each feature in that list survived distributed review, proved its standalone value, and shipped without the kind of data lock or vacuum performance cliff that would have created new problems for the users it was meant to help.

But the features that aren't there yet, and the workarounds practitioners have built in the meantime, describe a parallel story. Global indexes are waiting on vacuum infrastructure that has to justify itself first. AIO is evolving across versions in ways the release notes don't capture. And the extension model that gave Postgres its famous flexibility is being reshaped by the managed services that brought the database to the mainstream.

The capability that reaches Postgres users has always been filtered through the channels available. What's changing is that practitioners are increasingly aware of where those channels are constrained, and they're building accordingly. Whether that means shipping prerequisites one version at a time, redesigning interfaces to satisfy committers who caught something the original author missed, or writing SQL files that bypass the extension pipeline entirely, the path capability takes into Postgres tells you as much about the project's future as the capability itself.