July 27, 2026
Dirty data, dirtier comments
PostgreSQL's MVCC is bad. So is everyone else's
Postgres gets roasted for being messy, but fans say every database is hiding the same chaos
TLDR: The article argues PostgreSQL’s messy behavior comes from a deliberate design choice, and rival databases pay for the same problem in different ways. Commenters split between veterans saying “yes, all systems have trade-offs” and critics dunking on the article’s writing as “AI slop.”
Database nerds showed up for a technical debate and somehow the comments turned into a full-blown style war. The article’s big claim is simple enough for civilians: PostgreSQL, a hugely popular database, stores old and new copies of data so readers and writers don’t trip over each other. Critics say that makes it bloated, noisy, and high-maintenance, with endless cleanup and extra writing. Supporters reply: okay, sure, but name one rival that gets this for free. The whole point of the piece is that every database has to make ugly trade-offs somewhere, even if the mess is hidden in a different closet.
But the crowd? They were absolutely not content to discuss only the engineering. One of the loudest reactions was a brutal drive-by from otterley, who basically said the article may be useful but reads like “AI slop” and begged writers to sound human again. Ouch. That instantly shifted the vibe from dry database talk to comment-section bloodsport. On the other side, sbuttgereit came in with veteran energy, saying they were glad someone finally admitted the obvious: versioned databases are all trade-offs, and PostgreSQL is hardly the only one with baggage.
So the hottest split wasn’t even “Is Postgres bad?” It was more like: Is this an honest reality check, or a painful lecture wrapped in robot prose? The accidental comedy is that even in a post arguing no database is perfect, readers still found time to declare the writing the real disaster.
Key Points
- •The article says PostgreSQL’s MVCC costs—such as table bloat, write amplification, dead tuples, VACUUM overhead, and transaction ID limits—are consequences of deliberate design choices.
- •It frames MVCC as a necessary mechanism for databases that allow readers and writers to proceed without blocking each other.
- •The article identifies four design dimensions across MVCC systems: where old versions are stored, chain direction, what indexes point to, and who performs cleanup.
- •It explains that PostgreSQL UPDATE operations create a new heap row version, mark the old row with `t_xmax`, and leave cleanup to VACUUM.
- •A worked example with 1 million-row tables and WAL measurement is used to show write amplification when updating 100,000 rows, even on a non-indexed column.