PostgreSQL's MVCC is bad. So is everyone else's
The article examines the design trade-offs of PostgreSQL's Multi-Version Concurrency Control (MVCC) system, addressing common criticisms regarding table bloat and vacuuming. It argues that these issues are intentional design choices rather than defects, comparing them to alternative database architectures.
Why it matters
Understanding database internals is essential for engineers optimizing high-scale systems and choosing the right infrastructure for specific workloads.
The first thing you will probably learn about Postgres, if you follow people who don't like Postgres, is that MVCC is bad. The 40-year-old design mistake. It's signatures are everywhere. Bloated tables that double in size, 32-bit transaction counter limit, the never ending struggle with VACCUM, dead tuples nightmares. It comes with credentials, too: Uber measured the write amplification in 2016 and left for MySQL over it; Andy Pavlo's database group called MVCC the part of PostgreSQL they hate the most . It's a real thing. Postgres is as bad as it gets.
Get smarter about the news
Sign up free for a feed built around what you actually care about, Dive Deeper research on any story, and the full text of every article.
Create free accountAlready have an account? Sign in