UUID vs ULID vs CUID Welche eindeutige ID sollten Sie verwenden?

Jede Datenbankzeile, jeder API-Ressource, jeder verteilten Ereignis benötigt eine ID. Das Problem ist nicht die Erzeugung einer ID – es ist die Wahl eines Formats, das nicht in sechs Monaten, wenn die Postgres-Indizes fragmentiert sind und die URLs wie Rauschen aussehen, zu Problemen führt.

Hier ist die vollständige Vergleich der UUID-Generatoren: UUID v4, UUID v7, ULID, CUID2 und Snowflake – was sie sind, wo sie versagen und welche Sie tatsächlich verwenden sollten.

UUID v4: Die sichere Standardlösung (mit einem großen Problem)

UUID v4 besteht aus 128 Bit Zufallszahlen, formatiert als 550e8400-e29b-41d4-a716-446655440000. Es wird überall verstanden, unterstützt in jeder Sprache, jeder Datenbank und jedem ORM der Welt.

Die Wahrscheinlichkeit für einen Zusammenstoß ist praktisch null – man müsste eine Milliarde UUIDs pro Sekunde für 85 Jahre erzeugen, bevor man eine 50% Chance auf einen Zusammenstoß erreicht. Das ist im Praxis nicht ein Problem.

Das Problem ist die Ordnung. UUID v4 ist vollkommen zufällig, was bedeutet, dass die Einfügung von Zeilen in eine UUID-indizierte Tabelle die Schreibvorgänge über das B-Tree verteilt. Bei Skalierung führt das zu Seitenspalten, Indexfragmentation und verschlechterter Einfügeleistung. Wenn Sie Tausende von Zeilen pro Sekunde in eine MySQL- oder Postgres-Tabelle mit UUID-Primärschlüssel einfügen, werden Sie das spüren.

UUID v4 ist auch 36 Zeichen lang als String – nicht URL-sicher ohne Codierung und größer als Alternativen.

UUID v7: Das bessere Bruder von UUID v4

UUID v7 behebt das Probleme der Ordnung. Es ist ein zeitgesteuertes UUID, bei dem die höchsten Bits einen Millisekunden-Timestamp codieren und der Rest zufällig ist. Das Ergebnis: 01875f3a-7b2d-7f8e-a3d1-4b2e6c1a0f93.

Zeilen, die in zeitlicher Reihenfolge eingefügt werden, bleiben im Index annähernd sequentiell. Das ist ein großer Vorteil für schreibintensive Workloads. UUID v7 ist mit allen bestehenden UUID-Infrastrukturen kompatibel – gleicher Format, gleiche Feldlänge, gleiche Library-Unterstützung – und fügt die Sortierbarkeit hinzu.

Der RFC wurde 2022 abgeschlossen und die Library-Unterstützung folgt schnell. Wenn Sie bereits UUIDs verwenden und Ihre Schema nicht ändern können, ist der Wechsel von v4 zu v7 ein geringes Risiko und hoher Gewinn.

ULID: Die am freundlichsten für Entwickler geeignete Option

ULID (Universally Unique Lexicographically Sortable Identifier) kodiert einen 48-Bit-Timestamp und 80 Bit Zufall in 26 Base32-Zeichen: 01ARZ3NDEKTSV4RRFFQ69G5FAV.

Was es auszeichnet:

• Standardmäßig sortierbar – ein lexicographisches Sortieren ist ein chronologisches Sortieren
• URL-sicher – ohne Bindestriche, ohne Sonderzeichen
• Groß-/Kleinschreibung wird nicht beachtet – vermeidet die 0/O und 1/I Unklarheit, indem diese Zeichen aus dem Alphabet ausgeschlossen werden
• Kompakt – 26 Zeichen statt 36 für eine UUID-Zeichenkette

ULID ist die praktischste Wahl für neue Projekte, die keine Legacy-Beschränkungen haben. Es ist sortierbar genug für die meisten Anwendungsfälle, kurz genug für URLs und lesbar genug, dass ein Mensch es kopieren und einfügen kann, ohne Transkriptionsfehler zu machen.

Eine Vorsichtsmaßnahme: Wenn Sie mehrere ULIDs innerhalb derselben Millisekunde erzeugen, ist die monotonen Sortierreihenfolge pro-Prozess garantiert, aber nicht über mehrere verteilte Knoten hinweg. Für die meisten Anwendungen ist das ausreichend.

CUID2: Entwickelt für verteilte Systeme

CUID2 ist die Nachfolger von CUID, neu entworfen für Sicherheit und Kollisionssicherheit in verteilten Umgebungen. Ein CUID2 sieht aus wie: clh3uj5ln0000qzrmn831mbhe.

Es verwendet einen SHA-3-Hash aus einer Kombination aus Zeitstempel, Counter, Fingerprint (Prozess-ID + Hostname) und zufälligen Bytes. Der Fingerprint ist der entscheidende Unterschied – er wurde speziell entwickelt, um Kollisionen zu verhindern, wenn Sie viele ID-Generatoren gleichzeitig auf vielen Servern laufen.

CUID2 ist nicht sortierbar. Es priorisiert Kollisionssicherheit und Unvorhersehbarkeit gegenüber zeitlicher Ordnung. Wenn Sie ein System bauen, bei dem IDs von unvertrauenswürdigen Clients oder über viele unabhängige Knoten generiert werden und Sicherheit eine Rolle spielt, ist CUID2 eine lohnende Abwägung.

Für die meisten Backend-APIs ist es übertrieben.

Snowflake-IDs: Hohe Durchsatzleistung, aber Sie müssen es selbst regeln

Snowflake-IDs wurden bei Twitter entwickelt, um einzigartige IDs bei Millionen pro Sekunde in einem verteilten Cluster zu generieren. Ein Snowflake-Id ist eine 64-Bit-Ganzzahl: Zeitstempel (41 Bit) + Datencenter-ID (5 Bit) + Maschinen-ID (5 Bit) + Sequenz (12 Bit).

Sie sind sortierbar, kompakt (passt in ein BIGINT) und äußerst schnell. Discord, Instagram und viele hochskalierbare Systeme verwenden diesen Muster.

Die Schwierigkeit: Sie müssen Maschinen-IDs verwalten. Das bedeutet ein Koordinations-Service (ZooKeeper, etcd, eine Datenbanktabelle), um einzigartige Maschinen-IDs an jedes ID-Generator zu vergeben. Wenn zwei Knoten dieselbe Maschinen-ID teilen, entstehen Kollisionen. Die korrekte Einrichtung ist nicht trivial, und die Wartung ist eine operativen Belastung.

Es ist nicht lohnenswert, wenn Sie nicht Tausende von IDs pro Sekunde generieren.

Der Vergleich

Die Generierung jeder ID in Node.js

// UUID v4
import { v4 as uuidv4 } from 'uuid';
console.log(uuidv4()); // '9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d'

// UUID v7
import { v7 as uuidv7 } from 'uuid';
console.log(uuidv7()); // '01875f3a-7b2d-7000-8000-4b2e6c1a0f93'

// ULID
import { ulid } from 'ulid';
console.log(ulid()); // '01ARZ3NDEKTSV4RRFFQ69G5FAV'

// CUID2
import { createId } from '@paralleldrive/cuid2';
console.log(createId()); // 'clh3uj5ln0000qzrmn831mbhe'

// Snowflake (using @socialgouv/nextid for simplicity)
import Snowflake from '@socialgouv/nextid';
const snowflake = new Snowflake(1n); // machine ID = 1
console.log(snowflake.nextId().toString()); // '1641024000000000001'

Sie können die UUID-Generierung direkt mit dem IO Tools UUID-Generator – es unterstützt UUID v1 bis v7 und ermöglicht Bulk-Generierung ohne Installation von Dingen.

Welche sollte man verwenden?

Hier ist die tatsächliche Empfehlung, nicht die „es hängt davon ab“-Version:

• Neues Projekt, keine Legacy-Beschränkungen: Verwenden Sie ULID. Sortierbar, URL-sicher, kompakt. Es ist die beste Standardlösung.
• Bereits UUIDs verwendet, braucht bessere DB-Leistung: Wechsel zu UUID v7. Ein einfacher Austausch, riesiger Indexgewinn.
• IDs, die von Clients oder über unvertrauenswürdige verteilte Knoten generiert werden: Verwenden Sie CUID2. Die Fingerprinting-Mechanismen machen die Kollisionssicherheit robust, selbst unter feindlichen Bedingungen.
• Hohe Durchsatzplattform (100.000+ IDs pro Sekunde), bereit, Maschinen-IDs zu verwalten: Verwenden Sie Snowflake. Andernfalls ist es nicht nötig.
• UUID v4: Nur wenn Sie Legacy-Code pflegen und das Format nicht ändern können. Verwenden Sie es nicht für neue Tabellen.

Die Ära, die standardmäßig UUID v4 für alles verwendet, ist vorbei. ULID ist die neue Standardlösung für die meisten Anwendungsfälle, und UUID v7 ist der richtige Upgrade-Pfad, wenn Sie bereits in der UUID-Welt sind. Wählen Sie eine und gehen Sie davon aus.

Das könnte Ihnen auch gefallen

Neu

PDF Signature Verification: What Developers Need to Know

Mehr lesen "

Veröffentlicht am Mai 10, 2026

Neu

Markdown vs HTML: Wann jede für Dokumente, README-Dateien und APIs verwenden

Mehr lesen "

Veröffentlicht am 9. Mai 2026

Neu

UTM-Parameter: Wie man Marketing-Kampagnen ohne Spekulation verfolgt

Mehr lesen "

Veröffentlicht am 8. Mai 2026

Neu

Farbbarriere für Entwickler: Kontrast, Simulation von Sehbehinderungen und Fehlerbehebung

Mehr lesen "

Veröffentlicht am 7. Mai 2026