Hva er MVCC i PostgreSQL?

Question

Accepted Answer

**MVCC** (Multi-Version Concurrency Control) er hvordan PostgreSQL håndterer samtidig tilgang — i stedet for å låse rader for lesinger, beholder det **flere versjoner** av rader, slik at hver transaksjon ser et konsistent **snapshot** av dataene. Hovedfordelen: **lesere blokkerer ikke skrivere, og skrivere blokkerer ikke lesere**, noe som muliggjør høy samtidighet.

## Kjerneideén: flere radversjoner

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

## Hovedfordelen: ingen leselåser

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

## Hvordan det fungerer (forenklet)

```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 sporer transaksjon-IDer og radsynlighet slik at hver transaksjon ser den korrekte versjonen. Dette gir **isolasjon** uten leselåser.

## Kostnaden: døde tupler og 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.
```

## Hvorfor det betyr noe

MVCC er fundamental for å forstå PostgreSQLs samtidighetsatferd og ytelse, så det er verdifull kunnskap for å arbeide med Postgres effektivt.

Kjernverdien som MVCC gir, er **høy samtidighet**: ved å beholde flere versjoner av rader og gi hver transaksjon et konsistent snapshot, **blokkerer lesere ikke skrivere og skrivere blokkerer ikke lesere** — noe som er en stor fordel for virkelige applikasjoner (en langvarig rapport blokkerer ikke oppdateringer, og skrivinger blokkerer ikke lesinger), noe som muliggjør mye bedre samtidighet for lese-tunge og blandet arbeidsbelastning enn låsebaserte tilnærminger.

Dette er grunnen til at PostgreSQL håndterer samtidig tilgang så godt, og forståelse av MVCC forklarer databasens samtidighetskarakteristikker (konsistente snapshots, isolasjon uten leselåser, ingen dirty reads).

Krucielt er det at forståelse av MVCC også forklarer **hvorfor `VACUUM` er viktig i Postgres**: MVCC skaper foreldede radversjoner ("døde tupler") ettersom rader oppdateres og slettes, som akkumuleres som bloat, og `VACUUM`/`AUTOVACUUM` er opprydningsmekanismen som frigjør denne plassen og holder databasen sunt — så MVCC og VACUUM er intimt forbundet, og å kjenne denne forbindelsen er viktig for databasevedlikehold og ytelse (å neglisjere vacuum fører til bloat og forverret ytelse, en reell driftsbetingelse).

Siden samtidighetsatferd i grunnlaget påvirker hvordan en database utfører seg under belastning, og siden MVCC (Postgres sin samtidighetsmodell) forklarer både utmerket lese-/skrive-samtidighet og behovet for VACUUM-vedlikehold, er forståelse av MVCC verdifull kunnskap for å arbeide med PostgreSQL — det avklarer databasens samtidighetsfordeler og vedlikeholdet det krever, viktig både for å resonnere om ytelse og for å drifte Postgres korrekt, og et vanlig tema som demonstrerer forståelse av hvordan Postgres håndterer samtidig tilgang.