Jede moderne Datenbank, jedes verteilte System und jede API verwendet eindeutige Bezeichner — und 2026 hat sich der Standard, der sie regelt, grundlegend geändert. Eine UUID (Universally Unique Identifier, universell eindeutiger Bezeichner) ist ein 128-Bit-Label, das Informationen rechnerübergreifend ohne jede zentrale Koordination identifizieren kann. Unter dem neuen RFC 9562 (der RFC 4122 im Mai 2024 abgelöst hat) hat sich das Bild gewandelt: UUID v4 bleibt der Standard für zufällige IDs, doch UUID v7 ist nun der empfohlene Standard für Datenbank-Primärschlüssel, da seine zeitgeordnete Struktur die Fragmentierung von B-Baum-Indizes verhindert.
Dieser Leitfaden behandelt das Gesamtbild: wie UUIDs funktionieren, welche Version wann zum Einsatz kommt und wie man sie korrekt implementiert.
RFC 9562 verstehen: Der moderne UUID-Standard
Eine UUID ist eine 128-Bit-Zahl, deren Eindeutigkeit praktisch garantiert ist — ohne zentrale Instanz. Laut Wikipedia ist die Wahrscheinlichkeit einer Kollision zweier UUID so nah an null, dass sie für reale Anwendungen als unmöglich gilt. Verschiedene Teams können Daten unabhängig kennzeichnen, in der Gewissheit, dass ihre IDs sich nicht beißen.
Im Mai 2024 veröffentlichte die IETF den RFC 9562 und schickte den alten RFC 4122 in den Ruhestand. Das Update war eine Antwort auf die Anforderungen moderner verteilter Systeme, die IDs brauchten, die sowohl eindeutig als auch zeitlich sortierbar sind. Drei neue Versionen wurden eingeführt: v6, v7 und v8.
Anatomie einer UUID: Versionen und Varianten
Eine UUID sehen Sie typischerweise als 32 hexadezimale Zeichen, die durch Bindestriche in fünf Gruppen geteilt sind (8-4-4-4-12):
550e8400-e29b-41d4-a716-446655440000
^
version
Zwei Schlüsselfelder verraten, wie die UUID erzeugt wurde:
| Feld | Position | Aussage |
|---|---|---|
| Versionsbits | Die ersten 4 Bits des 7. Bytes (erstes Zeichen der 3. Gruppe) | Welcher Algorithmus verwendet wurde (z. B. „4″ = v4, „7″ = v7) |
| Variantenbits | 9. Byte | Die UUID-Variante — RFC 9562 verwendet ein 10-Bitmuster |
Wie SnapUtils erklärt, trennen die Variantenbits moderne RFC-9562-UUIDs von älteren Apollo- oder Microsoft-Formaten.
Warum UUID v7 der neue Goldstandard für Datenbanken ist
Der größte Nachteil von UUID v4 ist, dass sie vollständig zufällig ist. Als Primärschlüssel in einem B-Baum-Index muss die Datenbank neue Zeilen an unvorhersehbaren Positionen einfügen. Laut CreateUUID verursacht dies „Seitenaufteilungen“ (page splits) — die Datenbank muss ständig Daten umorganisieren, um Platz zu schaffen, was Schreibvorgänge verlangsamt und Speicher verschwendet.
UUID v7 löst das, indem sie einen 48-Bit-Unix-Epoch-Zeitstempel (Millisekundenpräzision) an den Anfang der ID stellt. Dadurch werden die IDs monoton steigend — neue sind stets größer als alte. Die Datenbank kann einfach ans Ende des Index anfügen und bietet Ihnen die Leistung einer sequenziellen Ganzzahl bei der globalen Eindeutigkeit einer UUID.
Wie UUID v7 Zeit und Entropie ausbalanciert
UUID v7 füllt die restlichen 74 Bits mit einem CSPRNG (kryptographisch sicheren Pseudozufallszahlengenerator). Laut Wikipedia müssten Sie etwa 1 Milliarde UUIDs pro Sekunde über 85 Jahre erzeugen, um eine 50%ige Kollisionswahrscheinlichkeit zu erreichen. Für jede reale Anwendung ist UUID v7 faktisch kollisionsfrei.
Best Practices für die Speicherung: Binary(16) vs. String(36)
Wie Sie UUIDs speichern, ist genauso wichtig wie die gewählte Version:
| Speicherformat | Platz | Indexleistung | Empfehlung |
|---|---|---|---|
| Binary(16) | 16 Byte | Hoch (kompakt) | Best Practice |
| Nativer UUID-Typ | 16 Byte | Hoch (optimiert) | Optimal für PostgreSQL |
| Zeichenkette (Char 36) | 36–72 Byte | Niedrig (fragmentiert) | Vermeiden |
SnapUtils empfiehlt, stets native Typen statt Zeichenketten zu verwenden. In PostgreSQL speichert der native uuid-Typ Daten in einem kompakten 16-Byte-Binärformat und unterstützt dennoch standardmäßige zeichenkettenbasierte Abfragen.
UUID vs. GUID: Gibt es einen Unterschied?
Eine GUID (Globally Unique Identifier, global eindeutiger Bezeichner) ist Microsofts Implementierung des UUID-Standards. Historisch gab es einen Unterschied in der Byte-Reihenfolge (Endianness) — frühe Microsoft-GUIDs verwendeten Little-Endian für die ersten drei Felder, während Standard-UUIDs Big-Endian (Netzwerk-Byte-Reihenfolge) nutzten (SnapUtils).
Bis 2026 ist das meist eine reine Namenskonvention. Unter RFC 9562 funktionieren sie identisch. Ein Guid.NewGuid() in .NET ist vollständig kompatibel mit einem uuid.uuid4() in Python. „GUID“ hören Sie in Windows-/Azure-Kreisen, „UUID“ in der Linux- und Open-Source-Community.
Moderne UUIDs implementieren: Sprache für Sprache
| Sprache | UUID v4 | UUID v7 |
|---|---|---|
| Python | Eingebautes uuid-Modul |
uuid6– oder uuid7-Paket |
| JavaScript | crypto.randomUUID() |
uuid-npm-Paket (v10+) |
| PostgreSQL | gen_random_uuid() (PG 13+) |
Natives uuidv7() (PG 17+) oder Erweiterungen |
| .NET | Guid.NewGuid() |
Community-Pakete |
| Rust | uuid-Crate (v1.7+) |
uuid-Crate mit v7-Feature |
Deterministische IDs: UUID v5
Wenn Sie für eine bestimmte Eingabe (wie eine URL oder einen Benutzernamen) jedes Mal dieselbe ID brauchen, verwenden Sie UUID v5. Sie hasht eine Namensraum-UUID und einen Namensstring mit SHA-1 — ideal zur Deduplizierung, wenn Sie keine zentrale Datenbank abfragen können.
Die Datenschutzlektion von UUID v1
UUID v1 verwendet einen Zeitstempel und die MAC-Adresse des Rechners. Sie wurde weitgehend aufgegeben, weil sie Hardwareinformationen verrät. Ein berühmtes Beispiel: Der Ersteller des Melissa-Virus wurde gefasst, weil UUIDs in infizierten Word-Dokumenten seine spezifische MAC-Adresse enthielten.
Fortgeschrittenes RFC 9562: v6, v8 und spezielle UUIDs
RFC 9562 fügte spezialisierte Versionen für Nischenbedürfnisse verteilter Systeme hinzu:
| Version | Zweck | Wann verwenden |
|---|---|---|
| v6 | Neu sortierter v1-Zeitstempel — sortierbar unter Beibehaltung der v1-Präzision | Migration von Legacy-v1-Systemen |
| v8 | Benutzerdefiniert — 122 Bits für entwicklerdefinierte Daten | Experimentelle oder herstellerspezifische Schemata |
| Nil UUID | 00000000-0000-0000-0000-000000000000 |
Null-Platzhalter |
| Max UUID | FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF |
Markierung für Bereichsendpunkt |
Fazit
RFC 9562 hat eindeutige Bezeichner für das moderne Cloud-Zeitalter aktualisiert. Die praktische Empfehlung:
- Datenbank-Primärschlüssel → Verwenden Sie UUID v7 für zeitgeordnete, fragmentierungsfreie Einfügungen
- Allgemeine Zufälligkeit → UUID v4 ist weiterhin völlig in Ordnung
- Deduplizierung → UUID v5 liefert deterministische IDs
- Speicherung → Verwenden Sie immer Binary(16) oder native UUID-Typen, niemals Zeichenketten
Maßnahme: Überprüfen Sie Ihre Datenbankschemata. Wenn Sie UUID v4 als Primärschlüssel in Tabellen mit Millionen Zeilen verwenden, ist die Migration zu UUID v7 eine unkomplizierte Änderung, die die Indexfragmentierung deutlich reduzieren und Abfragen beschleunigen kann.
Häufig gestellte Fragen
Ist eine UUID dasselbe wie eine GUID?
Funktional ja. Eine GUID ist Microsofts Implementierung des UUID-Standards. Unter RFC 9562 verhalten sie sich identisch — Sie können sie über .NET-, Java- und Python-Anwendungen hinweg austauschbar verwenden.
Können zwei UUIDs jemals in einem realen Szenario kollidieren?
Mathematisch möglich, praktisch unmöglich. Bei UUID v4 müssten Sie etwa 2,71 Trillionen IDs erzeugen, um eine 50%ige Kollisionswahrscheinlichkeit zu erreichen. Laut Generate-Random.org gibt das Erzeugen von 1 Milliarde UUIDs pro Sekunde über 85 Jahre Ihnen nur eine 50%ige Chance auf eine einzige Kollision.
Sollte ich UUIDs in meiner Datenbank als Zeichenketten oder binär speichern?
Bevorzugen Sie immer Binary(16) oder den nativen UUID-Typ (in PostgreSQL verfügbar). Eine 36 Zeichen lange Zeichenkette verbraucht mehr als doppelt so viel Platz und verlangsamt Indexsuchen und Joins erheblich.SnapUtils stellt fest, dass die Leistungsvorteile von RFC 9562 maximiert werden, wenn die Speicherung kompakt bleibt.
Wann sollte ich UUID v5 statt UUID v4 verwenden?
Verwenden Sie v5, wenn Sie deterministische IDs brauchen — dieselbe Eingabe erzeugt immer dieselbe UUID, ohne eine Datenbank abzufragen. Verwenden Sie v4, wenn Sie vollständige Zufälligkeit wünschen und sicherstellen wollen, dass der Bezeichner nicht zu seiner Quelle zurückverfolgt werden kann.
