Warum ist UUID v7 besser als v4 für Primärschlüssel?

Weil v7 mit einem Zeitstempel beginnt, liegen neue Werte im Index immer am Ende. Es entstehen kaum Seitenteilungen, die Füllrate bleibt hoch, und der INSERT-Durchsatz ist bei großen Tabellen typischerweise zwei- bis fünfmal so hoch wie bei v4.

Sind UUID v7 innerhalb einer Millisekunde sortierbar?

Ja, in diesem Generator. RFC 9562 erlaubt dafür einen Zähler in den Bits direkt nach dem Zeitstempel; wir nutzen ihn, sodass auch mehrere tausend in derselben Millisekunde erzeugte Werte in Entstehungsreihenfolge sortieren.

Verrät UUID v7 den Entstehungszeitpunkt?

Ja, die ersten 48 Bit sind ein Unix-Zeitstempel in Millisekunden und lassen sich auslesen. Für öffentlich sichtbare Bezeichner, bei denen das ein Problem ist, verwenden Sie besser v4.

Welche Datenbanken unterstützen UUID v7 nativ?

PostgreSQL bringt ab Version 18 uuidv7() mit. Für MySQL, SQL Server und ältere PostgreSQL-Versionen erzeugen Sie die Werte in der Anwendung - jede verbreitete Sprache hat dafür eine Bibliothek.

UUID v7 Generator - zeitlich sortierte Datenbankschlüssel

Was ist UUID v7?

UUID v7 ist in RFC 9562 definiert und stellt einen 48 Bit langen Unix-Zeitstempel in Millisekunden an den Anfang des Bezeichners. Die verbleibenden Bits tragen einen Zähler und kryptografischen Zufall.

Dadurch sortiert die Textform chronologisch: ORDER BY id liefert die Datensätze in Entstehungsreihenfolge, ohne dass eine zusätzliche Zeitstempelspalte nötig ist.

Der innere Aufbau

Die 128 Bit verteilen sich auf vier Abschnitte: 48 Bit unix_ts_ms, 4 Bit Version (0111), 12 Bit rand_a, 2 Bit Variante und 62 Bit rand_b.

Der 48-Bit-Zeitstempel reicht bis in das Jahr 10889. Weil der Zeitstempel in den höchstwertigen Bits steht, gilt die chronologische Ordnung sowohl für die Textform als auch für die binäre Darstellung.

Warum v7 die richtige Wahl für Primärschlüssel ist

B-Baum-Indizes arbeiten am effizientesten, wenn neue Werte am rechten Rand eingefügt werden. Genau das leistet der Zeitstempel-Präfix: die zuletzt genutzte Indexseite bleibt im Cache, Seitenteilungen entfallen fast vollständig, und die Füllrate liegt nahe am Optimum.

Bei zufälligen v4-Schlüsseln trifft jeder INSERT eine andere Seite. In großen Tabellen bedeutet das mehr zufälliges I/O, fragmentierte Indizes und messbar niedrigeren Durchsatz.

Monotonie innerhalb einer Millisekunde

Ein Zeitstempel in Millisekunden allein genügt nicht: eine schnelle Schleife erzeugt tausende Werte pro Millisekunde, deren Reihenfolge dann vom Zufallsanteil abhängen würde.

RFC 9562 beschreibt in Abschnitt 6.2 dafür einen dedizierten Zähler. Dieser Generator führt einen 12-Bit-Zähler in rand_a, der innerhalb derselben Millisekunde hochzählt und beim Wechsel der Millisekunde neu zufällig gesetzt wird. Auch ein Sprung der Systemuhr nach hinten unterbricht die Monotonie nicht.

Unterstützung in Datenbanken und Bibliotheken

PostgreSQL 18 bringt uuidv7() als eingebaute Funktion mit. In anderen Systemen erzeugen Sie die Werte anwendungsseitig: in JavaScript etwa mit dem Paket uuid ab Version 10, in Python mit uuid6, in Java mit java-uuid-generator, in Go mit google/uuid.

Gespeichert wird v7 genau wie jede andere UUID - als UUID, BINARY(16) oder UNIQUEIDENTIFIER. Ein Schemawechsel ist nicht erforderlich.

Den Zeitstempel wieder auslesen

Die ersten zwölf Hexadezimalziffern sind der Zeitstempel. In JavaScript genügt eine Zeile:

const ms = parseInt(uuid.replace(/-/g, '').slice(0, 12), 16);
new Date(ms); // Entstehungszeitpunkt

Das ist praktisch für Debugging und Datenanalysen - und gleichzeitig der Grund, v7 nicht für Bezeichner zu verwenden, deren Entstehungszeit vertraulich ist.

UUID v7 und ULID im direkten Vergleich

Beide kodieren 128 Bit mit einem 48-Bit-Millisekunden-Präfix und sind sortierbar. Der Unterschied liegt in Format und Rückendeckung: v7 ist in einem RFC standardisiert und passt in jede vorhandene UUID-Spalte; ULID ist mit 26 Zeichen kürzer und in URLs angenehmer, aber ohne formalen Standard. Für neue Systeme mit Datenbankanbindung ist v7 die konservativere und meist bessere Wahl.