- PostgreSQL's MVCC stores old row versions in the table itself, leading to bloat, write amplification, and reliance on VACUUM for cleanup.
- Alternative MVCC designs (Oracle/InnoDB, SQL Server, MongoDB, LSM-based databases) relocate costs to undo logs, tempdb, cache, or compaction, with their own failure modes like snapshot-too-old errors, rollback overhead, or instance-wide stalls.
- All MVCC systems face the same fundamental tension: they must choose how to handle version storage, indexing, cleanup, and long-running transactions, and no design eliminates all costs—they merely shift them between writers, readers, background processes, or storage components.
- PostgreSQL's heap-based MVCC offers zero-cost rollback and never cancels readers, but makes garbage visible and operator-driven, contrasting with undo-based engines that impose costs on writes and historical reads.
- Efforts to replace PostgreSQL's MVCC (zheap, OrioleDB) are ongoing but face significant engineering challenges, as the heap's simplicity is foundational to the system.