Qu'est-ce que MVCC dans PostgreSQL ?

Question

Accepted Answer

**MVCC** (Multi-Version Concurrency Control) est la façon dont PostgreSQL gère l'accès concurrent — au lieu de verrouiller les lignes pour les lectures, il conserve **plusieurs versions** des lignes, de sorte que chaque transaction voit un **snapshot** cohérent des données. L'avantage clé : **les lecteurs ne bloquent pas les rédacteurs, et les rédacteurs ne bloquent pas les lecteurs**, ce qui permet une haute concurrence.

## L'idée fondamentale : plusieurs versions de lignes

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

## Le grand avantage : pas de verrous de lecture

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

## Comment ça marche (simplifié)

```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 suit les identifiants de transaction et la visibilité des lignes de sorte que chaque transaction voit la bonne version. Cela fournit **l'isolation** sans verrous de lecture.

## Le coût : les tuples morts et 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.
```

## Pourquoi c'est important

MVCC est fondamental pour comprendre le comportement de concurrence et les performances de PostgreSQL, ce qui rend cette connaissance précieuse pour travailler efficacement avec Postgres.

La valeur fondamentale que MVCC fournit est la **haute concurrence** : en conservant plusieurs versions des lignes et en donnant à chaque transaction un snapshot cohérent, **les lecteurs ne bloquent pas les rédacteurs et les rédacteurs ne bloquent pas les lecteurs** — ce qui est un avantage majeur pour les applications réelles (un rapport de longue durée ne bloque pas les mises à jour, et les écritures ne bloquent pas les lectures), ce qui permet une bien meilleure concurrence pour les charges de travail mixtes et gourmandes en lectures que les approches basées sur les verrous.

C'est pourquoi PostgreSQL gère si bien l'accès concurrent, et comprendre MVCC explique les caractéristiques de concurrence de la base de données (snapshots cohérents, isolation sans verrous de lecture, pas de lectures sales).

Crucially, understanding MVCC also explains **why `VACUUM` is important in Postgres**: MVCC creates obsolete row versions ("dead tuples") as rows are updated and deleted, which accumulate as bloat, and `VACUUM`/`AUTOVACUUM` is the cleanup mechanism that reclaims this space and keeps the database healthy — so MVCC and VACUUM are intimately connected, and knowing this connection is important for database maintenance and performance (neglecting vacuum leads to bloat and degraded performance, a real operational concern).

Since concurrency behavior fundamentally affects how a database performs under load, and since MVCC (Postgres's concurrency model) explains both the excellent read/write concurrency and the need for VACUUM maintenance, understanding MVCC is valuable knowledge for working with PostgreSQL — it clarifies the database's concurrency advantages and the maintenance it requires, important for both reasoning about performance and operating Postgres correctly, and a common topic that demonstrates understanding of how Postgres handles concurrent access.