UUID Generator

Was ist eine UUID?

Eine UUID (Universally Unique Identifier, RFC 4122 / RFC 9562) ist eine 128-Bit-Kennung, die ohne zentrale Vergabestelle erzeugt wird und trotzdem global praktisch eindeutig ist. Die textuelle Darstellung sind 32 Hexziffern, in fünf Gruppen `8-4-4-4-12` per Bindestrich getrennt, also 36 Zeichen inklusive Trennzeichen.

Es gibt mehrere Versionen. v1 verwendet Zeit + MAC-Adresse (Privacy-Risiko), v3 und v5 leiten die ID aus einem Namen plus Namespace ab (deterministisch), v4 ist rein zufällig (heute der Standard), v7 ist zeitgeordnet und löst das Datenbank-Index-Problem von v4.

Daneben sind ULID und NanoID populäre, nicht-IETF-standardisierte Alternativen. ULID ist eine sortierbare 26-Zeichen-Zeichenkette, NanoID eine kurze, URL-sichere ID (oft 21 Zeichen). Welche Variante du wählst, hängt vor allem vom geplanten Storage und vom URL-Layout ab.

v4 vs. v7 vs. ULID vs. NanoID

Eine schnelle Übersicht der vier wichtigsten Varianten:

Crockford-base32 (ULID) lässt I, L, O und U weg, um Verwechslungen mit 1, 0 und V zu vermeiden.

Wann nutze ich welche Variante?

Faustregeln aus der Praxis:

• UUID v4: gute Default-Wahl für nicht-sortierte IDs (z. B. Sessions, Idempotency-Keys, Korrelationskennungen). 122 Bit Entropie, Kollisionswahrscheinlichkeit absurd niedrig.
• UUID v7: empfohlen für Datenbank-Primary-Keys. Die ersten 48 Bits sind ein Unix-ms-Timestamp, dadurch werden neue Einträge in B-Tree-Indizes ans Ende geschrieben (geringer Page-Split-Druck, gute Locality).
• ULID: wenn du eine zeitgeordnete ID brauchst, die in URLs und Logs lesbar bleibt. 26 Zeichen, kürzer als UUID, aber kein RFC-Standard. Bei manchen Tooling-Stacks fehlt nativer Support.
• NanoID-21: ideal für sichtbare Share-Links und Slugs. 21 Zeichen, URL-safe, ungefähr 126 Bit Entropie, also sicherer als UUID v4 bei deutlich kürzerer Darstellung.

Warum keine Auto-Increment-IDs in Production?

Auto-Increment-IDs (z. B. `BIGINT IDENTITY` oder `SERIAL`) sind einfach, schnell und Index-freundlich, scheitern aber an mehreren modernen Anforderungen:

• Verraten Geschäftsmetriken: ein Wettbewerber sieht aus zwei aufeinanderfolgenden Bestellungen, wie viele Bestellungen pro Tag laufen.
• Bieten keinen Bot-Schutz: `/users/123` lädt der nächste Brute-Force-Crawler einfach von 1 bis n hoch, jede ID ist trivial enumerierbar.
• Behindern verteilte Systeme: in einem Multi-Region-Setup oder bei Offline-Clients (Mobile-Apps, Edge) muss man entweder Sequenzen koordinieren oder einen zentralen ID-Service betreiben. UUIDs vermeiden das komplett.
• Sind nicht client-vergebbar: ein Frontend kann keine Auto-Increment-ID vor dem INSERT vergeben (z. B. für Optimistic-UI). UUIDs werden im Client erzeugt und mit `INSERT` durchgereicht.
• Sind nicht testfreundlich: Tests, die Daten zurückrollen, kollidieren mit Sequence-Werten oder hinterlassen Lücken. UUIDs sind in Tests stabil.

Empfehlung: Auto-Increment für interne, rein operative Tabellen (Migrations-Log, Counter), UUID v7 als Default-Primary-Key für Domain-Entitäten (User, Order, Document).

UUID-Performance in Datenbanken

Der häufigste Einwand gegen UUIDs lautet "die zerstören mir die Index-Performance". Stimmt teilweise, ist aber entweder leicht zu lösen oder mit v7/ULID gänzlich vermieden.

Das eigentliche Problem ist nicht die Größe (16 Bytes vs. 8 Bytes Bigint), sondern die Random-Insert-Reihenfolge: bei v4 landet jeder Insert irgendwo mitten im B-Tree-Index, was Page-Splits, kalte Caches und Write-Amplification erzeugt.

• Lösung 1: UUID v7 oder ULID statt v4 verwenden. Die zeitgeordneten Bits sorgen dafür, dass neue Einträge ans Tail des Index geschrieben werden.
• Lösung 2: in PostgreSQL den `uuid` Typ und in MySQL `BINARY(16)` (statt `CHAR(36)`) speichern, das spart 20 Byte pro Row und macht den Vergleich integer-schnell.
• Lösung 3: clustered Index gezielt auf einen anderen Schlüssel (z. B. monoton steigend) und UUID als Secondary-Key. Vor allem in MS SQL Server gängig.
• Lösung 4: bei Massen-Inserts ggf. in Sortier-Reihenfolge inserten oder Bulk-Loader nutzen, der den Index am Ende rebuildet.

In aktuellen Postgres- und MySQL-Versionen ist UUID v7 als Primary-Key in den allermeisten Workloads schneller als v4 und mit Bigint-Auto-Increment vergleichbar, während die Vorteile (kein Leak, verteilt erzeugbar, client-side) erhalten bleiben.

Hochdurchsatz-Backends bei KernelHost

Wer Millionen UUIDs pro Tag in einer Datenbank speichert, braucht NVMe-Storage, ECC-RAM und stabile Netzanbindung. KernelHost betreibt eigene Dedicated- und VPS-Server in Frankfurt FRA01 mit DDoS-Schutz, IPv4 + IPv6 sowie 1 Gbit/s. Niedrige RTT zu deutschen und österreichischen Kunden, faire Preise. Firmensitz Wien (AT), Rechenzentrum Frankfurt (DE).

Häufige Fragen zu UUIDs