POSETTE '26: Postgres Has Stopped Trying To Prove It Belongs And Started Absorbing The Stack Around It

The first livestream day of POSETTE 2026 opened the way these conferences usually do: a vendor keynote and a run of product tours, while attendees waited for the good stuff. About an hour in, when the independent consultants and community speakers finally took their slots, it turned out they were all, more or less, telling the same story.

The talks that drew us in this Tuesday were not about adding something new to Postgres. They were about how much it has already swallowed, how many separate systems an application no longer needs to stand up alongside it, and how a team can do that work without a second database, a second service, or a second on-call rotation. Thirty years in, the pitch from the floor was that Postgres is where the rest of your stack goes to retire.

Solve it in the database

Chris Ellis made the case most plainly. Ellis runs Nexteam, a small application-development house in the UK, and his POSETTE talk on design patterns was a tour of features most application developers walk past on their way to bolting on another piece of infrastructure. Based around the story of a booking and subscription platform he'd built, the throughline of the talk was that the database can enforce the rules the application keeps getting wrong. Two events should never be booked into the same room at the same time, and as Ellis said at POSETTE, that constraint is "often very difficult for an application to enforce using standard business rules in a safe manner." But Postgres can simply refuse to let it happen. He used the same posture to guarantee a member has only one active subscription at a time, a guardrail he said has "really saved my my ass a few times." And rather than reach for a separate message broker, he built a parallel-safe task queue inside the database itself, the sort of thing teams routinely install a whole new system to get. The argument underneath all of it was that an application that treats the database as a dumb store, with the logic living somewhere else, is leaving most of the safety and most of the power on the table.

That theme, using Postgres for the thing you were about to add a system for, ran straight through the day. Christian Miles has spent about fifteen years building graph-visualization tooling, now at gdotv, and his talk on Apache AGE walked through running graph workloads inside Postgres rather than standing up one of the hundred-plus dedicated graph databases he catalogs. But he was careful not to oversell it. Most people only know Neo4j, he said, and AGE earns its place not by being the most powerful graph engine but by being the one already living next to your relational data, with the transactions and indexing and infrastructure you already run. The pure-SQL way of doing the same traversals runs to about fifty lines of what he called "brittle SQL" that "you wouldn't want to maintain." Miles also marked the direction of travel: SQL/PGQ, the standards-based way to do graph pattern matching in SQL itself, has been committed to Postgres core targeting version 19, though he was clear it is "not guaranteed to be in the next release." AGE, he noted, is available now. His real subject was what to do once the data is in there, because a force-directed picture of a dense graph is usually a tangle that tells you nothing. "Complexity on screen isn't insight," he said, which is about as good a one-line warning against the genre as you will hear.

The same absorption story shows up in how Postgres handles the messy, semi-structured data that used to be a reason to go shop for a document store. Boriss Mejías, a solutions architect at EnterpriseDB, used his POSETTE talk on JSON to take on the reputation directly. Skeptics call the type evil, he said, and joke that the B in JSONB is for "beast," but his pitch was that "we can tame this data type." He argued that while schema freedom is real and useful, the moment a field starts earning its keep, you pull it out and make it a real column with a real key and a real constraint so the database can give you the integrity guarantees the document model never could. JSON for the parts that genuinely vary; columns for the parts that do not. It's the consolidation argument again, made from the opposite direction. You don't need a separate system for flexible data, because Postgres will hold it and discipline it at the same time.

Questioning the defaults

Those talks were about widening what Postgres takes on. Others were about the assumptions underneath what it already does. Tomas Vondra, a longtime Postgres committer at Microsoft, spent his talk re-running an experiment that's about twenty-five years old: the measurement that set the planner's default sense of how expensive random disk access is, relative to reading in sequence. That default hasn't moved since Tom Lane introduced the cost model around 2000. Of course, the entire hardware world underneath it has, from spinning platters to flash.

The standard advice has long been to lower it on solid-state storage. Vondra's measurements pointed the other way, with the empirical figure on SSDs landing far above the default rather than below it, and on spinning disks higher still. Here's the lesson he drew: the value was never really the raw cost of the hardware, the planner has no idea what's sitting in cache or what else is running, and anyone chasing a single magic setting from one isolated benchmark has misunderstood the problem. "A simple experiment can't give you a good number," he said. It was an unusually subversive talk for a vendor conference, a core contributor telling the room that a quarter-century-old default deserves to be re-questioned rather than worshipped.

Adam Wolk, also at Microsoft and an OpenBSD committer, brought the same adversarial instinct to the database's own robustness. His talk on fuzzing Postgres made the case for throwing deliberately malformed input at the system to see where its assumptions break, and he had the line of the day for it. "Testing is polite," he said. "Fuzzing is rude. It doesn't go to the door. It goes through the window, or through the back door." The encouraging part of his account doubled as a brag about the project's maturity. Across years of Google's continuous fuzzing effort, the tally he cited was nineteen bugs found in SQLite, fifteen in MySQL, and zero in Postgres. A separate academic study that ran for eleven days came up empty on Postgres, too. The query parser, he said, is "a very hardened piece" of software. His own simpler harness has not turned up anything dramatic yet, which he was honest about, but the broader point landed: a database absorbing this many new responsibilities is only trustworthy if people keep trying to break it on purpose, and Postgres has held up under more of that than its peers.

More surface area, more risk

That same trust question sat underneath the day's other thread, too. The keynote and the editor-tooling demos kept gesturing at AI tooling without ever landing on it directly: a near future where agents reach into Postgres the way developers already do. The consolidation story from the rest of the day made that prospect feel heavier. The more a single database holds, the more access control stops being a feature and starts being architecture, and the more it matters whether the database can be told no.

What tied the day together was not any one feature but a kind of confidence about the boundary of the project. The community speakers were not asking what Postgres might do someday. They were showing what it already does instead of three other systems, and the contributors were stress-testing the parts everyone already relies on. It's the posture of a thirty-year-old project that has stopped trying to prove it belongs and started absorbing the work around it.

Here's the tension: the more Postgres takes in, the more it becomes the one place where a careless instruction, from a person or an agent, can do real damage. Day 1 was the conference enjoying how much it had grown. The rest of the week explored the tougher question of what that growth demands.