UUID v4 vs. v7: für Datenbankschlüssel v7 wählen

Kurz gesagt. UUID v4 sind 122 Bit reiner Zufall und unsortierbar, was die B-Baum-Index-Leistung zerstört, wenn es als Datenbankschlüssel genutzt wird. UUID v7 (RFC 9562, 2024) stellt einen 48-Bit-Unix-Millisekunden- Zeitstempel voran, sodass die IDs nach Erstellzeit sortieren. Nutzen Sie v7 für Datenbankschlüssel und Event-IDs; bleiben Sie bei v4 für undurchsichtige Sitzungstokens.

UUIDs sind 128-Bit-Identifikatoren, die ohne Koordination systemübergreifend global eindeutig sein sollen. Die ursprüngliche Spezifikation (RFC 4122, 2005) definierte fünf Versionen; v4 (rein zufällig) war die einzige, die die meisten Entwickler nutzten. RFC 9562 (2024) fügte v7 hinzu, und v7 sollte der neue Standard für fast jeden Anwendungsfall sein, bei dem zuvor v4 gewählt wurde.

Die wichtigsten Unterschiede

Warum v4 Datenbanken schadet

Datenbank-Primärschlüssel liegen typischerweise in einem B-Baum-Index. B-Bäume arbeiten am besten, wenn Inserts in sortierter Reihenfolge eintreffen: neue Schlüssel hängen sich an das rechteste Blatt an, kein Rebalancing nötig, die Indexseite bleibt warm im Cache.

Zufällige Schlüssel (v4) zerstören all das. Jeder Insert landet in einer zufälligen Seite, verursacht potenziell eine Seitenteilung, garantiert Cache-Misses und erzeugt über den Index verstreuten freien Speicher, der nie kompaktiert wird. Bei schreibintensiven Lasten zeigt sich das als:

• 10- bis 100-fach höhere I/O als bei sequentiellen Schlüsseln bei gleicher Schreibrate
• aufgeblähte Indexdateien (oft 2- bis 3-fach größer als mit sortierten Schlüsseln)
• Abfrageverlangsamungen, wenn die Cache-Trefferquote sinkt

Die Postgres-vs.-MySQL-Benchmarks, die UUID v4 mit Bigint-Primärschlüsseln vergleichen, zeigen bei repräsentativen Lasten durchweg einen 2- bis 5-fachen Unterschied im Schreibdurchsatz. Die Lösung ist nicht, UUIDs aufzugeben – sondern die Art von UUID zu nutzen, die sortiert.

Wie v7 aussieht

Eine v7-UUID:

01950d29-4f6f-7234-bf01-a8b3c0d9e102
└─────timestamp_ms──────┘     └──random──┘

Erste 48 Bit: Unix-Zeitstempel in Millisekunden (also gut bis ~10889 n. Chr.). Nächste 4 Bit: Version (immer 7). Nächste 12 Bit: Zufall. Dann 2 Bit Variantenmarker + 62 Bit Zufall. Gesamtzufall: 74 Bit – komfortabel kollisionsresistent.

Zwei v7-UUIDs, die in derselben Millisekunde erstellt werden, konkurrieren um die 74 Bit Zufall; die Kollisionswahrscheinlichkeit innerhalb dieser Millisekunde liegt für ein System mit einer Milliarde IDs bei etwa 10⁻²². Über Millisekunden hinweg macht der Zeitstempel Kollisionen strukturell unmöglich.

Wann v4 noch die richtige Wahl ist

• Undurchsichtige Sitzungstokens, bei denen die Erstellreihenfolge nicht durchsickern soll. v7 verrät Erstellzeitstempel im Millisekundenbereich im Präfix, was für Datenbankschlüssel in Ordnung, für datenschutzsensible Tokens aber schlecht ist.
• API-Schlüssel, Zugriffstokens, Passwort-Reset-Tokens: Undurchsichtigkeit zählt mehr als Sortierbarkeit.
• Anonymisierungs-Identifikatoren: wo das Beobachten des Zeitstempels einem Angreifer beim Korrelieren helfen würde.

Wann v7 klar besser ist

• Datenbank-Primärschlüssel.
• IDs in verteilten Systemen (Event-IDs, Order-IDs, Trace-IDs).
• Überall, wo Sie davon profitieren, per ORDER BY id kostenlos chronologische Reihenfolge zu erhalten.
• Überall, wo Bereichsabfragen auf die Erstellzeit sonst einen separaten Index auf created_at bräuchten.

Der Migrationspfad

Neue Tabellen: von Anfang an v7 nutzen. Alte Tabellen: meist nicht wert zu migrieren, aber wenn Sie bei einer UUID-geschlüsselten Tabelle an Schreibdurchsatz-Obergrenzen stoßen, ist der Wechsel zu v7 eine lohnende strukturelle Änderung.

Erzeugen Sie beides über unseren UUID-Generator, der beide Versionen unterstützt.

Zahlenfakten

• Zeichenkettenlänge: beide sind 36 Zeichen mit Bindestrichen (32 Hex + 4 Bindestriche), 32 Zeichen ohne Bindestriche, 22 Zeichen in base64url, 16 rohe Bytes.
• Entropie: v4 hat 122 Zufallsbits (6 Bit von Versions- + Variantenmarkern verbraucht); v7 hat 74 Zufallsbits nach dem 48-Bit-Zeitstempel.
• v4-Kollisionsmathematik: 50 % Kollisionswahrscheinlichkeit nach dem Erzeugen von ~2⁶¹ ≈ 2,3 × 10¹⁸ UUIDs – erzeugen Sie eine Milliarde pro Sekunde, müssten Sie ~85 Jahre warten.
• v7-Zeitstempelbereich: das 48-Bit-Unix-Millisekundenfeld deckt Jahr 1970 bis Jahr 10889 ab.
• Postgres-B-Baum-Benchmark (Percona, 2023): ~7.000 Inserts/s mit v4 gegenüber ~28.000 Inserts/s mit v7/ULID auf gleicher Hardware und gleichem Schema – eine 4×-Lücke, die sich ausweitet, wenn der Index über den RAM hinauswächst.
• Index-Bloat: eine v4-geschlüsselte Tabelle mit 100 Mio. Zeilen landet auf der Festplatte üblicherweise 2- bis 3-fach größer als dieselben Daten mit v7 oder einem sequentiellen Bigint, wegen des nach Seitenteilungen verbleibenden freien Speichers.
• Erzeugungsgeschwindigkeit: crypto.randomUUID() (v4) läuft mit ~3 Mio. Ops/s in Node 20; v7-Implementierungen (uuid v9, ULID) erreichen ~2,5 Mio. Ops/s.

Entscheidungsmatrix

Quellen

• RFC 9562 – Universally Unique IDentifiers (UUIDs), Mai 2024 – rfc-editor.org/rfc/rfc9562 (definiert v6, v7, v8; ersetzt RFC 4122).
• Percona Blog – UUIDs in Databases: A Deep Dive, Benchmarks v4 vs. sequentielle Schlüssel – percona.com.