UUIDs und ULIDs dienen dazu, in verteilten Systemen und Datenbanken eindeutige IDs zu vergeben. Auf den ersten Blick ähneln sie sich, doch Standardisierung, Speicherlayout, Lesbarkeit und Informationslecks unterscheiden sich deutlich. Hier vergleiche ich die drei prominenten Varianten – UUID v4, UUID v7 und ULID – und ergänze Hinweise zu UUID v1 / v6.

Alle Tools zur Generierung und Zeitstempelauslese laufen komplett im Browser:

UUID v4: reine Zufallsvariante

UUID v4 nutzt von 128 Bit 122 Bit als Zufall – damit ist die Kollisionswahrscheinlichkeit extrem niedrig. Nachteil: keine Zeitreihensortierung. In B-Tree-Indizes entstehen häufiger Page-Splits, die Insert-Lokalität leidet. Ideal für Session-IDs oder One-Time-Keys, bei denen reine Zufälligkeit genügt.

UUID v7: sortierbare Evolution

UUID v7 wurde 2024 in RFC 9562 standardisiert. Die obersten 48 Bit enthalten den UNIX-Zeitstempel in Millisekunden, der Rest sind Zufallsbits. Dadurch gilt: Lexikografische Reihenfolge = Erzeugungsreihenfolge. Als Primärschlüssel bleiben Indizes lokal und stabil. Außerdem passt v7 in bestehende uuid-Typen oder BINARY(16).

  • Zufallsanteil: Bis auf Version/Variant-Bits bleiben rund 74 Bit Zufall. Manche Implementierungen nutzen monotone Erzeugung, um Kollisionen innerhalb derselben Millisekunde zu vermeiden – die statistische Zufälligkeit bleibt ausreichend.
  • Informationsleck: Aus einer v7 lässt sich der Erzeugungszeitpunkt in Millisekunden ableiten. Bei hoher Ausgabefrequenz und schwachem Zufall sind benachbarte IDs leichter zu erraten. Intern oft tolerierbar, bei öffentlichen Endpunkten kritisch.

ULID: menschenfreundliche Kennung

ULID wurde 2016 als de-facto-Standard publiziert. Die Darstellung nutzt Crockford Base32 mit 26 Zeichen und vermeidet verwechselbare Symbole (O/I/L/1). Wie v7 enthält ULID 48 Bit Zeitstempel (ms) am Anfang, somit entspricht die lexikografische Sortierung der Erzeugungszeit.

  • Sortiergarantie: Base32-Strings lassen sich immer chronologisch sortieren; monotone Generatoren sind verbreitet.
  • Speicherung: Als TEXT(26) ist ULID gut lesbar, für binäre Speicherung braucht es Base32↔16-Byte-Konvertierung. Häufig inkompatibel mit nativen UUID-Typen.
  • Informationsleck: Wie v7 legt ULID den Zeitstempel offen. Für öffentliche APIs, bei denen die Ausgabereihenfolge verborgen bleiben soll, nur mit Vorsicht einsetzen.

Vergleich aus Praxissicht

Kriterium UUID v4 UUID v7 ULID
Standardisierung RFC 4122 RFC 9562 (2024) Kein offizieller Standard (de facto)
Bit-Aufbau 128 Bit, davon 122 Bit Zufall 48 Bit UNIX-ms + Zufall (monoton möglich) 48 Bit UNIX-ms + 80 Bit Zufall
Zufallsentropie ≈ 122 Bit ≈ 74 Bit (abzüglich Version/Variant) 80 Bit
Zeichenrepräsentation 36 Zeichen (Hex + Bindestriche) 36 Zeichen (Hex + Bindestriche) 26 Zeichen (Crockford Base32)
Natürliche Sortierung (Text) ✗ (rein zufällig) ✓ (Lexikon = Zeit) ✓ (Lexikon = Zeit)
Natürliche Sortierung (Binär) ✗ ✓ (BINARY(16) big-endian) ✓ (bei 6 Byte-Zeitstempel vorn, big-endian)
DB-Speicherung uuid / BINARY(16) ideal uuid / BINARY(16) ideal TEXT(26) gut lesbar, BINARY(16) nur via Konvertierung; oft inkompatibel zu UUID-Typen
Index-Lokalität Schwach (zufällige Inserts) Gut (Append; Hotspots beobachten) Gut (Append; Hotspots beobachten)
Kosten für Gleichheitsabfragen Niedrig (16-Byte-Vergleich) Niedrig (16-Byte-Vergleich) Text etwas teurer (Collation); binär niedrig
Encode-/Decode-Aufwand Hex↔16 Byte (leicht) Hex↔16 Byte (leicht) Base32↔16 Byte (etwas höher)
Lesbarkeit / URL-Tauglichkeit Niedrig Niedrig Hoch
Zeitstempel offengelegt Nein Ja (ms) Ja (ms)
Typische Nutzung Session-ID, CSRF-Token DB-Primärschlüssel, Event-IDs, Log-Zeitreihen Öffentliche IDs, URLs, lesbare Log-Einträge

Hinweis zu Hotspots bei v7/ULID: Bei einem einzelnen Shard oder Leader kann das Append-Muster Hotspots erzeugen. Gegenmittel: leichte Shuffle-Strategien auf den oberen Bits („prefix shuffle“) oder zusätzliche Sharding-Keys.

Datenbanknotizen (PostgreSQL / MySQL / SQLite)

  • PostgreSQL
    • v4/v7: uuid-Typ verwenden, v7 als String einfügen und als uuid casten – Sortierung inklusive.
    • ULID: char(26)/text oder bytea(16) nach Base32-Konvertierung.
  • MySQL / InnoDB
    • BINARY(16) ist platzsparend und schnell (v4/v7). v7 bleibt big-endian sortierbar. ULID: CHAR(26) oder BINARY(16) mit Konvertierung.
  • SQLite
    • Kein spezieller UUID-Typ. BLOB(16) oder TEXT nutzen. Indexierte BLOBs funktionieren ordentlich.

Sicherheitshinweise

  • Vorhersagbarkeit: Bei v7/ULID teilen sich viele IDs denselben Zeitstempel. Schwache Zufallsquellen erhöhen das Risiko, Nachbar-IDs zu erraten. Setze auf kryptografische PRNGs und minimiere Muster bei monotonen Generatoren.
  • Metadaten-Leak: IDs verraten Zeitpunkt und ungefähr das Volumen. Für öffentliche APIs besser interne IDs von externen IDs trennen.

Zusammenfassung (Entscheidungshilfe)

  • UUID v4: Rein zufällig, minimale Kollisionswahrscheinlichkeit, keine Sortierung. Ideal für Sessions, Tokens, einmalige Verweise.
  • UUID v7: Standardisierte, sortierbare UUID. Optimal für Primärschlüssel und interne Events. Monotone Generatoren vermeiden Kollisionen innerhalb einer Millisekunde.
  • ULID: Menschenfreundlicher als UUID. Gute Wahl für URLs oder Logs; intern meist v7 überlegen. Monotone Generatoren verfügbar.

Exkurs: UUID v1 / v6 (Kurzfassung)

  • UUID v1 (Zeit + MAC): 60 Bit Zeitstempel (100 ns) plus Node-ID (oft MAC). Hohe Zeitlichkeit, aber MAC leakt Hostinfos, und Clock-Rollback macht Probleme. Heute aus Datenschutzgründen ungern genutzt.

  • UUID v6 (sortiertes v1): Reordnete v1-Bits für bessere Sortierung. In der Diskussion als „sortierbares v1“ – die Standardisierung mündete jedoch in v7. Für Neuentwicklungen gilt: lieber v7 statt v6.

Checkliste für Implementierungen

  • Zufallsquelle = kryptografischer PRNG des Betriebssystems.
  • Monotone v7/ULID-Generatoren vermeiden Kollisionen, dürfen aber keine erkennbaren Muster erzeugen.
  • In Datenbanken uuid/BINARY(16) bevorzugen, Collation-Fallen bei Text vermeiden.
  • Richtlinie für externe IDs festlegen (z. B. interne v7, externe Kurz-IDs) und ggf. trennen.

Fazit: v7 sollte in neuen Systemen Standard für interne Schlüssel sein. ULID bleibt attraktiv, wenn Lesbarkeit oder technische Zwänge zählen. Nur bei speziellen Anforderungen (kein Zeitstempel-Leak) bleiben v4 oder andere Verfahren im Rennen.