UUID-Versionen

Anatomie: 128 Bits in 36 Zeichen

Eine UUID ist 128 Bits, kanonisch geschrieben als 32 kleingeschriebene Hexadezimalziffern in fünf durch Bindestriche getrennten Gruppen zu 8-4-4-4-12 – 36 Zeichen mit den Bindestrichen, 32 ohne. Das Layout ist keine Dekoration: Bestimmte Bitbereiche tragen Bedeutung. Das vier Bit große Versionsfeld nimmt das höchste Nibble der dritten Gruppe ein, und die zwei Bit große Variante – die RFC-artige UUIDs von älteren Microsoft- und Legacy-Layouts unterscheidet – nimmt die oberen Bits der vierten Gruppe ein und liest sich hexadezimal immer als 8, 9, a oder b.

v1  614e4000-26bc-11ef-b17d-0242ac120002
v4  f7b17bde-5a0c-4174-8c95-407558615543
v6  1ec9414c-232a-6b00-b3c8-9e6bdeced846
v7  019b76da-a800-7c3e-8f2a-5b6c7d8e9f0a

3rd group, 1st hex digit = version (1, 4, 6, 7 here)
4th group, 1st hex digit = variant (b, 8, b, 8 here)

v1 und v6: eine Uhr und eine MAC-Adresse

v1 baut die Kennung aus einem 60-Bit-Zeitstempel auf, der 100-Nanosekunden-Intervalle seit dem 15. Oktober 1582 zählt – dem Beginn des Gregorianischen Kalenders –, plus einem Clock-Sequence-Zähler und der 48-Bit-MAC-Adresse der Maschine. Der Zeitstempel wird unschön aufgeteilt in time_low, time_mid, time_high – eine Feldreihenfolge, gewählt aus einem Bit-Packing-Komfort der 1990er Jahre und später bereut. Die MAC-Adresse ist die Privatsphäre-Mine: Jede v1-UUID verrät, welche Hardware sie erzeugt hat; deshalb erlaubte RFC 4122 schon den Ersatz durch einen zufälligen Multicast-Node.

v6 ist v1 mit korrigierter Feldreihenfolge: Die höchstwertigen Zeitstempel-Bits rücken nach vorn, sodass v6-UUIDs chronologisch sortieren, wenn man sie als Zeichenketten sortiert. Gleiche Uhr, gleiches Node-Feld, gleiche Privatsphäre-Einschränkungen – aber deutlich besseres Datenbankverhalten, und genau das ist der Sinn der Umordnung.

v1:  614e4000-26bc-11ef-b17d-0242ac120002
v6:  1ec9414c-232a-6b00-b3c8-9e6bdeced846

v6 – das Feld timeHigh steht vorn, daher ist die
lexikografische Ordnung die chronologische. v1 beginnt
mit den niedrigstwertigen Bits und streut stattdessen.

v3 und v5: Identität aus einem Namen

v3 und v5 leiten die Kennung aus einer Namespace-UUID und einem Namen ab, gehasht mit MD5 (v3) oder SHA-1 (v5). Gleicher Namespace, gleicher Name, gleiche UUID – auf jeder Maschine, für immer. Dieser Determinismus ist das Merkmal: Stabile Kennungen lassen sich aus URLs, Benutzernamen oder Domainnamen ableiten, ohne eine Zuordnungstabelle zu speichern, und jederzeit auf jedem System neu erzeugen.

Der Preis ist die Kehrseite des Determinismus: Die Kennung verrät Informationen über den Namen. Eine v5 eines Namens mit niedriger Entropie lässt sich durch simples Raten bestätigen, und identische Namen erzeugen absichtlich identische Kennungen. v5 löst v3 ab – SHA-1 statt MD5 –, und obwohl RFC 9562 keine neue namensbasierte Version benennt, weichen neue Entwürfe, die sowohl Determinismus als auch Zeitordnung wollen, meist zu v7 aus und speichern den Namen daneben.

namespace: DNS   6ba7b810-9dad-11d1-80b4-00c04fd430c8
name:      python.org

v3  6fa459ea-ee8a-3ca4-894e-db77e160355e
v5  886313e1-3b8a-5372-9b90-0c9aee199e5d

hash(namespace bytes || "python.org") mit Version
(3 oder 5) und Variante (binär 10) an festen
Bitpositionen – dieselbe Berechnung, Bit für Bit.

v4: 122 zufällige Bits und was sie bringen

v4 setzt 122 Bits aus einem kryptografisch sicheren Zufallsgenerator; nur die Versions- und Varianten-Nibbles sind festgelegt. Die Kollisionswahrscheinlichkeit folgt der Geburtstags-Schranke: Nach dem Erzeugen von n Werten liegt die Chance auf irgendeinen Duplikat bei etwa n²/2¹²³. Sie bräuchten rund 2^61 UUIDs – etwa 2,3 Trillionen –, um eine Münzwurf-Chance auf eine einzige Kollision zu haben. Wenn in der Praxis doch Duplikate auftauchen, liegt die Ursache fast immer an gebrochener Zufälligkeit – ein schwacher Seed, wiederverwendeter PRNG-Zustand, ein Hardwarefehler –, nie an den Wahrscheinlichkeiten selbst.

Zufälligkeit ist zugleich v4s Schwäche als Datenbankschlüssel: Vollständig ungeordnete Werte landen in zufälligen B-Tree-Seiten, fragmentieren Indexe und erschöpfen Schreib-Caches bei großen Datenmengen. Genau diese Beschwerde sollte die Standardisierung von v6 und v7 beheben, und deshalb steuern viele ORMs und verteilte Datenbanken neue Tabellen heute Richtung v7.

v7: Unix-Millisekunden plus Zufälligkeit

v7 ist der moderne Standard-Kandidat: 48 Bits Unix-Zeitstempel in Millisekunden, dann 12 plus 62 Bits zufälliger Payload. Der führende Zeitstempel macht v7-UUIDs als Zeichenketten sortierbar – indexfreundlich ausgerechnet in den Datenbanken, die sie speichern –, während die 74 zufälligen Bits die Kollisionswahrscheinlichkeit praktisch auf v4-Niveau halten. Er braucht keine MAC-Adresse, keine Epoche von 1582 und keine Kalenderumrechnungen.

Innerhalb derselben Millisekunde beschreibt RFC 9562 einen monotonen Zähler im Feld rand_a, sodass Kennungen in schneller Folge trotzdem weiter steigen – eine Eigenschaft, die Primärschlüssel noch mehr interessiert als rohe Eindeutigkeit. Der Zeitstempel ist auch lesbar: Er liest sich als 2026, nicht als Zählwerk von 100-Nanosekunden-Ticks seit 1582, was v7 in Logs und Abfrageergebnissen angenehm für den Blick macht.

2026-01-01T00:00:00Z  019b76da-a800-7c3e-8f2a-5b6c7d8e9f0a
2026-01-01T00:00:01Z  019b76da-abe8-9d41-8c2f-4a5b6c7d8e9f

019b76da-a800-… < 019b76da-abe8-…

die lexikografische Ordnung entspricht der zeitlichen,
und die oberen 48 Bits sind ein Unix-Zeitstempel in ms.

Eine Version wählen – ehrlich

Für neue Projekte: v7, wenn Kennungen zeitlich sortieren sollen oder in einem Datenbankindex leben; sonst v4 – beide brauchen keine Koordination und verraten nichts über ihren Ursprung. v5 zahlt sich aus, wenn die Kennung aus einem Namen reproduzierbar sein muss. v1 und v6 bleiben unterstützt, geben aber Hardware-Identität preis, sofern der Generator das Node-Feld nicht randomisiert; v3 ist MD5-Erbe, das aus Kompatibilitätsgründen mitgeschleppt wird. Keine der Versionen ist geheim, und keine anonymisiert Daten: Eine UUID ist ein Name, kein Nachweis.