Reading the appropriate version
An update need not immediately remove the contents required by an older reader. MVCC retains version information and uses snapshot visibility rules to select the state appropriate to each read.
PostgreSQL uses this model to reduce reader-writer contention. Snapshot timing still depends on isolation: Read Committed generally establishes a view per statement, while Repeatable Read maintains a more stable transactional view.
Versions do not eliminate write conflicts
Competing writers may still wait, conflict, or abort. Explicit locks can coexist with multiversion reads, so the name MVCC does not imply a lock-free system or guaranteed successful commit.
Snapshot isolation can also admit serialization anomalies involving different rows. PostgreSQL adds dependency monitoring at Serializable isolation. Reading a complete older state and obtaining a serially equivalent outcome are separate guarantees.
Obsolete versions require safe reclamation
A version cannot be discarded while a transaction may still need it. Once obsolete, its space should be reclaimed rather than allowing updates to grow storage indefinitely. PostgreSQL uses VACUUM for this work.
Ordinary VACUUM chiefly makes dead-version space reusable; it does not generally compact the table to its minimum size or immediately return all space to the operating system. Version retention and cleanup costs accompany the concurrency benefit.
References: [4]