Wat is MVCC in PostgreSQL?

Question

Accepted Answer

**MVCC** (Multi-Version Concurrency Control) is hoe PostgreSQL gelijktijdige toegang afhandelt — in plaats van rijen voor lezen te vergrendelen, bewaart het **meerdere versies** van rijen, zodat elke transactie een consistent **snapshot** van de gegevens ziet. Het belangrijkste voordeel: **lezers blokkeren schrijvers niet, en schrijvers blokkeren lezers niet**, wat hoge gelijktijdigheid mogelijk maakt.

## Het kernidee: meerdere rijversies

```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.
```

## Het grote voordeel: geen lesvergrendelingen

```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.
```

## Hoe het werkt (vereenvoudigd)

```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 houdt transactie-ID's en rijzichtbaarheid bij, zodat elke transactie de juiste versie ziet. Dit biedt **isolatie** zonder lesvergrendelingen.

## De kostprijs: dode tuples en 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.
```

## Waarom het belangrijk is

MVCC is fundamenteel voor het begrijpen van PostgreSQL's gelijktijdige gedrag en prestaties, dus het is waardevol kennis voor effectief werken met Postgres.

De kernwaarde die MVCC biedt, is **hoge gelijktijdigheid**: door meerdere versies van rijen te behouden en elke transactie een consistent snapshot te geven, **blokkeren lezers schrijvers niet en schrijvers blokkeren lezers niet** — wat een groot voordeel is voor echte toepassingen (een langlopende rapport blokkeert geen updates, en schrijfbewerkingen blokkeren geen lezen), waardoor veel betere gelijktijdigheid mogelijk is voor lees-zware en gemengde werklasten dan op locks gebaseerde benaderingen.

Dit is waarom PostgreSQL gelijktijdige toegang zo goed afhandelt, en het begrijpen van MVCC verklaart de gelijktijdigheidskenmerken van de database (consistente snapshots, isolatie zonder lesvergrendelingen, geen dirty reads).

Belangrijk is dat het begrijpen van MVCC ook verklaart **waarom `VACUUM` belangrijk is in Postgres**: MVCC creëert verouderde rijversies ("dode tuples") wanneer rijen worden bijgewerkt en verwijderd, die zich ophopen als bloat, en `VACUUM`/`AUTOVACUUM` is het opruimingsmechanisme dat deze ruimte teruggaaft en de database gezond houdt — dus MVCC en VACUUM zijn nauw met elkaar verbonden, en het kennen van deze verbinding is belangrijk voor databaseonderhoud en prestaties (het verwaarlozen van vacuum leidt tot bloat en verminderde prestaties, een echte operationeel probleem).

Aangezien gelijktijdigheidsgedrag fundamenteel beïnvloedt hoe een database onder belasting presteert, en aangezien MVCC (Postgres's gelijktijdigheidsmodel) zowel de uitstekende lees-/schrijfgelijktijdigheid als de noodzaak van VACUUM-onderhoud verklaart, is het begrijpen van MVCC waardevol kennis voor werken met PostgreSQL — het verduidelijkt de gelijktijdigheidsvoordelen van de database en het onderhoud dat vereist is, belangrijk voor zowel het redeneren over prestaties als het correct bedrijven van Postgres, en een veel voorkomend onderwerp dat aantoont dat men begrijpt hoe Postgres gelijktijdige toegang afhandelt.