PostgreSQL's MVCC is bad. So is everyone else's

# Summary PostgreSQL's MVCC (Multi-Version Concurrency Control) design, while criticized for write amplification, bloated tables, and constant vacuuming needs, is not uniquely flawed—every database engine must solve the same multi-version storage problem, just with different trade-offs. The article examines PostgreSQL's specific design choices (storing old versions in the table itself, cleaning up later via background processes) and argues that alternatives like Oracle, InnoDB, SQL Server, and MongoDB simply shift costs elsewhere, such as to writers, readers querying history, or cache management. PostgreSQL's approach has provided one valuable property for free since inception: long-running transactions don't completely break all other database engines the way they do.