UUIDs, NanoIDs und CUIDs: Das richtige ID-Format für Ihr Projekt wählen

Jeder Datenbankdatensatz, jede API-Ressource, jedes verteilte Ereignis und jedes Session-Token benötigt einen eindeutigen Bezeichner. Die Wahl des ID-Formats ist wichtiger, als es zunächst scheint — sie beeinflusst Sicherheit, Datenbankleistung, URL-Lesbarkeit und das Verhalten Ihres Systems, wenn Sie später mehrere Server betreiben oder Daten aus verschiedenen Quellen zusammenführen. Dieser Leitfaden behandelt die wichtigsten Optionen: UUIDs (v1, v4, v7), NanoIDs und CUIDs sowie den richtigen Einsatzzeitpunkt für jede Variante.

UUIDs und andere eindeutige IDs können Sie sofort mit dem BrowseryTools UUID-Generator erzeugen — kostenlos, ohne Anmeldung, alles wird lokal in Ihrem Browser generiert.

Warum Auto-Increment-IDs an Grenzen stoßen

Sequentielle Ganzzahl-IDs (1, 2, 3, ...) sind in den meisten relationalen Datenbanken der Standard und funktionieren gut für einfache Einzelserver-Anwendungen. Bei größeren Systemen oder verteilten Architekturen entstehen jedoch Probleme:

• Vorhersehbarkeit — wer eine ID kennt, kann andere erraten. /orders/1042 macht deutlich, dass Bestellung 1041 existiert und dass Ihr Unternehmen nicht besonders groß ist. Das ist eine IDOR-Schwachstelle (Insecure Direct Object Reference), wenn keine Autorisierung auf Anwendungsebene durchgesetzt wird.
• Merge-Konflikte — müssen Sie Daten aus zwei Datenbanken zusammenführen, kollidieren zwei separate Auto-Increment-Sequenzen. Multi-Tenant-Systeme, Offline-First-Apps und Migrationen stoßen alle auf dieses Problem.
• Verteilte Generierung — wenn mehrere Server oder Worker Datensätze einfügen, benötigen Sie einen Koordinationsmechanismus (eine einzelne Sequenz oder eine datenbankweite Sequenz), um doppelte IDs zu vermeiden. Das schafft einen Engpass.
• Offenlegung von Geschäftskennzahlen — sequentielle IDs verraten Bestellvolumen, Nutzerzahl und Wachstumsrate an Mitbewerber oder Forscher, die öffentliche IDs über die Zeit beobachten.

Was ist eine UUID?

Eine UUID (Universally Unique Identifier, auch GUID genannt) ist eine 128-Bit-Zahl, die üblicherweise als 32 hexadezimale Ziffern in fünf durch Bindestriche getrennte Gruppen dargestellt wird:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

Example: 550e8400-e29b-41d4-a716-446655440000
          ^        ^    ^    ^    ^
          |        |    |    |    12 hex digits (48 bits)
          |        |    |    variant bits (N)
          |        |    version digit (M)
          |        4 hex digits
          8 hex digits

Die Versionsziffer (M) gibt Auskunft über den verwendeten UUID-Generierungsalgorithmus. Die Variantenbits (N) sind in Standard-UUIDs immer 8, 9, a oder b. Die verbleibenden 122 Bits stehen für die eigentlichen Bezeichnerdaten zur Verfügung.

UUID v1: MAC-Adresse + Zeitstempel

UUID v1 kombiniert den aktuellen Zeitstempel (in 100-Nanosekunden-Intervallen seit dem 15. Oktober 1582) mit der MAC-Adresse des generierenden Rechners und einer Taktsequenz für die schnelle Generierung. Das Ergebnis ist theoretisch auf allen Rechnern und zu allen Zeiten eindeutig.

Das Problem: v1-UUIDs verraten sowohl den Zeitpunkt als auch den Ort ihrer Generierung — die MAC-Adresse ist im Klartext eingebettet. Das ist ein Datenschutzproblem und wurde beim Melissa-Wurm (1999) ausgenutzt, um infizierte Dokumente bis zu bestimmten Rechnern zurückzuverfolgen. Aus diesem Grund wird v1 in neuen Anwendungen kaum noch verwendet. Wer zeitgeordnete IDs möchte, greift heute stattdessen auf v7 zurück.

UUID v4: Zufällig

UUID v4 ist die am weitesten verbreitete Variante. Sie besteht aus 122 Bits kryptografisch zufälliger Daten (die verbleibenden 6 Bits kodieren Version und Variante). Kein Zeitstempel, keine MAC-Adresse, keine sequentielle Komponente — nur Entropie.

// Node.js 14.17+
const { randomUUID } = require('crypto');
randomUUID(); // → "9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d"

// Browser
crypto.randomUUID(); // → "1b9d6bcd-bbfd-4b2d-9b5d-ab8dfbbd4bed"

// Python
import uuid
str(uuid.uuid4()) # → "3d6f4580-2b3e-44e4-9d40-2d0ab12b4e7e"

Wie unwahrscheinlich sind UUID-v4-Kollisionen?

Mit 122 Bits Zufälligkeit ist die Kollisionswahrscheinlichkeit außerordentlich gering. Um eine 50-prozentige Wahrscheinlichkeit für mindestens eine Kollision zu erreichen, müssten Sie ungefähr 2,7 × 10¹⁸ UUIDs generieren — das sind 2,7 Quintillionen. Wenn Sie eine Milliarde UUIDs pro Sekunde generieren würden, würde es etwa 85 Jahre dauern, diesen Schwellenwert zu erreichen. Für jede reale Anwendung sind Kollisionen kein praktisches Problem. Die wahrscheinlichere Quelle doppelter IDs sind Anwendungsfehler (Copy-Paste-Fehler, Cache-Treffer mit alten IDs usw.), nicht der Generator selbst.

UUID v7: Zeitgeordnet und zufällig

UUID v7 wurde in RFC 9562 (2024) standardisiert, um den wichtigsten praktischen Nachteil von v4 zu beheben: Zufällige UUIDs sind schlechte Datenbankprimärschlüssel, weil sie die Indexlokalität zerstören. Werden Datensätze mit zufälligen IDs eingefügt, landet jede Einfügung an einer zufälligen Position in einem B-Baum-Index, was bei größeren Datenmengen zu Seitenaufteilungen, Cache-Fehltreffern und Fragmentierung führt.

UUID v7 bettet einen Unix-Zeitstempel mit Millisekunden-Genauigkeit in die signifikantesten Bits ein, gefolgt von Zufallsdaten. Dadurch sind v7-UUIDs sortierbar — chronologisch eingefügte Datensätze haben lexikografisch steigende IDs — und gleichzeitig global eindeutig und über die Millisekundengrenze hinaus unvorhersehbar:

UUID v7 structure:
[48 bits: Unix ms timestamp][4 bits: version=7][12 bits: random][2 bits: variant][62 bits: random]

Three v7 UUIDs generated in sequence:
  0192fe2c-4b3a-7000-8000-0a1b2c3d4e5f  ← earliest
  0192fe2c-4b3b-7001-8000-0a1b2c3d4e60  ← slightly later
  0192fe2c-4b3c-7002-8000-0a1b2c3d4e61  ← latest
  ^^^^^^^^^^ timestamp prefix increases monotonically

Wenn Sie eine neue Anwendung entwickeln, die UUIDs als Primärschlüssel in einer relationalen Datenbank verwendet, ist v7 ab 2024 die richtige Standardwahl.

NanoID: Kürzer und URL-sicher

NanoID ist keine UUID — es ist ein anderes ID-Format, das jedoch dasselbe Problem löst. Standardmäßig erzeugt es eine 21-Zeichen-Zeichenkette mit einem Alphabet aus URL-sicheren Zeichen (A-Za-z0-9_-). Das ergibt 126 Bits Entropie — vergleichbar mit UUID v4 — in einer Zeichenkette mit 21 statt 36 Zeichen. NanoID-Strings sind URL-freundlich ohne weitere Kodierung und sehen in Logs und nutzersichtigen URLs sauberer aus:

UUID v4:  9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d  (36 chars)
NanoID:   V1StGXR8_Z5jdHi6B-myT                  (21 chars)

import { nanoid } from 'nanoid';
nanoid();      // → "V1StGXR8_Z5jdHi6B-myT"
nanoid(10);    // → "IRFa-VaY2b"  (custom length)

NanoID ist beliebt für Kurzlink-IDs, Session-Tokens, Einladungscodes und alle Anwendungsfälle, bei denen die ID in einer URL erscheint und kompakt sein soll.

CUID2: Sortierbar und ohne Fingerabdruck

CUID2 (der Nachfolger von CUID) wurde speziell für den Einsatz als Datenbankprimärschlüssel entwickelt. Es erzeugt eine 24-Zeichen-Zeichenkette, die nach Erstellungszeit sortierbar ist, keine MAC-Adresse oder Fingerabdruck verwendet und schwieriger vorherzusagen ist als zeitbasierte IDs. CUID2 verwendet SHA-3 intern, um den Zeitstempel mit Zufallsdaten zu vermischen, was die Ausgabe auch bei gleichzeitiger Generierung im selben Millisekunden-Intervall unvorhersehbar macht.

CUID2 ist eine gute Wahl, wenn Sie sortierbare IDs möchten, das UUID-Format vollständig vermeiden wollen und Wert darauf legen, dass die ID undurchsichtig ist (keine Zeitstempelinformationen direkt preisgibt).

Das richtige Format wählen

• Datenbankprimärschlüssel, neues Projekt — UUID v7 oder CUID2. Beide sind sortierbar, was die Indexleistung beim Datenwachstum gesund hält.
• Allzweck-Eindeutigkeit, Interoperabilität — UUID v4. Jede Sprache und jedes Framework versteht das UUID-Format nativ.
• Kurzlinks, Einladungscodes, URL-Tokens — NanoID. Kompakt, URL-sicher, konfigurierbare Länge.
• Verteilte Systeme mit clientseitig generierten IDs — UUID v4 oder v7. Keine Koordination notwendig; Clients generieren ihre eigenen IDs vor dem Server-Commit.
• v1 vermeiden — es gibt Ihre MAC-Adresse preis. Kein neues Projekt sollte es verwenden.

UUID als Primärschlüssel: Leistungsaspekte

Die klassische Warnung „Verwenden Sie keine UUIDs als Primärschlüssel" bezieht sich speziell auf zufällige UUIDs (v4) in MySQL mit InnoDB oder in jeder Datenbank, die Daten nach Primärschlüssel clustert. Zufällige Einfügereihenfolge fragmentiert den geclusterten Index. In PostgreSQL mit einem nicht-geclusterten UUID-Index ist die Einbuße weniger schwerwiegend, aber bei großem Datenvolumen dennoch real. Die praktische Lösung: Verwenden Sie UUID v7 oder CUID2 (die monoton ansteigen), und das Fragmentierungsproblem verschwindet weitgehend. Nutzen Sie den BrowseryTools UUID-Generator, um v7-UUIDs zum Testen Ihres Schemas zu generieren, bevor Sie sich auf ein Format festlegen.