UUID v4 vs UUID v7 vs ULID vs NanoID: Welche ID sollten Sie verwenden?

Die Wahl des richtigen Formats für eindeutige Bezeichner für Ihre Anwendung ist eine Entscheidung, die die Datenbankleistung, Skalierbarkeit und Entwicklererfahrung beeinflusst. Mit UUID v7 als offiziellem Standard (RFC 9562, veröffentlicht 2024) hat sich die Landschaft der ID-Generierung erheblich verändert. Dieser Leitfaden vergleicht die vier beliebtesten Optionen.

Schnelle Vergleichstabelle

UUID v4: Der etablierte Standard

UUID v4 ist seit über einem Jahrzehnt die Standardwahl. Es generiert 128-Bit-Bezeichner mit 122 Bits Zufälligkeit und erzeugt das vertraute Format xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx.

Stärken:

• Universelle Bibliotheksunterstützung in jeder Programmiersprache
• Keine Koordination erforderlich — überall und jederzeit generieren
• Einfach und gut verstanden

Schwächen:

• Zufällige Verteilung verursacht B-Tree-Index-Fragmentierung in Datenbanken
• Keine Zeitinformation — Sortierung nach Erstellungsreihenfolge nicht möglich
• Bei großem Umfang (Millionen von Zeilen) verschlechtert sich die Insert-Leistung erheblich

// JavaScript
crypto.randomUUID();
// → "f47ac10b-58cc-4372-a567-0e02b2c3d479"

Probieren Sie unser UUID-Generator-Tool aus →

UUID v7: Der neue Standard (RFC 9562)

UUID v7, finalisiert in RFC 9562 (2024), ist speziell für den Einsatz als Datenbankschlüssel konzipiert. Es kombiniert einen 48-Bit-Unix-Zeitstempel (Millisekundengenauigkeit) mit 74 Bits Zufälligkeit und erzeugt zeitgeordnete UUIDs, die vollständig mit bestehender UUID-Infrastruktur kompatibel sind.

Stärken:

• Zeitgeordnet — sortiert natürlich nach Erstellungszeit
• Hervorragende Datenbank-Insert-Leistung (keine Index-Fragmentierung)
• Kompatibel mit allen bestehenden UUID-Spalten und -Tools
• Native Unterstützung in PostgreSQL 17+

Schwächen:

• Weniger zufällige Bits (74 vs 122) — immer noch astronomisch kollisionsresistent
• Zeitstempel ist eingebettet — zeigt ungefähre Erstellungszeit
• Bibliotheksunterstützung wächst noch (aber schnell)

// Node.js (uuid library v9+)
import { v7 as uuidv7 } from 'uuid';
uuidv7();
// → "018e4f5c-6a7b-7000-8000-1234abcd5678"
//    ^^^^^^^^^^^^^^^^ timestamp portion

ULID: Lexikographisch sortierbar

ULID (Universally Unique Lexicographically Sortable Identifier) ist älter als UUID v7 und teilt ein ähnliches Design: 48-Bit-Zeitstempel + 80 Bits Zufälligkeit. Der Hauptunterschied ist die Kodierung: Crockford Base32, die kompakte 26-Zeichen-Strings wie 01ARZ3NDEKTSV4RRFFQ69G5FAV erzeugt.

Stärken:

• Kompakte String-Darstellung (26 Zeichen vs 36 bei UUID)
• Eingebaute Monotonie — IDs, die in derselben Millisekunde generiert werden, sind trotzdem geordnet
• Lexikographisch sortierbar als Strings (kein spezieller Vergleich nötig)
• Groß-/Kleinschreibung-unabhängig und URL-sicher

Schwächen:

• Kein RFC-Standard — nur Community-Spezifikation
• Nicht kompatibel mit UUID-Spalten ohne Konvertierung
• Weniger Bibliotheksunterstützung als UUID

// JavaScript
import { ulid } from 'ulid';
ulid();
// → "01ARZ3NDEKTSV4RRFFQ69G5FAV"

NanoID: Kompakt und anpassbar

NanoID verfolgt einen anderen Ansatz: Anstelle eines festen Formats generiert es kompakte, URL-sichere Zufallsstrings mit einem konfigurierbaren Alphabet und konfigurierbarer Länge. Der Standard ist 21 Zeichen mit A-Za-z0-9_-.

Stärken:

• Sehr kompakt (standardmäßig 21 Zeichen, anpassbar)
• Standardmäßig URL-sicher
• Anpassbares Alphabet und Länge
• Winzige Bibliothek (~130 Bytes gzipped) — perfekt für das Frontend
• Kryptographisch stark (verwendet crypto.getRandomValues)

Schwächen:

• Keine Zeitordnung — gleiche B-Tree-Fragmentierungsprobleme wie UUID v4
• Keine Standardspezifikation
• Nicht kompatibel mit UUID-Infrastruktur

// JavaScript
import { nanoid } from 'nanoid';
nanoid();
// → "V1StGXR8_Z5jdHi6B-myT"

Entscheidungshilfe: Welchen sollten Sie wählen?

Verwenden Sie UUID v7, wenn:

• Sie eine neue Anwendung mit einer relationalen Datenbank erstellen
• Sie zeitgeordnete IDs für effiziente Indizierung benötigen
• Ihr System das Standard-UUID-Format erwartet (PostgreSQL, MySQL usw.)
• Sie das beste Gleichgewicht zwischen Kompatibilität und Leistung wünschen

Verwenden Sie UUID v4, wenn:

• Sie mit Systemen arbeiten, die nur UUID v4 unterstützen
• Sie maximale Zufälligkeit ohne Zeitstempel-Leck benötigen
• Die Datenbankgröße klein bis mittel ist (< 1M Zeilen)

Verwenden Sie ULID, wenn:

• Sie kürzere String-Darstellungen benötigen
• Sie mit Systemen arbeiten, die Strings lexikographisch sortieren
• Monotonie innerhalb derselben Millisekunde wichtig ist
• Sie keine UUID-Spaltenkompatibilität benötigen

Verwenden Sie NanoID, wenn:

• Sie IDs im Browser oder Frontend generieren
• Die Bundle-Größe wichtig ist (NanoID hat 130 Bytes)
• Sie kurze, URL-freundliche Bezeichner benötigen
• Sie URL-Shortener, Einladungscodes oder Session-Tokens erstellen

Leistungs-Benchmark: Datenbank-Inserts

Der wirkungsvollste Unterschied zwischen diesen Formaten ist die Datenbank-Insert-Leistung. Zeitgeordnete IDs (UUID v7, ULID) ermöglichen sequentielle B-Tree-Inserts, während zufällige IDs (UUID v4, NanoID) zufällige Seitenspaltungen verursachen:

Die Benchmark-Daten sind ungefähr und variieren je nach Hardware, Datenbankversion und Tabellenstruktur. Der relative Unterschied ist in allen Umgebungen konsistent.

Migrationspfad: UUID v4 zu UUID v7

Wenn Sie eine Migration von UUID v4 zu UUID v7 in Betracht ziehen, ist die gute Nachricht, dass beide dasselbe 128-Bit-Format und dieselbe String-Darstellung teilen. In den meisten Datenbanken können Sie beginnen, UUID v7-Werte für neue Zeilen zu generieren, während bestehende UUID v4-Werte gültig bleiben:

-- PostgreSQL 17+
CREATE TABLE users (
  id UUID DEFAULT gen_random_uuid_v7() PRIMARY KEY,
  name TEXT NOT NULL
);

-- Older PostgreSQL with uuid-ossp or pgcrypto
-- Use application-level UUID v7 generation