'There Is No Boss': How Postgres Decides Its Future In Public

The keynote that opened POSETTE 2026 was not a product launch or a roadmap unveiled from on high. It was four people from competing companies, sitting on a livestream and debating in public about what a thirty-year-old database should become next.

Álvaro Herrera builds Postgres under the EDB banner. Heikki Linnakangas co-founded Neon, now part of Databricks. Melanie Plageman is a principal engineer at Microsoft, and Thomas Munro is a committer there too. Between them, they've spent the better part of a working lifetime committing code to the same project. When they sat down for the Postgres 19 Hackers Panel, they weren't there to sell anything. They were there to talk through what made the cut for the next release, what missed the boat, and what they're still fighting about. The question running through it was the one worth asking: how does Postgres, with no central owner, keep out-shipping the cloud platforms that wrap it for a living?

Drawing the roadmap

The short version is that the argument is the product. There's no Postgres corporation that decides the roadmap and hands it down. There's a mailing list, a wiki page of open items, a feature-freeze deadline, and a few dozen committers scattered across rival payrolls who have to talk each other into things. Munro got to the heart of the matter: In an open-source community, you can't really tell people what to do. There's no boss. Every feature that ships is something a quorum of people who answer to different employers agreed was worth shipping, on their own reading of the merits. That's a far higher bar than any single vendor's quarterly plan has to clear.

Nothing illustrates that bar like multithreading, the change the panel was most candid about precisely because it's taken so long. Postgres has run each connection in its own operating-system process since the beginning, and moving to a threaded model is the kind of foundational rework that touches everything and breaks nothing, or else. Munro and Linnakangas have been passing patches back and forth on one piece of it, the machinery by which database backends wake each other up, for roughly three years. And the difficulty isn't only technical. For years, Munro noted, a lot of respected people argued that staying single-threaded was a virtue, and the work couldn't really start until the community talked itself out of that position. "I think as a community, we've finally got over the hump of actually agreeing that we're going to do this," he said, which is a strange and revealing way to describe progress on a database. The hard part was reaching consensus that the code should exist.

Then the calendar intervened in a way that says something about what this project considers its actual job. Munro had wanted multithreading patches in Postgres 19 and didn't get them in. The entire software industry has been dealing with a wave of security work, as he put it, and he and Linnakangas dropped everything to address CVEs that were, in his word, scary. One of the project's most basic duties is to protect people's data, he said, and that duty outranks the marquee feature every time. A vendor under pressure to demo something new at its annual conference doesn't get to make that trade so cleanly. An open project that answers to its users rather than a sales motion does, and the multithreaded future waits another release because the people doing the work decided that protecting people's data came first.

What the core decides to absorb

The same release shows the other half of the process working, where the open project absorbs something its users had been bolting on for years. For a very long time, anyone who needed to reclaim disk space from a bloated table without locking it had to reach for an external tool. The lineage went from pg_reorg to pg_repack to pg_squeeze, each leaning on older machinery to fake an operation Postgres couldn't do natively. Herrera worked with Antonín Houska of Cybertec to bring that capability into core for Postgres 19, rebuilt on a cleaner internal mechanism. It finally gives users the online version of a full table rewrite they've been requesting "for a very long time," he said. Plageman pressed him on the governance question that decision raises, and the exchange was the most instructive minute of the panel. The project tries not to pull things into core unless they truly belong there, she pointed out, because once something is in core, its users are bottlenecked on the committers forever. The case for bringing the repacking work in was that core can do things a third-party tool structurally can't, and that the demand was real and durable. That's the actual deliberation, conducted out loud, over whether to expand the surface a few thousand companies depend on.

What you don't hear on this panel is anyone pretending to certainty they don't have. The most telling moment came when Munro described the response to one of his patches from Andres Freund, a committer whose review carries weight. The patch worked, Freund told him, but he couldn't pinpoint the reason. "It seems to work really well, but I have no idea why," Munro recounted, and rather than wave it through, he went down a week-long rabbit hole trying to understand the thing well enough to defend it. A commercial roadmap optimizes for shippable; this process optimizes for understood, and is willing to be slowed by a reviewer's honest confusion. That willingness is the source of its credibility.

The contrast with how the same software gets sold was hard to miss across the rest of the conference, which is run by Microsoft and exists partly to put a cloud face on the database. The platforms wrapping Postgres move fast and market hard, and they have every incentive to. But the thing they're wrapping is governed by a process none of them controls, and that's the source of its staying power. Paula Berenguel, who leads Postgres upskilling for Microsoft's field engineers, made the point better than any neutral could when she stepped back from the product to explain why the database is worth teaching at all. Postgres, she said in her POSETTE talk, is "the database that never changes phone number," the one constant under a decade of shifting hype cycles, and it "survived 30 years without a marketing department." The reason, she explained, is that the community is the curriculum.

The institution that keeps Postgres current isn't a company. It's the argument itself, carried on across organizational lines.

The bet, and its exposure

That argument is also what a lot of businesses are now wagering on. A database stewarded by contributors with no shared boss is more durable than one owned by any single vendor, because no vendor's bad quarter or change of strategy can redirect it on its own. That said, that durability comes with exposure. When a critical piece of the surrounding tooling rests on one or two maintainers, the open model's strength becomes its vulnerability. The near-loss of a widely used backup tool was an unsettling example, and the scramble to fund its continuity exposed a stewardship problem the field can't keep deferring. Distributed governance is the reason Postgres still out-ships its wrappers. The same distribution is the reason a single person's burnout can threaten infrastructure that thousands of companies depend on.

The Hackers Panel is what the healthy version of that model looks like in a single frame. No one in the room could order anyone else to build a feature, and that's exactly why the features that do ship have already survived the only audit that matters: a hard look from people who don't work for you and have no reason to flatter your idea. Postgres turns thirty this year because enough engineers from rival firms keep showing up to argue about it in the open. After three decades, that argument is still the most reliable thing the database has going for it.