UUID v4 oder v7: was ist der Unterschied?

Die kurze Antwort

Nimm UUID v7 für neue Datenbankschlüssel, Event-IDs, Logeinträge und Dateinamen, die du in zeitlicher Reihenfolge haben willst. Neue v7-Werte sind immer größer als ältere, sie werden also wie eine fortlaufende Nummer (Auto-Increment) ans Ende eines Index angehängt. Trotzdem kannst du sie auf jedem Server oder im Browser erzeugen, ohne die Datenbank zu fragen.

Nimm UUID v4 für Tokens, öffentliche Kennungen, bei denen der Erstellungszeitpunkt privat bleiben soll, und für Systeme, die v4 schon verwenden. Ein v4-Wert verrät nichts, und bei den meisten Anwendungen ohne Millionen von Zeilen kostet seine zufällige Reihenfolge wenig. Beide Versionen sind in RFC 9562 definiert, der 2024 erschienen ist, den älteren RFC 4122 abgelöst hat und die Versionen 6, 7 und 8 eingeführt hat.

Wie eine UUID aufgebaut ist

Jede UUID hat 128 Bit und wird als 32 Hexadezimalziffern in fünf Gruppen geschrieben: 8-4-4-4-12, zusammen mit den Bindestrichen 36 Zeichen. Zwei Felder sind bei jeder modernen UUID festgelegt. Die erste Ziffer der dritten Gruppe ist die Version, die du also auf einen Blick erkennst: 4 für zufällig, 7 für Unix-Zeit. Die erste Ziffer der vierten Gruppe ist die Variante und bei Standard-UUIDs immer 8, 9, a oder b.

Beispiel v4: 9b2f4c1e-3a7d-4e8b-a5c2-0f6d1e9a3b47. Beispiel v7: 019a2b3c-4d5e-7f60-8a1b-2c3d4e5f6a7b. Beim v7-Beispiel sind die ersten 12 Hexziffern (019a2b3c4d5e) der Erstellungszeitpunkt in Millisekunden. Deshalb haben IDs, die eine Sekunde auseinander liegen, fast denselben Anfang.

Warum v7 als Primärschlüssel schneller ist

Die meisten Datenbanken speichern den Primärschlüssel in einem B-Baum-Index, sortiert nach dem Schlüssel. Mit zufälligen v4-Schlüsseln landet jedes Insert an einer zufälligen Stelle in diesem Baum. Sobald der Index größer ist als der Arbeitsspeicher, müssen bei Inserts ständig alte Seiten von der Platte gelesen werden, Seiten werden halb voll geteilt, und der Index wird größer als nötig. Bei InnoDB (MySQL und MariaDB) ist die Tabelle selbst nach Primärschlüssel geordnet gespeichert, dann leidet also die ganze Tabelle, nicht nur der Index.

Mit v7-Schlüsseln landen neue Zeilen am rechten Rand des Index, die häufig genutzten Seiten bleiben im Speicher, und die Seiten werden vollständig gefüllt. Benchmarks von Datenbankherstellern und Nutzern zeigen bei großen Tabellen meist spürbar schnellere Inserts und kleinere Indizes als mit v4; wie groß der Gewinn ist, hängt von Engine, Zeilengröße und Hardware ab. Bereichsabfragen wie die neuesten 100 Bestellungen werden ebenfalls günstiger, weil neue Zeilen nebeneinander liegen.

Speichere UUIDs in einem nativen 16-Byte-Typ, wo es einen gibt (uuid in PostgreSQL, BINARY(16) in MySQL, uniqueidentifier in SQL Server), statt als Text mit 36 Zeichen. Textschlüssel sind mehr als doppelt so groß und langsamer beim Vergleichen.

Hinweise für PostgreSQL, MySQL, SQL Server und .NET

• PostgreSQL: Der Typ uuid sortiert Byte für Byte, die Reihenfolge von v7 bleibt also erhalten. PostgreSQL 18 hat eine eingebaute Funktion uuidv7() bekommen; ältere Versionen können den Wert von der Anwendung erhalten.
• MySQL und MariaDB: als BINARY(16) mit UUID_TO_BIN(wert) ohne das Swap-Flag speichern, so bleibt die v7-Reihenfolge erhalten. Die MySQL-eigene Funktion UUID() erzeugt Version 1, nicht v7.
• SQL Server: uniqueidentifier vergleicht die letzte Bytegruppe zuerst, v7-Werte werden dort also nicht in zeitlicher Reihenfolge gespeichert. Wenn du in SQL Server fortlaufende Schlüssel brauchst, sind NEWSEQUENTIALID() oder eine bigint-Identity oft die einfachere Wahl.
• .NET: Guid.NewGuid() liefert v4. Seit .NET 9 liefert Guid.CreateVersion7() eine v7.
• JavaScript: crypto.randomUUID() liefert in Browsern und Node.js eine v4; für v7 brauchst du eine Bibliothek oder eine kleine Funktion wie die hinter dem Generator auf dieser Seite.

Kollisionsrisiko in echten Zahlen

Mit 122 Zufallsbits ist eine v4-Kollision ein Geburtstagsproblem. Du bräuchtest etwa 2,7 Trillionen (2,7 x 10^18) UUIDs für eine Wahrscheinlichkeit von 50 Prozent auf ein einziges Duplikat. Das entspricht einer Milliarde neuer IDs pro Sekunde, etwa 86 Jahre lang. Fehlerhafte Zufallsgeneratoren, kopierte Snapshots virtueller Maschinen und Bugs, die einen Wert wiederverwenden, sind als Ursache für Duplikate weit realistischer als der Zufall.

Ein v7-Wert hat weniger Zufallsbits, aber sie müssen nur innerhalb derselben Millisekunde eindeutig sein. Selbst ein Dienst, der eine Million IDs in einer Millisekunde erzeugt, ist praktisch nicht in Gefahr. Generatoren führen außerdem innerhalb der Millisekunde einen Zähler, wie dieser hier, damit auch IDs aus einem schnellen Stapel streng geordnet bleiben.

Setz trotzdem immer einen Unique Constraint auf die Spalte. Das kostet nichts und macht aus einem praktisch unmöglichen Ereignis einen klaren Fehler statt kaputter Daten.

UUID oder GUID und die anderen Versionen

GUID (Globally Unique Identifier) ist der Name, den Microsoft für eine UUID verwendet. Es ist derselbe 128-Bit-Wert; Windows-Tools schreiben ihn meist in Großbuchstaben und manchmal in geschweiften Klammern, etwa {3F2504E0-4F89-41D3-9A0C-0305E82C3301}. Die Formatoptionen im Generator (Großbuchstaben, Bindestriche, Klammern { }) decken diese Schreibweisen ab.

Version 1 kombiniert einen Zeitstempel mit der Adresse der Netzwerkkarte und wird heute kaum noch empfohlen, weil sie den Rechner identifizieren kann. Version 6 ist Version 1, umsortiert, damit sie nach Zeit sortiert. Die Versionen 3 und 5 werden mit MD5 oder SHA-1 aus einem Namen abgeleitet, dieselbe Eingabe ergibt also immer dieselbe UUID. Version 8 ist frei für eigene Aufbauten. ULID ist ein beliebtes Format außerhalb des UUID-Standards mit derselben Idee wie v7, aber v7 passt in jede vorhandene uuid-Spalte.

Wann v7 die falsche Wahl ist

• Öffentliche IDs, bei denen der Erstellungszeitpunkt heikel ist: Eine v7 in einer URL verrät, wann ein Konto, eine Bestellung oder ein Dokument angelegt wurde.
• Tokens, Einladungslinks und Codes zum Zurücksetzen von Passwörtern: Nimm v4 oder ein längeres zufälliges Token, nie etwas, das sich über die Zeit erraten lässt.
• Systeme, die IDs als Text oder mit anderer Bytereihenfolge sortieren oder vergleichen, wie uniqueidentifier in SQL Server.
• Bestehende Tabellen voller v4-Schlüssel: Versionen zu mischen funktioniert, aber den Vorteil beim Index hast du nur für neue Zeilen.