🧰 ToolPicoAlle Tools →

StartseiteBlog › UUID vs. GUID

UUID vs. GUID: Welche Version solltest du für deine Datenbank wählen?

v1, v3/v5, v4 oder v7 — die Wahl der richtigen UUID-Version klingt nach Kleinkram, kann sich aber spürbar auf Datenschutz, Reproduzierbarkeit und Datenbank-Performance auswirken. Dieser Leitfaden ordnet die gängigsten Versionen nach ihrem tatsächlichen Einsatzzweck ein.

Inhalt

Was UUID und GUID wirklich unterscheidet

KurzantwortPraktisch nichts — beide bezeichnen dieselbe 128-Bit-Struktur nach RFC 4122 (aktuell RFC 9562). „GUID” ist nur Microsofts historische Bezeichnung dafür, mit einer leicht abweichenden Standardformatierung (oft in geschweiften Klammern).

Eine UUID ist ein 128-Bit-Identifikator, der als 32 Hexadezimalzeichen in fünf Gruppen (8-4-4-4-12) geschrieben wird, z. B. 550e8400-e29b-41d4-a716-446655440000. Der Standard definiert mehrere „Versionen” — v1 bis v7 sind derzeit spezifiziert —, die sich darin unterscheiden, wie die 122 nutzbaren Bit gefüllt werden: zufällig, zeitbasiert oder aus einem Namen abgeleitet.

In der Praxis begegnet man dem Namen „GUID” vor allem in .NET-, SQL-Server- und Windows-Kontexten, während „UUID” in Unix-, Web- und den meisten anderen Programmiersprachen gebräuchlich ist. Der ToolPico-UUID-Generator kann beide Schreibweisen erzeugen — inklusive der geschweiften-Klammern-Variante über die entsprechende Formatoption.

v4 (zufällig) vs. v7 (zeitlich sortiert)

Kurzantwortv4 ist rein zufällig und heute der gebräuchlichste Standardmodus; v7 beginnt mit einem Millisekunden-Zeitstempel und eignet sich besser als Primärschlüssel in Datenbanken mit sortierten Indizes.

Eine v4-UUID füllt 122 Bit mit kryptografisch sicherer Zufälligkeit (im Browser über crypto.getRandomValues). Das macht sie ideal für Sitzungs-Tokens, API-Schlüssel oder überall dort, wo Unvorhersehbarkeit gewünscht ist. Der Nachteil: Weil die Werte komplett zufällig sind, landen neue Datensätze in einer Datenbanktabelle an zufälligen Stellen im Index, was bei sehr großen Tabellen zu mehr Indexfragmentierung führen kann.

Eine v7-UUID löst genau dieses Problem: Ihre ersten 48 Bit sind ein Unix-Zeitstempel in Millisekunden, der Rest bleibt zufällig. Dadurch sind nacheinander erzeugte v7-Werte auch numerisch aufsteigend sortiert — ähnlich wie ein klassischer Auto-Increment-Schlüssel, aber ohne zentrale Vergabestelle und ohne die Vorhersagbarkeit einer fortlaufenden Zahl.

Beispielhafte Einordnung (kein gemessener Benchmark, sondern zur Veranschaulichung): Bei einer Tabelle mit mehreren zehn Millionen Zeilen kann ein sortierter Primärschlüssel wie v7 die Indexpflege spürbar entlasten, während der Unterschied bei kleineren Tabellen mit wenigen Tausend Zeilen in der Praxis kaum ins Gewicht fällt.
VersionEnthält Zeitstempel?Sortierbar?Typischer Einsatz
v4 (zufällig)NeinNeinSitzungs-IDs, API-Schlüssel, allgemeine Datensätze
v7 (zeitlich sortiert)Ja (ms-genau)JaDatenbank-Primärschlüssel, Event-Logs
v1-ähnlich (zeitbasiert)JaTeilweiseLegacy-Systeme, ältere Standards

Beide Modi lassen sich im UUID-Generator direkt über die Reiter „v4 Zufall” und „v7 Sortiert” erzeugen, jeweils mit Bulk-Generierung von 1 bis 1.000 Werten auf einmal.

Wann v5 (namensbasiert) sinnvoll ist

Kurzantwortv5 (und das ältere v3) erzeugt für denselben Namespace + Namen immer dieselbe UUID — nützlich, wenn ein Wert reproduzierbar sein soll, ohne dass er irgendwo gespeichert werden muss.

Anders als v4 oder v7 ist eine v5-UUID deterministisch: Sie wird aus einem Namespace (z. B. dem Standard-DNS-Namespace 6ba7b810-9dad-11d1-80b4-00c04fd430c8) und einem beliebigen Namen (etwa einer Domain oder einer Datei-ID) per SHA-1 berechnet. Gibst du denselben Namespace und Namen erneut ein, erhältst du exakt dieselbe UUID zurück.

PraxisszenarioEin Team möchte für jede Kunden-Domain eine stabile interne ID erzeugen, ohne eine Zuordnungstabelle zu pflegen. Statt die Domain als String zu speichern, berechnen sie bei jedem Zugriff v5(DNS-Namespace, "kunde-domain.de") neu — das Ergebnis ist immer identisch, ganz ohne zusätzliche Datenbanktabelle.

Das ältere v3 nutzt denselben Mechanismus, aber mit MD5 statt SHA-1; v5 gilt heute als der empfohlene Nachfolger. Im ToolPico-Generator lassen sich unter dem Reiter „v3 / v5 Name” mehrere Namen zeilenweise gleichzeitig verarbeiten (Bulk-Modus), inklusive der vier Standard-Namespaces (DNS, URL, OID, X.500) oder eines eigenen.

Format, Länge und Kollisionswahrscheinlichkeit

KurzantwortEine UUID ist immer 128 Bit (16 Byte) groß; in Standardschreibweise sind das 36 Zeichen inklusive vier Bindestriche. Bei v4 ist eine Kollision statistisch verschwindend unwahrscheinlich.

Egal welche Version: Die Rohgröße einer UUID bleibt immer 128 Bit. In der textuellen Standardform (8-4-4-4-12) sind das 32 Hexzeichen plus 4 Bindestriche, also 36 Zeichen insgesamt. Ohne Bindestriche sind es 32 Zeichen, im .NET-GUID-Stil mit geschweiften Klammern 38 Zeichen — alle drei Formate lassen sich im Generator per Formatoption umschalten.

Zur Kollisionswahrscheinlichkeit bei v4: Da 122 Bit zufällig sind, wäre laut dem Geburtstagsparadoxon (ein kombinatorisches Beispielmodell, keine Garantie für jede konkrete Implementierung) eine Menge von grob 2,71 Trillionen generierten v4-UUIDs nötig, um eine 50-prozentige Kollisionschance zu erreichen. In normalen Anwendungen — selbst bei Milliarden von Datensätzen — bleibt das Risiko damit praktisch vernachlässigbar.

Der Validator-Reiter im Tool erkennt zudem automatisch Version und Variante einer eingefügten UUID und dekodiert bei v1, v7 und ULID den eingebetteten Erstellungszeitstempel in UTC und Lokalzeit.

UUIDs in v4, v7, v5 oder als ULID direkt im Browser generieren, validieren und im Bulk exportieren — ganz ohne Serveranfrage.

Zum UUID-Generator →

Häufig gestellte Fragen

Ist eine UUID dasselbe wie eine GUID?
Im Kern ja: Eine GUID ist Microsofts Bezeichnung für dieselbe 128-Bit-Struktur, die durch RFC 4122 definiert wird. Der praktische Unterschied liegt fast immer nur in der Formatierung — .NET-GUIDs werden oft in geschweiften Klammern dargestellt, etwa {550e8400-e29b-41d4-a716-446655440000}, während die Standard-UUID-Schreibweise ohne Klammern auskommt.
Warum sollte ich für Datenbank-Primärschlüssel v7 statt v4 verwenden?
Eine v4-UUID ist komplett zufällig, was bei Datenbankindizes (z. B. B-Tree-Indizes) zu zufälligen Einfügepositionen und dadurch zu mehr Indexfragmentierung führen kann. Eine v7-UUID beginnt mit einem Millisekunden-Zeitstempel, sodass nacheinander erzeugte v7-Werte auch numerisch aufsteigend sortiert sind — ähnlich wie ein Auto-Increment-Schlüssel, nur global eindeutig. Das kann bei sehr großen Tabellen die Index-Performance verbessern. Für kleine bis mittlere Projekte ist der Unterschied in der Praxis oft vernachlässigbar.
Wie wahrscheinlich ist eine UUID-Kollision wirklich?
Bei v4-UUIDs stehen 122 Bit für Zufälligkeit zur Verfügung. Rein rechnerisch (Geburtstagsparadoxon) müsste man ungefähr 2,71 Trillionen v4-UUIDs erzeugen, um eine 50-prozentige Kollisionswahrscheinlichkeit zu erreichen — das ist ein Beispielwert aus der Kombinatorik, keine Garantie für jede Implementierung, aber er zeigt, warum Kollisionen in normalen Anwendungen praktisch nie beobachtet werden.
Wann sollte ich eine namensbasierte UUID (v5) statt einer zufälligen (v4) verwenden?
Verwende v5 (oder das ältere v3), wenn du für denselben Input — z. B. eine Domain, eine E-Mail-Adresse oder einen Dateipfad — immer wieder dieselbe UUID erzeugen möchtest, ohne sie irgendwo zu speichern. v5 kombiniert einen Namespace (z. B. den DNS-Namespace) mit einem Namen über SHA-1 zu einem deterministischen Ergebnis. v4 dagegen ist rein zufällig und für jeden neuen Datensatz gedacht, bei dem keine Wiederholbarkeit nötig ist.
Kann ich aus einer UUID ablesen, wann sie erzeugt wurde?
Bei v1- und v7-UUIDs sowie bei ULIDs ja, weil sie einen eingebetteten Zeitstempel enthalten. Bei v3-, v4- und v5-UUIDs nein — sie enthalten keinerlei Zeitinformation. Der Validator-Reiter im ToolPico-UUID-Generator dekodiert diesen eingebetteten Zeitstempel automatisch in UTC und Lokalzeit, wenn eine passende Version eingefügt wird.
Hinweis zur Methodik: Dieser Artikel dient der allgemeinen Information zu UUID-Versionen gemäß RFC 4122/9562 und ersetzt keine individuelle Architektur- oder Datenbankberatung. Zahlenbeispiele zu Kollisionswahrscheinlichkeit und Index-Performance sind vereinfachte Veranschaulichungen, keine gemessenen Benchmarks für ein konkretes System.