Why PostgreSQL's MVCC Design Choices Are Often Misunderstood
PostgreSQL's MVCC is bad. So is everyone else's
Critics often blame PostgreSQL's MVCC for bloat and write amplification, but these are deliberate design trade-offs, not defects. Every database engine handling concurrent reads and writes faces similar challenges, just with different costs. I demonstrate how PostgreSQL's specific answers to versioning questions create known overheads, while alternatives simply shift the burden to writers, readers, or background processes. The real issue isn't the mechanism itself, but understanding what every system sacrifices to achieve concurrency.
MVCC is not optional. Any database that wants readers to not block writers has to keep multiple versions of rows somewhere, and every engine that does so answers the same four questions.
- gtowey
I'm conflicted with this article. It does pack a lot of good information in there, and it's a useful comparison of the core difference between PostgreSQL and MySQL. But it still contains a lot of LLM-isms which are off putting and make me want to stop reading when I see them.
- shayonj
> Nothing was solved. The four questions got new answers, and the costs moved into the compactor.
I have been meaning to write on this topic and in relation to LSM for a while. So, I appreciated that note on LSMs. There are no free ~lunches~ reads or writes.
- jhgb
I'm surprised that Interbase/Firebird seems to be entirely omitted from this despite pioneering the MVCC approach.