July 29, 2026
Dirty reads, dirtier comments
PostgreSQL's MVCC is bad. So is everyone else's
Postgres gets dragged for making copies of data — but rivals aren’t exactly saints either
TLDR: The article argues PostgreSQL’s famous data-copying problem is real, but every rival database just hides similar tradeoffs somewhere else. Commenters split between praising that reality check and absolutely clowning the post’s alleged AI-like writing style, turning a database debate into a comments-section food fight.
The big claim in this fight? PostgreSQL, a hugely popular database, has a messy habit of keeping old and new copies of changed data around so readers and writers don’t crash into each other. Critics say that means swollen storage, extra cleanup chores, and lots of wasted effort. The article leans into the roast, practically saying, “Yes, it’s bad” — and then spins the twist: everyone else’s system is bad in a different way. In other words, there’s no magic fix, just different flavors of pain.
But the comments are where the real popcorn starts. One camp was into the argument, especially the line that there are “no free lunches” in database design — a neat way of saying every clever trick sends the bill somewhere else. Another camp barely cared about the technical point because they were too busy dragging the article’s “slop-tone” and alleged LLM-isms, with one commenter calling it a duplicate post that got revived only to be flagged. Ouch. Then came the awkward creator reply: “I give up.” Instant comment-section theater.
There was also classic nerd grievance energy: one reader was stunned that Interbase/Firebird didn’t get credit for pioneering this whole approach. So the vibe was split between “good comparison, useful point” and “I cannot get past the writing style.” The result? A very online showdown where the database drama was juicy, but the meta-drama about how the article was written may have stolen the show.
Key Points
- •The article argues that PostgreSQL MVCC’s commonly cited problems—bloat, write amplification, transaction ID limits, and VACUUM overhead—are consequences of deliberate design choices rather than defects.
- •It states that any database supporting non-blocking readers and writers must implement multiple row versions somewhere, so alternative engines also incur tradeoffs.
- •According to the article, PostgreSQL stores row versions in the table, creates new row copies on update, uses physical row locations for index references, and cleans up obsolete versions later via VACUUM.
- •The article explains that PostgreSQL `UPDATE` operations do not modify rows in place; they create a new tuple, mark the old tuple with `t_xmax`, and defer cleanup.
- •To demonstrate write amplification, the article sets up indexed and minimally indexed 1 million-row tables, updates 100,000 rows in an unindexed column, and measures WAL output using `pg_stat_wal`.