"UUID vs ULID vs CUID: Welches ID-Format 2026 verwenden?"

Warum eindeutige IDs komplexer sind als sie aussehen

Du brauchst eine eindeutige Kennung für eine Datenbankzeile, eine API-Ressource, ein Session-Token. Einfach, oder? Nimm einfach eine Zahl.

Das Problem mit sequentiellen Ganzzahlen: Sie sind vorhersehbar (/users/1, /users/2) — jeder kann deine Ressourcen aufzählen. Sie erfordern eine zentrale Autorität (nur ein Server kann die „nächste" Zahl bestimmen). Und sie verraten Geschäftsinformationen (deine 1000. Bestellung hat die ID 1000).

Also erfand die Welt bessere IDs. Und hörte nicht auf zu erfinden. Hier ist, was jedes Format wirklich tut.

UUID (v4) — Die sichere Standardwahl

Format: 550e8400-e29b-41d4-a716-446655440000 Länge: 36 Zeichen (32 Hex + 4 Bindestriche) Zufälligkeit: 122 Bit

UUID v4 sind 122 zufällige Bits in einem Standardformat. Die Kollisionswahrscheinlichkeit ist so astronomisch gering (man müsste 1 Milliarde UUIDs pro Sekunde für 85 Jahre generieren, um eine 50%ige Kollisionswahrscheinlichkeit zu erreichen), dass sie praktisch unmöglich ist.

Was UUID gut macht:

• Universeller Standard — jede Sprache, Datenbank und Framework hat native Unterstützung
• Keine Koordination nötig — jeder Server oder Client kann unabhängig generieren
• Nicht sequentiell — keine Enumerationsangriffe

Was UUID schlecht macht:

• Nicht sortierbar — UUIDs sind zufällig und sortieren sich nicht nach Erstellungszeit. In einem B-Tree-Index (wie die meisten Datenbanken funktionieren) verursachen zufällige Einfügungen „Page Splits" — die Datenbank reorganisiert ständig ihren Index. Im großen Maßstab ist das teuer.
• Groß: 36 Zeichen als String, 16 Byte binär
• Nicht URL-freundlich (enthält Bindestriche)

UUID v4 verwenden wenn: du eine Standard-ID mit breiter Unterstützung benötigst, ohne dir über Sortierreihenfolge Gedanken zu machen.

UUID v7 — Korrigiertes UUID

Format: 018e2c4c-3d12-7f3a-91f8-3e4a5b6c7d8e Länge: 36 Zeichen Zufälligkeit: 74 Bit (mit 48-Bit-Millisekunden-Timestamp-Präfix)

UUID v7 (ratifiziert 2023) ist UUID mit einem Timestamp-Präfix. Die ersten 48 Bits sind ein Unix-Timestamp in Millisekunden, wodurch UUIDs nach Erstellungszeit sortierbar werden.

Warum es wichtig ist: Sortierbare IDs = sequentielle Einfügungen im B-Tree = deutlich bessere Datenbankindex-Performance im großen Maßstab.

UUID v7 verwenden wenn: du UUID-Kompatibilität möchtest, aber zeitgeordnete IDs für Datenbankperformance benötigst.

ULID — Sortierbares und URL-sicheres UUID-Alternative

Format: 01ARZ3NDEKTSV4RRFFQ69G5FAV Länge: 26 Zeichen Zufälligkeit: 80 Bit (mit 48-Bit-Millisekunden-Timestamp-Präfix)

ULID (Universally Unique Lexicographically Sortable Identifier) löst das Sortierproblem von UUID mit einem saubereren Format. Es kodiert 48 Bit Timestamp + 80 Bit Zufälligkeit in Crockford Base32 (keine Bindestriche, keine mehrdeutigen Zeichen).

Was ULID gut macht:

• Lexikographisch sortierbar (sortiert korrekt als String)
• URL-sicher (keine Bindestriche oder Sonderzeichen)
• 26 Zeichen vs. 36 bei UUID — kompakter
• Eingebetteter Millisekunden-Timestamp

Was ULID schlecht macht:

• Weniger universell als UUID — erfordert Bibliothek in den meisten Sprachen
• Monotonie: mehrere ULIDs, die in der gleichen Millisekunde generiert werden, sortieren möglicherweise nicht korrekt ohne die monotone Variante

ULID verwenden wenn: du sortierbare IDs möchtest, die auch kompakt und URL-sicher sind, ohne UUID-Kompatibilität zu benötigen.

CUID2 — URL-sicher, kollisionsresistent, ohne Timestamp

Format: clyg4v5l20000356ok1f5t6nb Länge: 24 Zeichen (Standard) Zufälligkeit: hoch (SHA-3-Fingerprinting, keine vorhersehbare Struktur)

CUID2 ist für sicherheitssensible Kontexte konzipiert. Im Gegensatz zu ULID hat es absichtlich kein Timestamp-Präfix — man kann nicht ableiten, wann eine Ressource aus ihrer ID erstellt wurde.

Was CUID2 gut macht:

• Sicherer als UUID/ULID für öffentliche IDs (keine Timing-Informationen)
• URL-sicher
• Konfigurierbare Länge (Abwägung zwischen Länge und Kollisionsresistenz)

Was CUID2 schlecht macht:

• Nicht sortierbar (by Design)
• Weniger breit unterstützt als UUID
• Abhängig von einer spezifischen Bibliothek

CUID2 verwenden wenn: IDs öffentlich sind und du keine Erstellungs-Timestamps preisgeben möchtest (Benutzer-IDs, API-Schlüssel, Kurzlinks).

NanoID — Klein, schnell, anpassbar

Format: V1StGXR8_Z5jdHi6B-myT Länge: 21 Zeichen (Standard, konfigurierbar) Alphabet: anpassbar (Standard: Base64 URL-sicher)

NanoID ist eine moderne, schlanke Alternative zu UUID. Gleiche Kollisionswahrscheinlichkeit wie UUID v4 in 21 Zeichen, aber kleiner und mit anpassbarem Alphabet.

Was NanoID gut macht:

• Am kompaktesten (21 Zeichen vs. 36 bei UUID)
• Anpassbares Alphabet — kann IDs nur mit Kleinbuchstaben, nur mit Zahlen usw. generieren
• In 20+ Sprachen verfügbar
• Schnell

Was NanoID schlecht macht:

• Nicht sortierbar
• Kein Standard (kein RFC)

NanoID verwenden wenn: Größe wichtig ist (URLs, kurze Tokens) oder du ein benutzerdefiniertes Alphabet benötigst.

Entscheidungstabelle

Die einfache Antwort

• Standardwahl: UUID v7 — sortierbar, Standard, gute DB-Performance
• URL-sicher + sortierbar: ULID
• Öffentliche IDs (kein Timing preisgeben): CUID2
• Kurze Tokens, benutzerdefiniertes Alphabet: NanoID
• Legacy-System / maximale Kompatibilität: UUID v4

IDs jetzt generieren

UUID-Generator generiert UUID v4 und v7 — Massengenerierung, Ein-Klick-Kopieren. Kein Konto erforderlich.