Che cos'è MVCC in PostgreSQL?

Question

Accepted Answer

**MVCC** (Multi-Version Concurrency Control) è il modo in cui PostgreSQL gestisce l'accesso concorrente — invece di bloccare le righe per le letture, mantiene **multiple versioni** delle righe, così ogni transazione vede uno **snapshot** consistente dei dati. Il beneficio principale: **i lettori non bloccano gli scrittori e gli scrittori non bloccano i lettori**, abilitando un'elevata concorrenza.

## L'idea fondamentale: multiple versioni delle righe

```text
When a row is UPDATED, Postgres doesn't overwrite it — it creates a NEW version and
marks the old one obsolete. Different transactions can see different versions.
→ Each transaction sees a consistent SNAPSHOT of the database as of its start
  (depending on isolation level), unaffected by others' uncommitted changes.
```

## Il grande vantaggio: nessun lock di lettura

```text
Without MVCC (lock-based): readers and writers BLOCK each other
  → a long-running report could block writes; a write could block reads.
With MVCC:
  ✓ READERS DON'T BLOCK WRITERS — a SELECT sees an old version while an UPDATE proceeds
  ✓ WRITERS DON'T BLOCK READERS
  ✓ Each transaction sees a stable, consistent view (no dirty reads)
→ Much higher concurrency for read-heavy and mixed workloads.
```

## Come funziona (semplificato)

```sql
-- Transaction A starts a long SELECT (sees a snapshot)
BEGIN; SELECT count(*) FROM orders;   -- sees data as of its snapshot

-- meanwhile Transaction B updates rows — creates new versions, doesn't block A
-- A still sees its consistent snapshot; B's changes are a new version
```

Postgres traccia gli ID delle transazioni e la visibilità delle righe così ogni transazione vede la versione corretta. Ciò fornisce **isolamento** senza lock di lettura.

## Il costo: tuple morte e VACUUM

```text
MVCC creates obsolete row versions ("dead tuples") that accumulate → bloat.
VACUUM (and AUTOVACUUM) reclaims this dead space and keeps the database healthy.
→ This is why VACUUM is important in Postgres — it's the cleanup for MVCC's versions.
```

## Perché è importante

MVCC è fondamentale per comprendere il comportamento di concorrenza e le prestazioni di PostgreSQL, quindi è una conoscenza preziosa per lavorare con Postgres efficacemente.

Il valore fondamentale che MVCC fornisce è **un'elevata concorrenza**: mantenendo multiple versioni delle righe e fornendo a ogni transazione uno snapshot consistente, **i lettori non bloccano gli scrittori e gli scrittori non bloccano i lettori** — il che è un grande vantaggio per le applicazioni reali (un rapporto long-running non blocca gli aggiornamenti, e le scritture non bloccano le letture), abilitando una concurrenza molto migliore per carichi di lavoro read-heavy e misti rispetto agli approcci basati su lock.

Ecco perché PostgreSQL gestisce l'accesso concorrente così bene, e comprendere MVCC spiega le caratteristiche di concorrenza del database (snapshot consistenti, isolamento senza lock di lettura, nessuna lettura sporca).

Crucialmente, comprendere MVCC spiega anche **perché `VACUUM` è importante in Postgres**: MVCC crea versioni di righe obsolete ("tuple morte") quando le righe vengono aggiornate e cancellate, che si accumulano come bloat, e `VACUUM`/`AUTOVACUUM` è il meccanismo di pulizia che recupera questo spazio e mantiene il database sano — quindi MVCC e VACUUM sono strettamente connessi, e conoscere questa connessione è importante per la manutenzione del database e le prestazioni (trascurare il vacuum porta a bloat e prestazioni degradate, una vera preoccupazione operativa).

Poiché il comportamento di concorrenza influenza fondamentalmente le prestazioni di un database sotto carico, e poiché MVCC (il modello di concorrenza di Postgres) spiega sia l'eccellente concorrenza lettura/scrittura che la necessità della manutenzione VACUUM, comprendere MVCC è una conoscenza preziosa per lavorare con PostgreSQL — chiarisce i vantaggi di concorrenza del database e la manutenzione che richiede, importante sia per ragionare sulle prestazioni che per operare Postgres correttamente, ed è un argomento comune che dimostra la comprensione di come Postgres gestisce l'accesso concorrente.