UUID v4 erklärt: Warum zufällige IDs Auto-Increment schlagen

Was eine UUID v4 tatsächlich ist, warum das Kollisionsrisiko vernachlässigbar ist, und die konkreten Situationen, in denen sie eine einfache Auto-Increment-Integer-ID schlägt.

Eine UUID v4 ist ein 128-Bit-Identifikator, fast vollständig aus Zufallsbits erzeugt, formatiert als 32 Hex-Zeichen in 5 Gruppen (z. B. 3fa85f64-5717-4562-b3fc-2c963f66afa6). Die '4' markiert die Version und bedeutet, dass die ID keinerlei Information darüber trägt, wann, wo oder wodurch sie erzeugt wurde — was genau der Sinn ist.

Besteht nicht das Risiko, dass zwei IDs kollidieren?

Technisch ja, praktisch nein. Eine UUID v4 hat 122 zufällige Bits (6 Bits sind für Version und Variante fest), was etwa 5,3 x 10^36 mögliche Werte ergibt. Du müsstest rund 2,71 Trillionen UUIDs erzeugen, bevor eine 50%ige Chance auf eine einzige Kollision besteht. Für praktisch jede reale Anwendung ist dieses Risiko kleiner als die Wahrscheinlichkeit, dass ein Hardwarefehler die Daten ohnehin beschädigt.

Warum nicht einfach 1, 2, 3… wie ein Datenbank-Auto-Increment?

Ein Auto-Increment-Integer funktioniert innerhalb einer einzelnen Datenbank gut, verrät aber Informationen und bricht, sobald dein System wächst. Sequenzielle IDs erlauben jedem, benachbarte Datensätze durch bloßes Ändern einer Zahl in einer URL zu erraten (/orders/1042 → /orders/1043), verraten Wettbewerbern dein ungefähres Anmelde- oder Bestellvolumen und können nicht sicher von zwei verschiedenen Servern gleichzeitig erzeugt werden, ohne einen gemeinsamen Zähler — der zum Flaschenhals wird, sobald du horizontal skalierst.

Wann eine UUID klar die bessere Wahl ist

Jedes System mit mehreren unabhängigen Schreibern (Microservices, Offline-first-Mobile-Apps, verteilte Datenbanken) profitiert am meisten, da jeder Knoten eine gültige, eindeutige ID ohne jegliche Koordination und ohne zentralen Zähler erzeugen kann. Es ist auch die richtige Wahl, wenn eine ID nutzerseitig sichtbar werden könnte — Bestellreferenzen, API-Ressourcen-IDs, Dateinamen — wo sie nicht erratbar sein soll oder Reihenfolge-Informationen preisgeben darf.

Wann ein Integer immer noch die bessere Wahl ist

Für eine kleine Anwendung mit einem einzigen Schreiber, bei der IDs die Datenbank nie verlassen und du den kleinstmöglichen Speicherbedarf sowie die schnellsten Index-Lookups brauchst, ist ein einfacher Auto-Increment-Integer (oder sein geordneter Verwandter, UUID v7) immer noch einfacher und schneller. Die Zufälligkeit der UUID v4 ist auch ihr größter Nachteil beim Indexieren: da die Werte ungeordnet sind, fragmentieren sie einen B-Tree-Index weit stärker als eine sequenzielle ID.

Unser UUID-Generator erzeugt gültige, RFC-4122-konforme v4-UUIDs sofort und in großer Zahl, vollständig in deinem Browser — nützlich für Test-Fixtures, Mock-Daten oder einfach um eine sichere eindeutige ID zu wählen, ohne eine Datenbank aufzusetzen.