Kurz gesagt: UUID v4 ist die sichere Standardwahl für zufällige eindeutige IDs, ULID ist besser, wenn Sie auch nach Erstellungszeit sortierbare IDs wollen, und NanoID ist ideal, wenn Sie kurze, URL-taugliche IDs brauchen. Alle drei vermeiden Koordination zwischen Systemen, wägen aber Länge, Sortierbarkeit und Indexverhalten unterschiedlich ab. Dieser Leitfaden erklärt, was jede ist und wann man sie wählt.

Ein eindeutiger Bezeichner lässt unabhängige Systeme Datensätze anlegen, ohne einen zentralen Server zu fragen „Was ist die nächste Nummer?“. Diese Unabhängigkeit ist der Kern: Zwei Dienste oder zwei Offline-Geräte können je eine ID erzeugen und sicher sein, dass die Werte nicht kollidieren.

Was eine UUID wirklich ist

Eine UUID ist ein 128-Bit-Wert, üblich als 36 Zeichen geschrieben — 32 Hexadezimalziffern plus vier Bindestriche, wie 550e8400-e29b-41d4-a716-446655440000. Die Version, die Sie fast immer wollen, ist UUID v4, die 122 dieser Bits mit Zufall füllt. Das ergibt rund 5,3 × 10³⁶ mögliche Werte, eine Kollision müssen Sie also nicht einplanen: Sie müssten in der Größenordnung einer Trillion Werte erzeugen, bevor die Wahrscheinlichkeit auch nur 50 % erreicht.

„Vernachlässigbar“ ist nicht „unmöglich“, doch praktisch bietet v4 Eindeutigkeit ohne zentrale Koordination.

UUID v4 gegen v1

UUID v1 entsteht aus einem Timestamp plus der Netzwerkadresse (MAC) der erzeugenden Maschine. Das macht v1 grob zeitlich geordnet, kann aber verraten, wo und wann eine ID entstand — bisweilen ein Datenschutzthema. UUID v4 verzichtet darauf zugunsten reinen Zufalls: keine Ordnung, keine eingebetteten Metadaten, nichts zu verraten. Für die meisten Anwendungen ist v4 der richtige Standard, und v1 lohnt nur, wenn Sie gezielt seine Zeitkomponente wollen.

ULID: von Natur aus sortierbar

Eine ULID ist ebenfalls 128 Bit, aber als 26 Crockford-Base32-Zeichen kodiert statt Hex mit Bindestrichen. Die ersten 48 Bit sind ein Millisekunden-Timestamp, die restlichen 80 sind zufällig. Da der Timestamp vorn steht, sortieren ULIDs lexikografisch in Erstellungsreihenfolge: Sortieren Sie die Zeichenketten, erhalten Sie die chronologische Reihenfolge gratis. Das ist echt nützlich: „neueste zuerst“-Abfragen werden günstig und Datenbank-Inserts landen geordnet statt verstreut.

NanoID: kurz und URL-tauglich

Eine NanoID nutzt standardmäßig 21 Zeichen aus einem URL-sicheren Alphabet und passt so ohne Percent-Encoding in einen Link. Die Länge ist konfigurierbar, womit Sie Größe gegen Kollisionssicherheit abwägen: kürzere IDs sind aufgeräumter, lassen aber weniger Zufall, halten Sie sie also für öffentliche oder hochvolumige Bezeichner länger. NanoID glänzt bei Teilen-Links, kurzen öffentlichen IDs und überall, wo eine 36-Zeichen-UUID in einer URL sperrig wirkte.

Welche als Datenbankschlüssel?

Hier hat die Wahl echte Performance-Folgen. UUID v4 ist als Primärschlüssel völlig gültig, doch sein Zufall lässt neue Zeilen an zufälligen Positionen eines B-Tree-Index einfügen, was mit wachsender Tabelle Fragmentierung und mehr Page-Splits verursacht. Zeitgeordnete Bezeichner — ULID oder das neuere UUID v7 — fügen sich grob aufsteigend ein, was den Index kompakt und Schreibvorgänge lokal hält. Für einen Schlüssel einer großen, schreibintensiven Tabelle bevorzugen Sie eine zeitgeordnete ID; bei kleinen Tabellen zählt der Unterschied selten.

Häufige Fehler

  • Sequenzielle Ganzzahl-IDs öffentlich zeigen, wenn Sie unerratbare wollten — das ist Aufgabe einer zufälligen ID, nicht eines Auto-Increment.
  • Zufälliges UUID v4 als gruppierten Schlüssel einer riesigen Tabelle nutzen und sich dann über langsame Inserts wundern.
  • Eine UUID kürzen, um „Platz zu sparen“ — Sie werfen den Zufall weg, der Eindeutigkeit garantiert.
  • Eine NanoID für einen hochvolumigen Bezeichner zu stark kürzen und das Kollisionsrisiko erhöhen.

Passen Sie die ID zum Zweck: Nutzen Sie den UUID-Generator, um v4-, v1-, ULID- oder NanoID-Werte zu erzeugen, wählen Sie v4 für allgemeine Eindeutigkeit, ULID wenn die Reihenfolge zählt und NanoID wenn die ID in einer URL leben muss.