Kann ich v4 nachträglich durch v7 ersetzen?

Für neue Datensätze ja, weil beide Versionen dasselbe Format haben. Bestehende v4-Schlüssel bleiben gültig, nur die Sortierung gilt dann erst ab dem Umstellungszeitpunkt.

Verrät eine v7-UUID die Uhrzeit?

Ja, die ersten 48 Bit sind die Unix-Zeit in Millisekunden. Wer das nicht möchte, etwa bei öffentlichen Links, nimmt Version 4.

Unterstützen Datenbanken v7 nativ?

PostgreSQL ab Version 18 mit uuidv7(), MySQL über Funktionen, SQLite über Erweiterungen. Ansonsten erzeugt die Anwendung die Werte, so wie dieser Generator.

UUID v4 oder v7? Wann welche Version passt

Beide Versionen sehen gleich aus, sind gleich lang und werden von jeder Bibliothek akzeptiert. Der Unterschied liegt in den ersten 48 Bit und hat Folgen, die man erst im Betrieb merkt.

Version 4: Zufall und sonst nichts

Eine v4-UUID besteht aus 122 Zufallsbits, dazu die festen Versions- und Variantenbits. Sie verrät nichts: keinen Zeitpunkt, keinen Rechner, keine Reihenfolge. Genau das macht sie zum Standard für alles, was nach außen sichtbar ist, etwa Links zu Dokumenten, Bestellnummern in E-Mails oder Kennungen in einer öffentlichen API.

Der Nachteil zeigt sich in Datenbanken mit B-Baum-Index, also praktisch allen. Neue Zufallsschlüssel landen an beliebigen Stellen im Index. Jede Einfügung trifft eine andere Seite, der Cache hilft kaum, und der Index wächst zerklüftet. Bei kleinen Tabellen ist das egal. Ab einigen Millionen Zeilen kostet es messbar Schreibdurchsatz und Speicher.

Version 7: Zeit vorne, Zufall hinten

RFC 9562 hat 2024 die Version 7 eingeführt. Die ersten 48 Bit enthalten die Unix-Zeit in Millisekunden, die restlichen 74 Bit sind Zufall. Zwei Eigenschaften folgen daraus:

Sortierbarkeit. Werte, die später erzeugt wurden, sind auch lexikografisch größer. Ein ORDER BY id liefert die Einfügereihenfolge, ohne eigene Zeitspalte.
Freundlicher Index. Neue Schlüssel landen immer am rechten Rand des B-Baums, so wie bei einer laufenden Nummer. Einfügungen bleiben schnell, der Index kompakt.

Innerhalb derselben Millisekunde entscheidet der Zufallsteil über die Reihenfolge. Wer strikte Ordnung auch dann braucht, verwendet einen monotonen Zähler in den Zufallsbits, was der Standard ausdrücklich erlaubt.

Entscheidungshilfe

Frage	Version 4	Version 7
Schlüssel ist öffentlich sichtbar	ja	eher nicht
Erzeugungszeit darf ablesbar sein	nein	ja
Tabelle wird groß, viele Einfügungen	mäßig	gut
Sortierung nach Entstehung nötig	nein	ja
Ältere Bibliotheken ohne v7-Support	ja	Anwendung erzeugt selbst

Zwei Fallstricke

Uhrzeit des Erzeugers. Version 7 vertraut der Systemuhr. Läuft sie auf einem Server falsch, sortieren dessen Schlüssel an die falsche Stelle. Das bricht nichts, verdirbt aber die schöne Reihenfolge. NTP auf allen Erzeugern ist Pflicht.

Informationsleck. Aus zwei v7-UUIDs lässt sich ablesen, wie viel Zeit zwischen zwei Datensätzen lag. Für interne Schlüssel unproblematisch, für Kennungen in öffentlichen URLs ein Grund, doch Version 4 zu nehmen oder eine zweite, öffentliche Kennung zu führen.

Empfehlung

Für interne Primärschlüssel, Ereignisse, Logs und Warteschlangen: Version 7. Für alles, was Nutzer sehen oder weitergeben: Version 4. Beide lassen sich in derselben Spalte mischen, weil das Format identisch ist. Der Generator auf der Startseite erzeugt beide, und das Prüffeld zeigt bei Version 7 den enthaltenen Zeitstempel an.