UUIDs erklärt: v4, v7 und die Wahl der richtigen Version

Aktualisiert: 28. September 2026

Eine UUID ist eine 128-Bit-Kennung, die jeder Computer selbstständig erzeugen kann, ohne zentralen Zähler – und trotzdem ist praktisch sicher, dass niemand sonst dieselbe erzeugt hat. Deshalb dienen UUIDs als Datenbankschlüssel, Dateinamen, Request-IDs und Bestellnummern. Die meisten UUIDs, die einem begegnen, sind Version 4 und bestehen aus reinem Zufall; Version 7, 2024 standardisiert, enthält zusätzlich den Erstellungszeitpunkt und entwickelt sich für Datenbanken rasch zur besseren Wahl. Dieser Ratgeber erklärt, wie man eine UUID liest, wie sich die Versionen unterscheiden, wie wahrscheinlich eine Kollision tatsächlich ist und welche Version die richtige ist.

Wie eine UUID aussieht

Eine UUID umfasst 128 Bit und wird als 32 Hexadezimalziffern in fünf durch Bindestriche getrennten Gruppen geschrieben – 8, 4, 4, 4 und 12 Ziffern, insgesamt 36 Zeichen:

3f2a9c1e-5b7d-4e8a-9c21-7d4e5f6a8b90Eine UUID der Version 4.
01a0d86f-ca00-7b3e-9f21-6c4d8a0e5b17Eine UUID der Version 7.

Der aktuelle Standard ist RFC 9562, veröffentlicht im Mai 2024; er hat RFC 4122 aus dem Jahr 2005 abgelöst. Buchstaben dürfen groß, klein oder gemischt geschrieben werden; alle drei Schreibweisen bezeichnen denselben Wert.

Datenbanken mit einem nativen UUID-Typ wie PostgreSQL speichern den Wert in 16 Byte statt als Text aus 36 Zeichen.

Die Version ablesen

Zwei Ziffern verraten, um welche Art von UUID es sich handelt. Die erste Ziffer der dritten Gruppe ist die Version. Die erste Ziffer der vierten Gruppe ist die Variante: Bei jeder standardkonform erzeugten UUID ist sie 8, 9, a oder b.

UUID	Version	Bedeutung
`3f2a9c1e-5b7d-4e8a-9c21-7d4e5f6a8b90`	4	Zufällig
`01a0d86f-ca00-7b3e-9f21-6c4d8a0e5b17`	7	Zeitlich geordnet, erzeugt am 25. September 2026 um 12:00:00 UTC
`00000000-0000-0000-0000-000000000000`	—	Die Nil-UUID: alle Bits null, steht für „kein Wert“
`ffffffff-ffff-ffff-ffff-ffffffffffff`	—	Die Max-UUID: alle Bits eins, dient als Obergrenze

Die Versionen

Version	Wie sie erzeugt wird	Einsatz heute
1	Zeitstempel und die Netzwerkadresse (MAC) des Computers	Veraltet; verrät, auf welchem Rechner sie erzeugt wurde
3	MD5-Hash aus einem Namensraum und einem Namen	Nur, um bestehende IDs nachzubilden; besser Version 5
4	122 Zufallsbits	Fast überall die Standardwahl
5	SHA-1-Hash aus einem Namensraum und einem Namen	Derselbe Name ergibt immer dieselbe UUID
6	Version 1, so umgeordnet, dass sie sich nach Zeit sortieren lässt	Nur dort, wo Version 1 bereits im Einsatz ist
7	Unix-Zeitstempel in Millisekunden plus Zufallsbits	Neue Datenbanken und alles, was von zeitlicher Ordnung profitiert
8	Aufbau wird von der Anwendung festgelegt	Experimentelle oder herstellerspezifische Formate

Version 2 existiert für ein altes Sicherheitssystem und liegt außerhalb des Geltungsbereichs des Standards. Laut RFC 9562 sollten Implementierungen nach Möglichkeit Version 7 statt der Versionen 1 und 6 verwenden.

Version 4: zufällig

Bei einer UUID der Version 4 sind 6 ihrer 128 Bit fest vorgegeben, um Version und Variante zu kennzeichnen; die übrigen 122 werden mit Zufallsdaten gefüllt. Der Standard sieht einen kryptografisch sicheren Zufallszahlengenerator vor – genau den stellen Browser über crypto.randomUUID() bereit, die Funktion, die der nTools-Generator verwendet.

Bei 122 Zufallsbits sind Kollisionen praktisch kein Thema. Eine Wahrscheinlichkeit von 50 %, dass mindestens zwei davon übereinstimmen, wird erst nach etwa 2,7 × 10¹⁸ UUIDs erreicht – bei einer Milliarde pro Sekunde dauert das rund 86 Jahre. Nach einer Billion UUIDs liegt die Wahrscheinlichkeit, dass zwei davon gleich sind, bei etwa 1 zu 10 Billionen. Das realistische Risiko ist ein fehlerhafter Zufallszahlengenerator, nicht die Mathematik.

UUID-Generator

Version 7: nach Zeit sortiert

Eine UUID der Version 7 enthält in ihren ersten 48 Bit die Unix-Zeit in Millisekunden, danach Version und Variante und schließlich 74 Bit Zufall oder einen Zähler. Weil die Zeit vorn steht, werden später erzeugte UUIDs hinter früheren einsortiert – sowohl als Text als auch als Bytes.

Im Beispiel oben stehen die ersten 12 Hexadezimalziffern, 01a0d86fca00, für 1.790.337.600.000 Millisekunden nach dem 1. Januar 1970: den 25. September 2026 um 12:00:00 UTC. Der 48-Bit-Zeitstempel reicht bis ins Jahr 10889. Innerhalb einer einzelnen Millisekunde verwenden Generatoren entweder Zufallsbits, oder sie ergänzen einen Zähler, damit UUIDs aus demselben Prozess trotzdem in der richtigen Reihenfolge entstehen.

Auch die gängigen Werkzeuge ziehen nach: PostgreSQL 18, erschienen im September 2025, hat neben uuidv4() eine eingebaute Funktion uuidv7() erhalten.

Welche Version sich als Datenbankschlüssel eignet

Die meisten Datenbanken verwalten Primärschlüssel in einem B-Baum-Index (B-Tree), der effizient bleibt, wenn neue Schlüssel in geordneter Reihenfolge hinzukommen.

Schlüssel der Version 4 landen an zufälligen Stellen im Index. Bei kleinen Tabellen spielt das keine Rolle; bei großen trifft jedes Einfügen einen anderen Teil des Index, was mehr Seitenteilungen (Page Splits), mehr Cache-Misses und größere Indizes bedeutet.
Schlüssel der Version 7 kommen in zeitlicher Reihenfolge an, sodass neue Zeilen nahe am Ende des Index angefügt werden – ähnlich wie bei einer automatisch hochgezählten Nummer –, und lassen sich trotzdem überall erzeugen, ohne die Datenbank nach dem nächsten Wert zu fragen.
Automatisch hochgezählte Ganzzahlen (Auto-Increment) sind kleiner und am schnellsten, brauchen aber einen einzigen zentralen Zähler und verraten, wie viele Datensätze es gibt und in welcher Reihenfolge sie angelegt wurden.

Für eine neue Tabelle, die UUIDs braucht, ist Version 7 meist die bessere Wahl. Version 4 bleibt die richtige, wenn der Erstellungszeitpunkt an der ID nicht erkennbar sein darf.

Was eine UUID nicht ist

Kein Geheimnis. Eine UUID der Version 7 zeigt jedem, der sie liest, auf die Millisekunde genau, wann sie erzeugt wurde. Eine UUID der Version 4 ist schwer zu erraten, aber IDs werden protokolliert, in URLs weitergegeben und in Oberflächen angezeigt. Links zum Zurücksetzen von Passwörtern oder zu privaten Dateien sollten ein eigenes Zufallstoken verwenden, nicht die ID des Datensatzes.
Keine Informationsquelle. Der Standard empfiehlt, UUIDs als opake Werte zu behandeln: Man speichert und vergleicht sie, baut aber keine Logik, die darauf beruht, ihre Bestandteile auszulesen.
Nicht immer Version 4. Code, der Zufälligkeit erwartet, sollte sie nicht einfach voraussetzen; wo es darauf ankommt, lohnt ein Blick auf die Versionsziffer.

Häufige Fragen

Können zwei zufällige UUIDs jemals gleich sein?

Theoretisch ja, praktisch nein. Damit mit 50 % Wahrscheinlichkeit auch nur eine einzige Übereinstimmung auftritt, wären rund 2,7 × 10¹⁸ UUIDs der Version 4 nötig – vorausgesetzt, sie stammen aus einem ordentlichen Zufallszahlengenerator.

Ist eine GUID dasselbe wie eine UUID?

Ja. GUID ist die Bezeichnung von Microsoft für dieselbe 128-Bit-Kennung. Windows-Werkzeuge zeigen sie oft in Großbuchstaben oder in geschweiften Klammern an, etwa {3F2A9C1E-5B7D-4E8A-9C21-7D4E5F6A8B90}, doch der Wert ist derselbe.

Unterscheiden UUIDs zwischen Groß- und Kleinschreibung?

Nein. 3F2A9C1E-… und 3f2a9c1e-… sind dieselbe UUID. Beim Vergleichen sollte die Groß- und Kleinschreibung ignoriert werden – oder man speichert die UUIDs in einer nativen UUID-Spalte, dann stellt sich die Frage gar nicht.

Welche Version erzeugt der nTools-Generator?

Version 4, über crypto.randomUUID() des Browsers. Er erzeugt bis zu 100 auf einmal, vollständig auf dem eigenen Gerät.