UUID vs. NanoID

Anatomie: was in jeder ID steckt

UUIDs kodieren ihre eigenen Metadaten. Die Bits 48–51 tragen die Version – 1 für Zeit plus MAC, 4 für zufällig, 7 für zeitgeordnet zufällig – und zwei weitere Bits legen die Variante fest. Eine v4 sieht immer zufällig aus; eine v7 beginnt mit einem lesbaren Zeitstempel, weil ihre ersten 48 Bits Millisekunden seit der Unix-Epoche sind und UUIDs, die am selben Tag geprägt wurden, ein gemeinsames Präfix teilen.

NanoIDs tragen keine Metadaten. Jedes Zeichen ist ein unabhängiger Zug aus dem Alphabet, gewählt mit Maskierung und Reject Sampling über crypto.getRandomValues, sodass jedes Symbol gleichwahrscheinlich bleibt. Diese Reinheit ist der Grund, warum das Format flexibel ist – Alphabet oder Länge ändern, Algorithmus behalten – und warum ein NanoID nichts darüber verrät, wann er erzeugt wurde.

Kollisionsrechnung: warum keiner von beiden jemals kollidiert

Die Geburtstagsformel sagt, dass ein n-Bit-Zufallsbezeichner bei etwa 2^(n/2) Zügen eine Kollisionswahrscheinlichkeit von 50 Prozent erreicht. Für UUID v4 sind das rund 2^61 – etwa 2,3 Trillionen IDs –, bevor die Chancen eines einzigen Duplikats die Hälfte erreichen; NanoIDs 126 Bits schieben die Latte noch etwas höher. In der Praxis sind beide Systeme, bei denen es nie passiert – jedes Duplikat, dem Sie begegnen, ist ein Codefehler, kein Entropie-Ereignis.

Diese Gleichwertigkeit ist der Grund, warum die Größen-Debatte weniger wichtig ist als angenommen: 21 NanoID-Zeichen sind nicht sicherer als eine v4-UUID – dieselbe Garantie in weniger Bytes. Die ehrlichen Gründe für die Wahl sind operative Passung – Speicherplatz, URLs, Tooling –, nicht das Kollisionsrisiko.

Datenbanken: das Problem der Index-Lokalität

Fügen Sie einen zufälligen Schlüssel in einen B-Tree-Index ein, kann die Zeile auf jeder beliebigen Seite landen; füllen Sie Seiten zur Hälfte in zufälliger Reihenfolge, riskiert jeder Einfügevorgang eine Seitenaufteilung, zusätzliche Schreibvorgänge und einen kälteren Cache. Das ist die Fragmentierungs-Steuer, die sowohl UUID v4 als auch NanoID zahlen – NanoID eingeschlossen, denn es ist genauso zufällig. Auf einem indizierten Primärschlüssel bei schreiblastiger Last ist keiner von beiden standardmäßig indexfreundlich.

UUID v7 ist die Korrektur, die der Standard selbst mitliefert: Ihre führenden 48 Bits sind ein Millisekunden-Zeitstempel, daher sortieren neue Schlüssel fast immer an den rechten Rand des Index. NanoID kann das nicht bieten: keine Zeitkomponente, nichts zum Sortieren. In einer indizierten Spalte ist die echte Wahl v7 gegen alles andere.

• v4 und NanoID verteilen Einfügevorgänge über den ganzen Baum – Seitenaufteilungen und Cache-Misses bei Skalierung.
• Postgres' uuid-Typ speichert 16 rohe Bytes; ein 36-Zeichen-Textschlüssel speichert 37 oder mehr.
• NanoIDs Textvorteil – 21 Zeichen gegenüber 36 – hält nur, solange das Alphabet dokumentiert bleibt.

URLs, Alphabete und der Längen-Regler

NanoIDs Alphabet ist von Konstruktion her URL-sicher: A-Za-z0-9_- braucht nirgendwo in einer URL Prozent-Kodierung, also kann eine ID ein Pfadsegment, ein Query-Wert oder ein Slug ohne jede Escapung sein. UUIDs sind technisch ebenfalls URL-sicher – Hex-Ziffern und Bindestriche brauchen nie eine Kodierung –, aber 36 Zeichen sind viel sichtbarer String für einen Link.

Das eigene Alphabet ist NanoIDs praktischstes Feature: nur Ziffern, Kurzlinks in Kleinschreibung – die 64 Symbole austauschen, den Algorithmus behalten. Beachten Sie die Regel, dass Entropie Länge mal log2 der Alphabetgröße ist: Ein NanoID mit 8 Zeichen in Kleinschreibung hat etwa 38 Bit, gut für einen Ein-Stunden-Code, fahrlässig als Primärschlüssel. UUIDs bieten einen solchen Regler nicht; das Format ist auf 128 Bit fixiert.

Wann Sie was wählen

Wählen Sie UUIDs, wenn die ID in Infrastruktur lebt: Datenbank-Primärschlüssel (v7), Austausch zwischen Teams und Anbietern, alles, was ein Dritter validieren muss, überall dort, wo eine eingebaute Lösung eine Abhängigkeit schlägt. Der Standard ist das Produkt – jede Sprache, jedes ORM und jede Datenbank spricht ihn bereits.

Wählen Sie NanoID, wenn die ID für Nutzer sichtbar ist: kurze URLs, Einladungslinks, Dateinamen, Cookie-Werte, Request-IDs in Logs. Die Empfehlung kehrt sich sauber um – wenn Sie permanent gegen die Breite einer UUID in einer URL ankämpfen, will dieser Link NanoID; wenn Sie sich dabei ertappen, NanoID in einem Backend neu zu implementieren, dessen Datenbank Schlüssel nativ liefern könnte, will diese Spalte eine v7-UUID.