UUIDs sind das erste Werkzeug, zu dem die meisten Backend-Entwickler greifen, wenn sie einen eindeutigen Bezeichner brauchen, der nicht an eine Datenbanksequenz gebunden ist. In fast jeder Sprache eingebaut, in URLs präsentabel, und funktioniert ohne Abstimmung zwischen Services. Doch die UUID-Spezifikation kennt mehrere Versionen mit unterschiedlichen Kompromissen — die Wahl der richtigen zählt in großen Systemen.

Was eine UUID ist

Eine UUID (Universally Unique Identifier, unter Windows auch GUID) ist ein 128-Bit-Wert, typisch als 32 Hex-Ziffern in den Gruppen 8-4-4-4-12 geschrieben. Die vier Hex-Zeichen an Position 13–16 kodieren die Version (1 bis 7); das erste Zeichen der Gruppe 17–20 kodiert die Variante. Alles andere sind Daten, deren Bedeutung von der Version abhängt.

Version 1: Zeit und MAC

v1 kodiert den aktuellen Zeitstempel (100-Nanosekunden-Intervalle seit 15. Oktober 1582) plus die MAC-Adresse des Hosts plus eine Taktsequenz. Garantiert eindeutig ohne Abstimmung — leakt aber, wann und wo jede ID erzeugt wurde, meist unerwünscht. Viele Enterprise-Datenbanken erzeugen v1 noch aus Gewohnheit.

Version 4: rein zufällig

v4 füllt 122 der 128 Bits mit Daten aus einem kryptografischen RNG. Die anderen 6 Bits sind fest, um v4 zu kennzeichnen. Standard in modernen Systemen, weil er nichts preisgibt, einfach zu erzeugen ist (eine Zeile, sofern crypto.randomUUID verfügbar) und eine praktisch bedeutungslose Kollisionswahrscheinlichkeit hat.

Version 7: zeitsortiert

v7 ist neu (RFC 9562, 2024 veröffentlicht). Beginnt mit einem Millisekunden-Zeitstempel und füllt den Rest mit Zufall. Ergebnis: monoton sortierbar — praktisch als Datenbank-Primärschlüssel, weil v4 Indexe schrecklich fragmentiert, während v7 Inserts zusammenhält. Wenn Ihre Datenbank-Bibliothek es unterstützt, bevorzugen Sie v7 statt v4 für Primärschlüssel; v4 nur dann, wenn Sie den Erstellungszeitpunkt verbergen müssen.

Kollisionswahrscheinlichkeit

Bei v4 ist der Raum 2^122 — etwa 5 × 10^36. Eine Milliarde UUIDs pro Sekunde über 85 Jahre ergibt immer noch eine vernachlässigbare Kollisionschance. Praktisch entstehen v4-Kollisionen durch schlechte RNGs, nicht durch erschöpften Raum. Immer crypto.randomUUID oder crypto.getRandomValues nutzen, niemals Math.random.

UUID vs. Auto-Increment

Auto-Increment-IDs sind kleiner (8 Byte vs. 16), von Natur aus sortiert, schnell indizierbar — leaken aber Geschäftsdaten („wie viele Bestellungen täglich"), erfordern Koordination in verteilten Systemen und erschweren Cross-Database-Merges. UUIDs sind das Gegenteil: opak, koordinierungsfrei, groß. Auto-Increment für interne Tabellen, aus denen keine ID die Datenbank verlässt. UUIDs für alles, was Nutzer sehen oder zwischen Services fliegt.

Speicherhinweise

UUIDs immer als nativen Binärtyp speichern, wenn die DB das unterstützt (UUID in Postgres, BINARY(16) in MySQL). Als VARCHAR(36) gespeichert verdoppelt sich der Platz und jeder Index-Lookup wird 2–3× langsamer. Die Hex-mit-Bindestrich-Form ist nur für die Anzeige.