The Best Lesson From POSETTE’s Vendor Day: When Your Postgres Feels Slow, It's Rarely Postgres

By the third afternoon of POSETTE, the conference had stopped pretending it wasn't a sales floor. Day three was the product day, the one where the cloud vendors who underwrite this event got their turn at the microphone, and the run of show read like a tour of managed offerings, new database services, rewritten storage layers, retrieval stacks for AI.

What stayed with us afterward was not any of the architecture diagrams the vendors flew us through but a claim that kept surfacing underneath the demos, voiced most plainly by the practitioners who weren't selling anything: when your Postgres feels slow, the cause is almost never Postgres. It's the storage you put it on, the version you never upgraded off of, or the maintenance you stopped doing.

The rot you can't see

The cleanest piece of news on the program came from someone bringing a discipline to Postgres that every other language already takes for granted. Pavlo Golub, a senior consultant at the Austrian Postgres firm CYBERTEC, used his POSETTE talk to introduce pgcov, an open-source tool that measures test coverage for database code the way Go or Rust developers measure it for application code. His framing was the whole argument. "SQL is a real code," he said, and a Turing-complete one at that, full of functions, loops, and branching logic. Yet the procedural code living inside the database has been a place no coverage tool could see. Tests pass, the build goes green, and you still can't say which branches of your logic ever actually ran. pgcov closes that gap without touching the engine, spinning each test up in its own throwaway database and tearing it down clean. Golub's live demo walked a sample project from half its code exercised to seventy percent by filling in the missing tests. The reason this belongs in a story about slowness is that untested database logic is exactly the kind of thing that works in development and rots in production. One of the hosts caught it on the way out, recalling an old shop saying that tests are for correctness and coverage is for confidence. The data layer, he noted, is the part teams trust least and inspect least.

If pgcov is about the rot you can't see in your code, Sarat Balijepalli's session was about the rot you can't see in your tables. It was the most useful twenty-five minutes of the day for anyone running real load. Balijepalli, who said he's spent close to eighteen years on databases, built his entire talk around one sentence: "performance doesn't break suddenly, it degrades silently over time." A table that holds a few thousand rows behaves beautifully and gives no warning as it grows into the billions. Then one day, the queries that never changed are slow and nobody touched anything. He catalogued seven distinct ways a large table decays without warning: bloat that automatic cleanup can no longer keep pace with, a cache that thrashes once the working set outgrows memory, storms of forced freezing that hit insert-heavy tables hardest, write volume that turns orderly checkpoints into bursty ones, locking chains, stale planner statistics, update patterns that stop fitting on the page. None of these announce themselves. The fixes he laid out were the same boring competence the rest of the day kept circling back to: partition so each query only touches the slice it needs, tune the cleanup process to run more aggressively on the biggest tables, leave room on the page so updates stay cheap, watch the right counters before the symptoms reach the application. It's the complaint every operator eventually hears from a developer: 'I changed nothing. My queries are identical. Why is everything slow?' Because your data grew, and you stopped maintaining it.

Slow is usually the version or the storage

The version question got its own demonstration. Divya Bhargov, an engineer on the Postgres team at Microsoft, ran a side-by-side comparison of identical workloads on Postgres 17 and Postgres 18. The wins she showed are core open-source planner improvements, free on upgrade, with the same queries and no application changes. The one worth understanding is what happens when an index leads with a column your query doesn't filter on. That's the classic case where the older planner falls back to grinding through most of the index. The newer planner recognizes that the leading column has only a handful of distinct values and probes each one directly instead. A query that crawled in the old version returned effectively instantly in the new one. Other improvements were subtler, including the planner learning to throw away the redundant self-joins that object-relational mapping tools generate, which Bhargov called the "abstraction tax" that Postgres used to pay in full on every query. Her verdict carried more force precisely because it cost her nothing to say it about software no vendor owns: the answer to whether you should upgrade is almost always yes, and with this release it's, in her words, "a pretty enthusiastic yes." A meaningful share of the slow databases in the field are slow because they're sitting on an older version that left these wins on the table.

Sai Srirampur, who leads Postgres at ClickHouse and has spent years building replication tooling, put the storage half of the thesis most directly. His title was the argument: Postgres isn't slow, your storage is. He walked through the common complaints operators file against Postgres: slow ingest, inconsistent read latency at the tail, cleanup that can't keep up, sluggish checkpoints. Nearly all of them, he argued, trace back to the disk underneath rather than the engine on top. The frame that lands is the memory hierarchy. There's an enormous latency gap between the database's in-memory cache and the network-attached storage most cloud deployments rely on. Every time a query misses the cache, it falls into that gap. Storage physically attached to the machine sits inside that gap and behaves, in his telling, like a second tier of memory. Cache misses cost microseconds instead of milliseconds, and the commit path stops waiting on the disk. One of the hosts summed it up better than the slides, saying Postgres can be a Ferrari, but on bicycle tires it isn't going anywhere fast. The same point cuts the other way too: a lot of teams reach for the engine's tuning knobs when the honest fix is to stop running on slow storage.

The promise underneath every commit

Not everything on the program was about performance. Two talks were about the deeper promise that makes the maintenance worth doing in the first place: once the database tells you a write committed, that write is not coming back, even through a crash. Bruce Momjian, the longtime EDB engineer and Postgres elder, opened the livestream with the foundational explainer: the write-ahead log. It's the running record of every change that gives Postgres its durability and underpins crash recovery, point-in-time restore, and replication. He's been giving talks for decades and said this was one he'd always wanted to write. The reason it anchored the day is that the write-ahead log is what makes the commit promise keepable in the first place.

Later, Jeremy Schneider, a Postgres engineer at GEICO who came to the database after fifteen years in Oracle, and Leonardo Cecchi, a maintainer of the open-source CloudNativePG project at EDB, took that promise to its hardest case. What happens during a failover, when the primary database dies and a replica has to be promoted? Schneider is opinionated about the starting point. Anyone running Postgres on Kubernetes should be using synchronous replication, he argued, where the commit isn't acknowledged until the data has reached a replica. The harder problem is proving you can promote a survivor without silently dropping a transaction that was acknowledged but hadn't propagated. Their answer borrows a decades-old idea from distributed systems: a quorum check that fires only when the cluster reconfigures, refusing to promote unless the math guarantees the most up-to-date replica is in hand. When the guarantee holds, it promotes automatically; when it can't, it stops and pulls a human in rather than gamble. Cecchi's underlying point was that the database, not the orchestration layer wrapped around it, stays the source of authority for what's safe and what isn't. The feature is open source and shipping. For shops still writing down how they'd survive a maintainer walking away or a tool going dark, it sits next to the continuity questions practitioners have started auditing across the rest of their stack.

What the vendor demos were selling, by contrast, was the idea that the agent era needs a new kind of database, and there were polished tours of retrieval pipelines and rewritten storage architectures making that pitch.

The honest through-line of day three came from the people without a booth. A slow Postgres is a solvable problem, and the solution is almost always boring. Put it on real storage, get current on your version, and maintain the thing while it's still fast, because the day it feels slow, the decay has already been running for months.