Was ist eine UUID?
Eine UUID ist ein 128 Bit langer Bezeichner, der so konstruiert ist, dass er ohne zentrale Koordination eindeutig bleibt. Genau darin liegt der praktische Wert: ein Mobilgerät im Flugmodus, ein Hintergrundjob und eine Datenbank können gleichzeitig Bezeichner erzeugen, ohne sich abzustimmen.
In Textform besteht eine UUID aus 32 Hexadezimalziffern in fünf Gruppen, getrennt durch Bindestriche: 550e8400-e29b-41d4-a716-446655440000. Die erste Ziffer der dritten Gruppe gibt die Version an, hier also eine 4.
Aufbau und Struktur
Die 128 Bit sind nicht frei belegbar. Vier Bit kodieren die Version, zwei Bit die Variante (bei RFC-UUIDs immer 10). Die übrigen 122 Bit tragen die eigentliche Information: bei v4 reinen Zufall, bei v1, v6 und v7 einen Zeitstempel plus Zufallsanteil.
Deshalb erkennt man Version und Variante direkt an der Zeichenkette, ohne die UUID zu dekodieren. Eine UUID, deren dritte Gruppe mit 7 beginnt und deren vierte Gruppe mit 8, 9, a oder b anfängt, ist eine gültige v7.
Die Versionen im Überblick
v1 verbindet einen 60-Bit-Zeitstempel mit einer Knotenkennung. Ursprünglich war das die MAC-Adresse, was die Herkunft verrät; dieser Generator verwendet stattdessen sechs zufällige Bytes.
v4 besteht aus 122 Bit kryptografischem Zufall. Keine Struktur, keine Metadaten, kein Rückschluss auf Entstehungszeit oder erzeugendes System.
v6 ist v1 mit umsortiertem Zeitstempel: das höchstwertige Segment steht vorn, wodurch die Textform chronologisch sortierbar wird.
v7 stellt einen 48-Bit-Unix-Zeitstempel in Millisekunden voran und füllt den Rest mit Zufall. Das ist die empfohlene Wahl für neue Systeme, in denen Bezeichner in einer Datenbank landen.
Warum UUIDs in verteilten Systemen unverzichtbar sind
Ein AUTO_INCREMENT-Schlüssel setzt voraus, dass genau eine Instanz die Vergabe kontrolliert. Sobald mehrere Regionen schreiben, Daten offline erfasst werden oder Datensätze zwischen Systemen wandern, wird diese Annahme zum Engpass.
Mit UUIDs kennt der Client den Schlüssel bereits, bevor er schreibt. Das erlaubt idempotente Requests, Offline-Erfassung mit späterer Synchronisation und das Zusammenführen von Datenbeständen ohne Schlüsselkonflikte.
UUID, ULID, NanoID und GUID im Vergleich
UUID ist standardisiert und praktisch überall nativ unterstützt. ULID kodiert dieselben 128 Bit in 26 Crockford-Base32-Zeichen, ist damit kürzer und ebenfalls sortierbar, aber nicht durch ein RFC abgedeckt. NanoID ist mit 21 Zeichen am kompaktesten und bewusst nicht sortierbar. GUID ist Microsofts Schreibweise für dieselbe Sache, meist in Großbuchstaben und geschweiften Klammern.
Wenn die Bezeichner in einer Datenbank indexiert werden, ist die Sortierbarkeit das entscheidende Kriterium; steht Kürze in URLs im Vordergrund, gewinnt NanoID.
UUIDs effizient speichern
Ein häufiger Fehler ist die Ablage als VARCHAR(36). Das belegt 36 Byte statt 16 und verlangsamt jeden Indexvergleich. Nutzen Sie die nativen Typen: UUID in PostgreSQL, BINARY(16) in MySQL, UNIQUEIDENTIFIER in SQL Server.
Der Unterschied ist messbar: binäre Speicherung ist rund 56 % kleiner, und kleinere Indizes bedeuten mehr Einträge pro Datenseite und damit weniger I/O.
Die Standards: RFC 4122 und RFC 9562
RFC 4122 definierte 1:1 die Versionen 1 bis 5. RFC 9562 hat ihn 2024 ersetzt und die Versionen 6, 7 und 8 ergänzt - eine Reaktion darauf, dass rein zufällige Bezeichner als Datenbankschlüssel messbare Nachteile haben. Beide Dokumente sind frei verfügbar, und dieser Generator hält sich in der Bitbelegung exakt an sie.