Vad är MVCC i PostgreSQL?

Question

Accepted Answer

**MVCC** (Multi-Version Concurrency Control) är hur PostgreSQL hanterar samtidig åtkomst — istället för att låsa rader för läsningar, behåller det **flera versioner** av rader, så varje transaktion ser en konsistent **ögonblicksbild** av data. Huvudfördelan: **läsare blockerar inte skrivare, och skrivare blockerar inte läsare**, vilket möjliggör hög samtidighet.

## Grundidén: flera radversioner

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

## Huvudfördelar: inga läslås

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

## Hur det fungerar (förenklat)

```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 spårar transaktions-ID:n och radsynlighet så att varje transaktion ser rätt version. Detta ger **isolering** utan läslås.

## Kostnaden: döda tupler och 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.
```

## Varför det spelar roll

MVCC är grundläggande för att förstå PostgreSQL:s samtidighetsbeteende och prestanda, så det är värdefull kunskap för att arbeta effektivt med Postgres.

Huvudvärdet som MVCC ger är **hög samtidighet**: genom att behålla flera versioner av rader och ge varje transaktion en konsistent ögonblicksbild, **blockerar läsare inte skrivare och skrivare blockerar inte läsare** — vilket är en stor fördel för verkliga applikationer (en långkörande rapport blockerar inte uppdateringar, och skrivningar blockerar inte läsningar), vilket möjliggör mycket bättre samtidighet för läs-tunga och blandade arbetsbelastningar än låsbaserade metoder.

Detta är anledningen till att PostgreSQL hanterar samtidig åtkomst så väl, och att förstå MVCC förklarar databasens samtidighetsegenskaper (konsekventa ögonblicksbilder, isolering utan läslås, inga dirty reads).

Viktigast är att att förstå MVCC också förklarar **varför `VACUUM` är viktigt i Postgres**: MVCC skapar föråldrade radversioner ("döda tupler") när rader uppdateras och raderas, som ackumuleras som slöseri, och `VACUUM`/`AUTOVACUUM` är rengöringsmekanismen som återtar detta utrymme och håller databasen frisk — så MVCC och VACUUM är intimt förbundna, och att veta om denna koppling är viktigt för databasunderhåll och prestanda (att försumma vacuum leder till slöseri och försämrad prestanda, en verklig operativ angelägenhet).

Eftersom samtidighetsbeteende fundamentalt påverkar hur en databas presterar under belastning, och eftersom MVCC (Postgres samtidighetsmodell) förklarar både den utmärkta läs/skriv-samtidigheten och behovet av VACUUM-underhåll, är det värdefull kunskap att förstå MVCC för att arbeta med PostgreSQL — det klargör databasens samtidighetsfördelar och det underhåll den kräver, viktigt både för att resonera om prestanda och för att driva Postgres korrekt, och är ett vanligt ämne som visar förståelse för hur Postgres hanterar samtidig åtkomst.