# Multi-Version Concurrency Control (MVCC) PostgreSQL implements **Multi-Version Concurrency Control (MVCC)** to manage data consistency and concurrency. Instead of locking rows for updates, Postgres maintains multiple versions of the same row. For the narrative explanation of this concept, see [[Chapter 1/1.5 - The Sharpie Ledger (MVCC)|1.4 MVCC (The Sharpie Ledger)]]. ## Core Mechanism 1. **Append-Only Updates**: When a row is updated, the original tuple is marked as deleted (using `t_xmax`) and a new tuple is inserted with the updated data. 2. **Snapshot Isolation**: Each transaction sees a "snapshot" of the data as it existed at the start of the transaction, based on Transaction IDs (XIDs). 3. **Visibility Rules**: - A tuple is visible if its creation XID (`t_xmin`) has committed and its deletion XID (`t_xmax`) is either zero or hasn't committed yet. - This allows readers to never block writers, and writers to never block readers. ## Storage Implications - **Bloat**: Over time, updated and deleted tuples (dead tuples) accumulate in the data files. - **Autovacuum**: A background process that reclaims the space occupied by dead tuples, making it available for new data without necessarily shrinking the file in the Frozen Pantry. - **Transaction ID Wraparound**: A critical maintenance concern where XIDs (32-bit) must be "frozen" to prevent the database from failing to distinguish between old and new transactions. ## See Also - [[Structures/Tuple|Tuple Structure]] - [[Architecture/WAL|Write-Ahead Logging]]