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

Does PostgreSQL's Multi-Version Concurrency Control (MVCC) deserve the criticism it often receives? In this article, several charges are detailed against PostgreSQL's MVCC design, highlighting issues like write amplification, table bloat from dead tuples, the impact of idle transactions, and the constraints of a 32-bit transaction ID. Uber's negative experiences with PostgreSQL's write amplification showcase how deeply these issues can affect performance, forcing organizations to consider alternatives. The relative costs of MVCC implementation across various databases like Oracle, InnoDB, and MongoDB reveal that while no solution is perfect, PostgreSQL's design carries specific burdens that need attention. As the conversation evolves, database practitioners evaluate not just PostgreSQL, but how other systems fare based on their own unique trade-offs.