What A Morning With Postgres’ Maintainers Reveals About How The Database Really Gets Made

The second morning of POSETTE opened with a room full of the people who actually write Postgres, talking with unusual candor about how the thing gets made. The day's keynote was a panel of four committers with something close to seventy-five combined years inside the codebase, walking through the public ritual every Postgres release ends with: what made the feature freeze for the coming version, what missed the boat, and what got reverted at the last minute.

If you only knew Postgres as the polished default the AI industry now runs on, the panel was a useful corrective, because the version of the project these four describe is messy, deadline-driven, and held together by people in different time zones who mostly work alone. What stood out watching it live was, surprisingly, the tone. This is a thirty-year-old project run by people with no shared boss, and they talk about it like a workshop, not a product.

Melanie Plageman, a principal engineer at Microsoft and a Postgres committer, set that mood early by choosing to talk not about the feature she landed but the one she didn't. Her write-combining work, an effort to let the database push more than a single block to disk at once, fell apart in February. It was late enough in the cycle that there was no room left to rethink it. The hard part, she said in the POSETTE keynote panel, is proving the idea behaves under every load you can imagine. Best case, worst case, all the awkward combinations in between. That exercise is where the months go.

Thomas Munro, also a committer at Microsoft, described reading "difficult books about queuing theory" to tune one piece of the I/O machinery, only to have a reviewer tell him the patch seemed to work really well but he had no idea why. That admission, from people at the center of the project, is the texture that never shows in the marketing. The implications of how this group decides what ships run deeper than any one release note.

Turning around to teach

The rest of the morning was the same people, turning around to teach. That was the real shape of day two: the maintainers and longtime contributors explaining the parts of Postgres they know best, to a room trying to understand the database one layer down. The most radical talk on the schedule was the one that turned around and asked the audience to come help build it.

Xuneng Zhou, an independent contributor who co-authored a new command for read-after-write consistency, gave that invitation a title borrowed from Douglas Adams (a running theme in his contributions to the community): don't panic, just start small. From the outside, Zhou said in his POSETTE talk, Postgres "can look finished and intimidating," but from the inside "it's still a living engineering project where people ask questions, revise patches, and change their minds." His advice for anyone daunted by a massive codebase and a hypercritical review culture was to stop trying to understand everything and instead review someone else's patch or fix a small bug. He walked through one real review of his own consistency feature to show how a narrow question compounds into genuine understanding. Feedback from other hackers reshaped the command into something more general than he'd first proposed. Knowledge "expands fractally," he said, looking smooth from a distance and full of gaps up close. The closing line was the talk's whole argument: do not panic, just start small.

If Zhou's talk was about getting in the door, the teaching talks that followed were about what's behind it. Richard Yen, a senior software engineer at Microsoft who's run Postgres in production for more than two decades, took on the question every developer eventually asks in frustration: why does the database sometimes refuse to use the index you built for it? The answer, he explained in his POSETTE talk, is almost never a bug. The planner is choosing a full table scan on purpose, because the statistics it keeps about your data tell it that's the cheaper path. When those statistics are stale or too coarse, it makes confidently wrong choices. The planner is only as smart as the statistics you feed it, he said. That small idea has a long reach, sitting underneath a surprising number of the performance mysteries practitioners spend nights chasing.

Murat Tuncer, a software engineering manager at Microsoft, gave the morning its most genuinely fun history lesson, tracing how Postgres came to have roughly a dozen ways to prove who you are. None of them, he argued in his POSETTE talk, is an accident or a mistake. Each one solved a real problem at a real moment: the trusting university machines of the 1990s where a colleague was assumed not to be an attacker, then passwords and directories and certificates, up to the short-lived tokens that arrived as native support in the latest release. The reason the configuration looks like an archaeological dig is that the project never deletes a method once it ships, so the file reads as its own history. His warnings landed hard. People still run the most trusting setting in production, and the recurring failure is a strong mechanism bolted on without a plan to revoke it. Whatever you pick, he said, always optimize for revocation.

The changes that took years to agree on

The new-features talks carried the same teach-the-room spirit. Gülçin Yıldırım Jelínek, a technical product manager at Xata and a Postgres contributor since 2012, opened by promising she had read the entire changelog so the audience wouldn't have to, then walked through what the latest release does for constraints. The headline was temporal keys, which let the database refuse to double-book a resource by treating a time period as part of an entity's identity. A room booked from ten to eleven and again from eleven to noon will reject an overlapping request in between. She slipped in a point along the way that fits the day's theme of a project slowly absorbing the hard things. The patch making absence-of-value a fully first-class constraint had been discussed since 2010 and took roughly fifteen years to land, which is what real consensus costs in a community with no boss to break ties. Some of the deepest changes in a release, she suggested in her POSETTE talk, are the ones that took the longest to agree on.

Paolo Melchiorre, a Django Software Foundation board director and Python Software Foundation fellow, brought the same news from the application side. Generated columns, where the database computes a value for you instead of trusting your code to keep it in sync, have existed for years. The latest release adds a version that computes on read rather than on write, useful when you write often and read rarely. The thread running through his POSETTE talk was that the right place to put this logic is the lowest level you can reach. For most developers, that means pushing work down out of their application and into Postgres, where it stays correct without anyone remembering to update it.

The morning's most pointed argument came from Alexander Kukushkin, a principal engineer at Microsoft known across the community for his work on the Patroni high-availability tool. He set out to stop people from rebuilding a solved problem badly. Engineers keep reaching for a simple in-database queue and keep watching it collapse under load, he explained in his POSETTE talk. The obvious approach churns through dead rows and demands aggressive cleanup until queries that took milliseconds start taking tens of seconds. The fix is a roughly twenty-year-old extension called PgQ, born alongside the connection pooler everyone knows from the same toolkit. It sidesteps the whole failure mode by never updating or deleting rows in the first place. He defended it with the kind of plain conviction the day was full of, calling it the work of real engineers and real Postgres hackers, stable like a rock and most likely bug-free. The lesson was less about one extension than about institutional memory. The answer often already exists, and the community's long tail of unglamorous, well-worn tools is one of its real advantages.

The newest thing to refuse

That tension between what the database can do on its own and what we should let software do to it on our behalf is exactly where the day's most forward-looking talk lived. Mohsin Ejaz, a benchmarking engineer at the Postgres-tuning startup DBtune, used his slot to show what happens when an automated system reaches into a live database and changes the wrong thing. A single altered setting turned a fast query into a seven-second stall. His argument that an agent near production needs brakes, rollback, and a hard ceiling is part of a larger conversation about what agent-driven workloads demand from Postgres. Here it served as the bridge between the people building Postgres and the systems now being built on top of it.

The committers on stage spend their careers deciding what the database should refuse to do, by hand, over years of argument. The newest question facing them is how to teach it to refuse an agent in milliseconds. On a day given over to how Postgres gets made, that felt less like a departure than the next patch in the queue.