UUID v7 Generator 2026

Aufbau einer UUID v7

Die ersten 48 Bits sind ein Unix-Timestamp in Millisekunden. Danach folgen 4 Bits Version (0111 fuer v7), 12 Bits Zufall, 2 Bits Variant und 62 weitere Zufallsbits. Insgesamt also 48 Bit Zeit und 74 Bit Zufall.

Vorteil bei Datenbank-Inserts

B-Tree-Indices speichern Eintraege sortiert. Bei v4-UUIDs landet jeder neue Insert in einer zufaelligen Page, was Page-Splits und I/O verursacht. v7-UUIDs werden immer am Ende eingefuegt — wie Auto-Increment-IDs, nur ohne zentrale Sequenz.

Wann nicht v7?

Wenn der Erstellungszeitpunkt geheim bleiben muss — etwa bei Einladungs-Tokens oder Zugangsschluesseln. Auch bei verteilten Systemen ohne synchronisierte Uhren kann die Sortierung brechen.

Migration von v4

Neue Tabellen direkt mit v7 anlegen. Bestehende Systeme koennen waehrend einer Uebergangszeit beide Versionen akzeptieren — das Format ist identisch, nur die Sortierung aendert sich.

Datenschutz

Reine Client-Side-Generierung. Weder Timestamp noch Zufallsdaten verlassen den Browser.

Häufige Fragen

v7 codiert in den ersten 48 Bits einen Unix-Timestamp in Millisekunden, die restlichen 74 Bits (plus 6 Bits Version und Variant) sind zufaellig. Dadurch sind v7-UUIDs zeitlich sortierbar — ein grosser Vorteil fuer Datenbank-Indices.

v7 ist Teil von RFC 9562, der 2024 RFC 4122 ersetzt hat. Moderne Bibliotheken in Postgres, Go, Rust und JavaScript unterstuetzen den Standard.

Innerhalb einer Millisekunde stehen 74 Zufallsbits zur Verfuegung — selbst bei Milliarden generierten IDs pro ms liegt die Kollisionswahrscheinlichkeit bei praktisch null.

Ja, der Erzeugungszeitpunkt ist auf die Millisekunde genau rekonstruierbar. Fuer Tokens, die nicht verraten duerfen, wann sie erstellt wurden, besser v4 oder NanoID verwenden.

Sehr gut. Weil aufeinanderfolgende IDs benachbart sind, vermeidet der B-Tree-Index Page-Splits — Inserts sind deutlich schneller als mit v4.

UUID v7 Generator