UUID-Generator: v1, v3, v4, v5, v7 und ULID erklärt

Eine UUID (Universally Unique Identifier) ist ein 128-Bit-Wert. Ihr Zweck: zwei Systeme können IDs unabhängig vergeben und in der Praxis trotzdem nicht kollidieren - kein zentraler Sequenzgeber, keine Koordination nötig. Die einzelnen Versionen mischen Zeitstempel, Zufall und (historisch) Hardware-Bytes unterschiedlich. Welche du nimmst, hängt davon ab, ob die ID sortierbar, deterministisch oder einfach zufällig sein soll. Der Generator unten zeigt das Layout pro Version live: welche Bytes für den Zeitstempel reserviert sind, welche für Zufall, welche für ein Knoten-Feld - und welche Eigenschaften daraus folgen. v7 und v4 nebeneinander: die Sortier-Demo zeigt in zwei Klicks, warum v7 in Datenbanken gewinnt.

Welche UUID-Version brauchst du wirklich?

Drei Fragen reichen meistens:

1. Brauchst du Sortierbarkeit? Wenn die ID Primärschlüssel in einer Datenbank wird, oder Event-IDs, oder eine URL-sichere Zeitachse - dann v7 (RFC 9562) oder ULID. Beide beginnen mit einem Zeitstempel auf Millisekunden-Auflösung; eine String-Sortierung folgt der Einfügereihenfolge auf 1 ms genau (innerhalb derselben Millisekunde regelt der Zähler oder Zufall der Implementierung den Rest).
2. Brauchst du Determinismus? Wenn dieselbe Eingabe immer dieselbe ID liefern soll - dann v3 (MD5) oder v5 (SHA-1). v5 ist die saubere Wahl.
3. Sonst: v4. Reiner Zufall aus den Crypto-APIs des Browsers, kein Zustand, kein Geräte-Leak.

v1 brauchst du eigentlich nie - außer ein Legacy-System verlangt es. Die letzten 6 Bytes einer v1-UUID sind ein 48-Bit-Knoten-Feld; je nach Implementierung steht da die MAC-Adresse des erzeugenden Geräts. Die Bibliothek hinter diesem Tool zieht zufällige Knoten-Werte, andere Stacks schreiben die echte MAC. Wer v1-IDs aus Logs oder fremden APIs weiterreicht, behandelt die letzten 6 Bytes besser als potenziell sensitiv.

Das 128-Bit-Layout pro Version

Jede Karte oben zeigt das Layout in farbigen Bändern. Die wichtigen Unterschiede:

• v1 - Zeit + Knoten. Drei Zeitstempel-Runs (time_low, time_mid, time_hi), permutiert. Ein clock_seq-Feld verhindert Kollisionen bei Uhren-Sprüngen. Die letzten 6 Bytes sind das 48-Bit-Knoten-Feld - historisch die MAC, hier zufällig generiert.
• v3 / v5 - Hash. Der Output ist der MD5- bzw. SHA-1-Hash von Namensraum + Name. Versions- und Varianten-Bits werden in den Hash hineinkopiert; der Rest sind Hash-Bytes.
• v4 - Zufall. 122 Bits crypto-Zufall. 4 Bits Version, 2 Bits Variante - das war es.
• v7 - Zeit + Zufall. 48 Bits ms-Zeitstempel am Anfang, dann 74 Bits für Zufall und/oder einen monotonen Zähler (RFC 9562 lässt die genaue Aufteilung offen). Versions- und Varianten-Bits trennen die zwei Bereiche.
• ULID - Crockford-32. 48 Bits ms-Zeitstempel + 80 Bits Zufall, dargestellt in 26 Crockford-Base32-Zeichen. Keine 0/O- oder I/L-Verwechslung.

v4 oder v7 - die Sortier-Demo unten

Die Sortier-Demo unten zieht je 10 v4 und 10 v7 UUIDs in zufälliger Reihenfolge. Klick auf "Alphabetisch sortieren" - die linke Spalte (v4) bleibt durcheinander, die rechte (v7) sortiert sich zurück in die Erzeugungsreihenfolge. Genau das passiert in einer Datenbank, wenn du eine UUID-Spalte als Primärschlüssel und Sortier-Schlüssel benutzt:

• Bei v4 schreibt jeder neue Eintrag an eine zufällige Stelle im B-Tree-Index. Die Index-Seiten fragmentieren, das I/O verteilt sich.
• Bei v7 sitzen neue Einträge praktisch immer am Ende der sortierten Folge. Die Index-Seiten bleiben dicht, das I/O bleibt sequentiell.

In MySQL- und Postgres-Benchmarks der letzten Jahre liegt der Unterschied bei großen Tabellen oft im einstelligen Faktor zugunsten von v7. ULID hat dasselbe Verhalten - nur in einer anderen Notation.

Wann sind v3 und v5 die richtige Wahl?

Wenn die ID aus etwas Stabilem abgeleitet werden soll: einer URL, einem DNS-Namen, einem Pfad, einem Datei-Inhalt. Dieselbe Eingabe → dieselbe ID, ohne dass du selbst eine Datenbank befragen musst.

v5(DNS-Namensraum, "example.com") = cfbff0d1-9375-5685-968c-48ce8b15ae17
v5(DNS-Namensraum, "example.com") = cfbff0d1-9375-5685-968c-48ce8b15ae17

Der Namensraum ist eine UUID. RFC 9562 Abschnitt 6.6 (Tabelle 3) definiert vier Standard-Namensräume - DNS, URL, OID, X.500 - die der Generator oben als Presets anbietet. Du kannst auch eine eigene UUID als Namensraum verwenden, etwa eine pro Anwendung, sodass derselbe Name in verschiedenen Anwendungen verschiedene IDs ergibt.

v5 ist v3 vorzuziehen, weil SHA-1 als Hash-Funktion robuster ist als MD5 - obwohl in dieser Anwendung keine kryptografische Sicherheit gefragt ist; es geht nur um eine gute Verteilung der Bits.

Was ist mit v6, v8 und Microsoft-GUIDs?

• v6 ist v1 mit umgeordneten Zeitstempel-Bytes - sortierbar wie v7. Das Knoten-Feld trägt dieselbe MAC-Frage wie v1: je nach Implementierung kann es die echte Adresse enthalten oder ein zufälliger Wert sein. Kaum Verbreitung; in der Praxis gewinnt v7.
• v8 ist die "Custom"-Version aus RFC 9562 für proprietäre Layouts. Wenn du sie brauchst, weißt du es; wenn nicht, brauchst du sie nicht.
• Microsoft-GUIDs sind UUIDs in einer Big-Endian/Little-Endian-Mischform. Beim Austausch zwischen .NET-Welt und allem anderen darauf achten, dass die ersten drei Felder evtl. byte-getauscht sind.

Bulk-Generierung: 1, 10, 100, 1000

Der Schalter "Wie viele?" oben zieht die gewählte Anzahl in einem Rutsch. Die Liste lässt sich dann als JavaScript-Array, CSV oder JSON kopieren - praktisch für Seed-Daten, Lasttests oder einfach um zu sehen, wie sich das Layout über viele Einträge verhält. Bei v7 rückt der ms-Zeitstempel vorne pro Eintrag um eine Millisekunde vor (damit die Demo eine deutliche Sortier-Spur hat); bei v4 sieht man die Gleichverteilung des Zufalls.

Häufige Fragen

Welche UUID-Version soll ich nehmen?

Standard ist v4 für Session-IDs und alles ohne Sortier-Bedarf. v7 für Datenbank-Primärschlüssel und Event-IDs - der Zeitstempel am Anfang macht v7 sortierbar. v3 und v5 nur, wenn du deterministische IDs aus Namen brauchst (v5 ist v3 vorzuziehen). v1 nur in Legacy-Systemen - das Knoten-Feld kann je nach Stack die MAC enthalten.

Was ist UUID v7 und warum ist sie sortierbar?

v7 (RFC 9562, 2024) beginnt mit 48 Bits ms-Zeitstempel, gefolgt von 74 Bits für Zufallsdaten und/oder einen monotonen Zähler (zwischen Versions- und Varianten-Bits aufgeteilt). Weil der Zeitstempel die ersten Bytes belegt, sortieren sich v7-UUIDs lexikographisch nach Millisekunden-Zeit; innerhalb derselben Millisekunde regelt der Zähler oder Zufall der Implementierung den Rest. In Datenbanken bedeutet das deutlich weniger Index-Fragmentierung als bei v4.

Leakt eine v1-UUID meine MAC-Adresse?

Kann sein. Die letzten 6 Bytes sind ein 48-Bit-Knoten-Feld - historisch die MAC, je nach Implementierung aber auch zufällig. Wenn du v1-IDs aus unbekannten Stacks weiterreichst, nimm lieber v4 oder v7.

Was ist der Unterschied zwischen UUID und ULID?

ULID ist kein RFC, sondern ein populäres Schema: 26 Zeichen Crockford-Base32, 48 Bits ms-Zeitstempel + 80 Bits Zufall. Lexikographisch sortierbar wie v7, URL-freundlicher und ohne Verwechslung von 0/O oder I/L.