PostgreSQL's Multi-Version Concurrency Control (MVCC) has been criticized for issues like table bloat, write amplification, and the need for VACUUM. These problems stem from design choices: old row versions are kept in the table, version chains point old-to-new, indexes point to physical locations, and cleanup is handled by a background process.

While these choices lead to observable costs, they are not defects but rather a trade-off. Every database that prevents readers from blocking writers must maintain multiple row versions. PostgreSQL's approach answers fundamental questions about version storage, linkage, index targeting, and cleanup differently than other systems.

Criticisms like write amplification, evidenced by Uber's findings, arise because updates create new physical rows, forcing index updates. Bloat occurs as dead row versions accumulate, requiring VACUUM. Even idle transactions left open can impact performance. These issues highlight that MVCC is not optional for concurrent access, and alternative implementations simply shift the costs elsewhere.