UUID v4 vs v7: Welche Version für deine Datenbank?

UUIDs (Universally Unique Identifiers) sind 128-Bit-Werte, die als Primärschlüssel, Trace-IDs oder Idempotency-Keys allgegenwärtig sind. Lange war v4 der Default – inzwischen verdrängt v7 ihn aus gutem Grund. Dieser Artikel zeigt warum.

UUID-Versionen im Überblick

v1 – Timestamp + MAC-Adresse. Sortierbar, aber leakt Hardware-Info. Heute selten.
v3 – Hash (MD5) eines Namens. Deterministisch, aber MD5 ist veraltet.
v4 – 122 Bit Zufall. Lange Standard.
v5 – Hash (SHA-1) eines Namens. Wie v3, aber besserer Hash.
v7 – Unix-Timestamp in Millisekunden + Zufall. Seit 2024 in RFC 9562 standardisiert.

UUID v4 – Random

v4 besteht aus 122 Bit kryptographischer Zufall plus 6 Bit für Version und Variante. Beispiel: 550e8400-e29b-41d4-a716-446655440000.

Vorteile

Trivial zu generieren, jede Sprache hat es eingebaut.
Kollisionswahrscheinlichkeit so niedrig, dass sie in der Praxis ignoriert werden kann.
Gibt keine Information preis – nicht einmal die Erzeugungsreihenfolge.

Nachteile

Das große Problem: schlechte Index-Performance. B-Tree-Indizes (PostgreSQL, MySQL/InnoDB) funktionieren am besten, wenn neue Werte ans Ende einfügen. Bei v4 fallen Inserts zufällig in den ganzen Baum, was zu "Page Splits" und schlechter Cache-Lokalität führt. Bei großen Tabellen siehst Du das in 2–10x langsameren Inserts und größeren Indizes.

UUID v7 – Time-Ordered

Die ersten 48 Bit sind ein Unix-Timestamp in Millisekunden, der Rest ist Zufall:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           unix_ts_ms                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          unix_ts_ms           |  ver  |       rand_a          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var|                        rand_b                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            rand_b                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vorteile

Sortierbar nach Erzeugungszeit – lexikografisch und binär.
B-Tree-friendly: Inserts landen am Ende, kein Splitting.
Erzeugungszeit ablesbar (zur Millisekunde) – nützlich für Debugging.
Ersetzt ULID, KSUID und Snowflake mit Standard-Konformität.

Nachteile

Erzeugungszeit ist sichtbar – kein Vorteil für Tokens oder "unraten-bare" IDs.
Bei Clock-Skew zwischen Servern kann Sortierung leicht durcheinander geraten.

Vergleich v4 vs v7

Eigenschaft	UUID v4	UUID v7
Eindeutigkeit	Sehr hoch (122 Bit Zufall)	Sehr hoch (74 Bit Zufall + Timestamp)
Sortierbar	Nein	Ja, nach Erzeugungszeit
B-Tree-Index-Performance	Schlecht (Random Inserts)	Sehr gut (Append-only)
Privacy / Unraten-barkeit	Komplett opak	Erzeugungszeit sichtbar
Kollisionsrisiko	Praktisch null	Praktisch null

Wann v4, wann v7?

Default heute: v7 – besonders für Datenbank-Primärschlüssel, Event-IDs, alles was chronologisch sortiert sinnvoll ist. Die Performance-Gewinne sind real und messbar.

v4 nimmst Du, wenn:

die ID nach außen exponiert wird und Erzeugungsreihenfolge sensibel ist (z.B. Reservierungs-IDs, Coupon-Codes),
Du keine Garantie geben willst, wann ein Datensatz angelegt wurde,
Du Token-artige Werte brauchst, die nicht ratbar sein dürfen.

Tooling und Migration

PostgreSQL 18 bringt eingebaute uuidv7()-Funktion mit.
Node.js: uuid@10+ (npm) hat uuid.v7().
Python: uuid_utils oder ab Python 3.14 nativ.
Java: java.util.UUID hat es nicht – Libraries wie uuid-creator nutzen.
Browser: crypto.randomUUID() liefert v4. Für v7 aktuell Polyfill nötig.

Mit unserem UUID-Generator kannst Du beide Varianten direkt erzeugen und vergleichen.