15 Jahre lang war UUID v4 die einzige Antwort. Zufällige 128-Bit-Identifikatoren, in Ihrem Browser generiert, in eine Datenbankspalte kopiert und überall verwendet. Es funktionierte. Dann im Jahr 2024 standardisierte RFC 9562 v7, und das Gespräch veränderte sich.
Die kurze Version: Verwenden Sie v7 für neue Datenbank-Primärschlüssel, verwenden Sie v4 für Sicherheitstoken und Session-IDs. Darunter folgt das Warum.
Was ein UUID tatsächlich ist
Ein UUID ist ein 128-Bit-Identifikator, normalerweise als 32 Hex-Zeichen geschrieben, getrennt durch Bindestriche: 550e8400-e29b-41d4-a716-446655440000. Die Bindestriche sind kosmetisch; die Bytes zählen. Die 128 Bits geben Ihnen 2¹²⁸ mögliche Werte — etwa 340 Undezillionen. Ihnen werden nicht die Werte ausgehen.
Die Versionsnummer (die erste Ziffer nach dem zweiten Bindestrich — 4 in 550e8400-e29b-**4**1d4-a716-446655440000) sagt Ihnen, wie das UUID generiert wurde. Das ist der wichtige Teil.
UUID v4: rein zufällig
UUID v4 ist das, was die meisten meinen, wenn sie “UUID” sagen. 122 der 128 Bits sind zufällig, die anderen 6 kodieren Version und Variante. Der Zufall ist der ganze Punkt — kein Muster zum Ausnutzen, keine Möglichkeit, die nächste ID zu raten, keine Zeitkorrelation.
Generieren Sie eines in jedem modernen Browser:
crypto.randomUUID() // → "550e8400-e29b-41d4-a716-446655440000"Es ist wunderschön einfach. Es ist auch, wie sich herausstellt, furchtbar für Datenbanken.
Das Problem ist die B-Tree-Indexierung. Ein B-Tree ist die Datenstruktur hinter den meisten Indizes (Postgres, MySQL, SQLite, MongoDB). Er hält Daten sortiert, damit Bereichsanfragen schnell sind und Einfügungen ungefähr an die gleiche Stelle auf der Festplatte gehen. Wenn Sie ein zufälliges UUID einfügen, muss die Datenbank es irgendwo in die Mitte des Baums setzen — jeder Insert wird ein zufälliger I/O. Bei Millionen von Zeilen killt das den Schreibdurchsatz.
Die historische Lösung war “verwenden Sie UUID v4, aber mit sequenzieller Ordnung” — außer v4 ist per Definition zufällig. Leute haben daran herumgehackt (MySQLs UUID_TO_BIN(..., 1) tauscht die Zeitbits nach vorne). RFC 9562 machte den Hack zum Standard.
UUID v7: zeitgeordnet
UUID v7 setzt einen Millisekunden-Präzisions-Zeitstempel in die hohen Bits und Zufall in die niedrigen Bits:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
├─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┤
| unix_ts_ms |
├─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┤
| unix_ts_ms | ver | rand_a |
├─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┤
|var| rand_b |
├─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┤
| rand_b |
└─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┘Die ersten 48 Bits sind der Unix-Zeitstempel in Millisekunden. Die nächsten 4 Bits sind die Version (7). Dann 74 zufällige Bits, dann 2 Variante-Bits und noch einmal 48 zufällige Bits.
Das Ergebnis: UUIDs, die in derselben Millisekunde generiert wurden, sortieren in der Reihenfolge der Einfügung. Später generierte UUIDs sortieren später. Einfügungen gehen auf die rechte Seite des B-Trees, nicht in die Mitte. Der Schreibdurchsatz steigt um das 2- bis 10-Fache, abhängig von der Datenbank.
Der Benchmark, der zählt
PlanetScale veröffentlichte 2024 einen Benchmark mit konkreten Zahlen. Mit MySQL 8 auf einem Primärschlüssel-Index:
| Format | Inserts/Sek | Anmerkungen |
|---|---|---|
| Auto-Inkrement INT | 35.000 | Am schnellsten, aber gibt Informationen preis |
| UUID v7 | 18.000 | Vergleichbar mit INT für die meisten Apps |
| UUID v4 | 4.500 | Zufällige Inserts = Page Splits |
| UUID v1 (mit Zeitstempel) | 14.000 | Ältere zeitgeordnete Variante |
Der 4-fache Unterschied zwischen v4 und v7 ist der Preis für zufälligen I/O. Für einen Dienst mit hohem Traffic schlägt sich das direkt in Dollar nieder.
Wann v4 verwenden
UUID v4 ist immer noch die richtige Wahl, wenn die ID selbst die Sicherheitsgrenze ist:
- Session-Token — Sie wollen nicht, dass eine Session-IDs ihre Erstellungszeit preisgibt. UUID v7 sortiert nach Zeit, was bedeutet, dass ein Angreifer, der eine ID kennt, benachbarte IDs raten kann. (Praktische Ausnutzbarkeit ist gering — 74 Bits Zufall sind immer noch viel — aber das Prinzip zählt.)
- Passwort-Zurücksetz-Token — gleiche Begründung.
- API-Schlüssel, die an Dritte verteilt werden — wenn die ID uneratbar sein soll, ist Zeitordnung ein Feature, das Sie nicht wollen.
- Alles, was als CSPRNG-Ausgabe verwendet wird — v4 ist das, was
crypto.randomUUID()zurückgibt. Wenn Sie die ID für kryptographischen Zufall verwenden, passt v4 am besten.
Wann v7 verwenden
UUID v7 ist die richtige Standardvorgabe für:
- Datenbank-Primärschlüssel — das ist der Hauptanwendungsfall. Die meisten neuen Schemas sollten v7 wählen.
- Event-Log-IDs — sortierbar nach Zeit ohne separate Zeitstempelspalte.
- Message-Queue-Message-IDs — FIFO-Reihenfolge mit Einzigartigkeit.
- Verteilte System-Identifikatoren, bei denen Sie grobe Ordnung ohne Abstimmung einer Sequenz wollen.
Wie man sie generiert
Im Browser ist v4 eingebaut:
crypto.randomUUID() // v4Für v7 brauchen Sie ein kleines Polyfill — crypto.getRandomValues plus ein Zeitstempel-Präfix. Der UUID-Generator auf DevSpeedTools erzeugt sowohl v4 als auch v7 im Browser direkt mit crypto.getRandomValues, sodass Sie die IDs direkt in Ihr Schema einfügen können, ohne etwas installieren zu müssen.
In Node.js 22+ gibt das eingebaute crypto.randomUUID() nur noch v4 zurück. Das npm uuid-Paket (v9+) hat v7() hinzugefügt. In Python ist uuid.uuid7() in 3.14 gelandet (veröffentlicht Juni 2025) und jetzt die empfohlene Wahl in den Standardbibliothek-Dokumenten. In Postgres gibt die Funktion gen_random_uuid() immer noch v4 zurück — um v7 zu bekommen, generieren Sie client-seitig und übergeben es. MySQL 9 (veröffentlicht 2024) hat UUID_V7_BIN() als erstklassigen Typ hinzugefügt, und MariaDB folgte in 11.7. Cloudflare D1, PlanetScale und Supabase generieren alle 2026 standardmäßig v7 für neue Primärschlüssel-Spalten.
Migration von v4 zu v7
Wenn Sie eine bestehende Tabelle mit v4-Primärschlüsseln haben, müssen Sie nicht migrieren. Die beiden Versionen koexistieren in derselben Spalte (der uuid-Typ akzeptiert beide). Die Leistungsverbesserung liegt bei den Einfügungen, also zählt das nur, wenn Sie neue Zeilen hinzufügen. Die einfachste Migration: Beginnen Sie, v7 für neue Einfügungen zu generieren, bestehende Zeilen als v4 belassen. Sie werden sich leicht ungeordnet mit neuen v7-Zeilen sortieren (da v4 keinen Zeitstempel hat), aber der Index wird in Ordnung sein.
Für ein neues Schema in 2026 ist v7 der Standard. Der 4-fache Schreibdurchsatz-Gewinn ist real, die Spezifikation ist stabil, jede wichtige Sprache-Runtime hat einen v7-Generator, und verwaltete Datenbankanbieter stellen auf v7 als Standard für neue Primärschlüssel um. Greifen Sie nur dann zu v4, wenn Sie speziell uneratbare, zeitkorrelationsfreie IDs brauchen.