Die Entscheidung „Wir verwenden UUID“ ist unvollständig. Verschiedene Versionen verteilen die 128 Bits nach unterschiedlichen Regeln und liefern damit andere Eigenschaften. Für viele Jahre war UUIDv4 der naheliegende Standard. UUIDv7 bietet inzwischen zeitliche Sortierbarkeit, während namenskodierte Versionen deterministische Zuordnungen ermöglichen. Die richtige Wahl folgt Zugriffsmustern, Datenschutz und Kompatibilität, nicht bloß Neuheit.

UUIDv4 ist der bekannte Zufallsstandard

Version 4 verwendet fast alle verfügbaren Bits für Zufall. Sie verrät keine Erstellungszeit und lässt sich unabhängig auf jedem Host generieren. Gute Systembibliotheken machen sie unkompliziert und interoperabel.

Der Nachteil liegt vor allem in geordneten Datenbankindizes. Neue Werte verteilen sich zufällig über den Schlüsselraum. Bei moderatem Volumen ist das oft unproblematisch; bei intensiven Inserts sollte es gemessen werden.

UUIDv7 verbindet Zeitordnung und Zufall

Version 7 beginnt mit einem Unix-Zeitanteil in Millisekunden und ergänzt Zufallsbits. Neuere IDs liegen dadurch ungefähr hinter älteren, was B-Tree-Inserts und zeitliche Listendarstellungen verbessern kann. Gleichzeitig bleibt dezentrale Erzeugung möglich.

Der Timestamp macht die ungefähre Erstellungszeit sichtbar. Das kann bei internen Ressourcen hilfreich und bei öffentlich sensiblen Objekten unerwünscht sein. Autorisierung bleibt in beiden Fällen zwingend.

UUIDv7 ist keine globale Sequenz

Mehrere IDs in derselben Millisekunde und verschiedene Hosts brauchen zusätzliche Zufalls- oder Monotonieeigenschaften der Bibliothek. Uhren können rückwärts springen. Die resultierende Reihenfolge ist praktisch nützlich, aber keine transaktionale oder kausale Garantie.

Wer eine lückenlose Reihenfolge benötigt, braucht eine Datenbanksequenz, Logposition oder ein anderes Koordinationsverfahren. Ein Zeitstempel im Identifier ersetzt diese Systeme nicht.

Namensbasierte UUIDs liefern reproduzierbare Werte

UUIDv5 und neuere namenskodierte Varianten leiten aus Namespace und Name deterministisch eine ID ab. Derselbe Input erzeugt denselben Wert. Das ist nützlich für Imports, Standardobjekte und stabile Abbildungen externer Schlüssel.

Namespace und Normalisierung sind Teil des Vertrags. Großschreibung, Unicode und Whitespace müssen vor der Ableitung eindeutig behandelt werden. Sonst erzeugen semantisch gleiche Namen verschiedene IDs.

Deterministisch bedeutet nicht geheim

Kennt ein Angreifer Namespace und mögliche Namen, kann er die UUIDs selbst berechnen. Namensbasierte IDs eignen sich nicht als Zugangstoken und verbergen niedrige externe Nummern nicht zuverlässig.

Für eine öffentliche, nicht ableitbare Identität ist zufällige Erzeugung geeigneter. Für reproduzierbares Mapping ist die Deterministik dagegen gerade der Vorteil.

Ältere zeitbasierte Versionen besitzen Altlasten

UUIDv1 kombiniert Zeit mit einer Node-Komponente, die historisch aus einer MAC-Adresse stammen konnte. Das kann Geräteinformationen und Erstellungszeit offenlegen. Moderne Bibliotheken können Zufallswerte verwenden, doch bestehende Verträge müssen genau verstanden werden.

UUIDv6 ordnet ähnliche Informationen indexfreundlicher. Für neue Systeme ist v7 häufig leichter zu erklären, sofern die Zielplattform sie unterstützt.

Kompatibilität muss praktisch getestet werden

Ein alter Validator akzeptiert möglicherweise nur Version 4, obwohl seine Spalte jeden 128-Bit-UUID-Wert speichern könnte. SDKs, Gateways, Analytics und Partnerintegrationen können Versionsbits unnötig einschränken.

Vor einem Rollout von v7 sollte eine begrenzte Tabelle oder ein Dienst neue Werte erzeugen. Metriken und Contract Tests zeigen Ablehnungen. Historische IDs bleiben gültig; geändert wird nur die Erzeugung neuer Werte.

Eingabe- und Ausgabepolicy sind verschieden

Ein Dienst kann neue v7-IDs erzeugen und weiterhin v4 aus alten Daten akzeptieren. Eine starre „nur aktuelle Version“-Validierung würde Migrationen und importierte Referenzen brechen. Erlaubte Eingaben folgen dem realen Datenbestand.

Die Ausgabe sollte eine kanonische Textform besitzen. Clients dürfen die Version nicht aus Stringmustern erraten, wenn sie fachlich keine Rolle spielt.

Datenschutz hängt vom gesamten Endpoint ab

v4 verbirgt den Zeitpunkt besser als v7, doch eine API kann denselben Zeitpunkt in created_at, Sortierung oder Seitencursor offenlegen. Umgekehrt ist eine sichtbare Erstellungszeit bei öffentlichen Artikeln möglicherweise völlig unkritisch.

Das Threat Model betrachtet Ressource, Metadaten und Zugriff zusammen. Die UUID-Version allein kann keine Privatsphäre garantieren.

Benchmarks müssen das echte Schema verwenden

Die Geschwindigkeit des Generators ist selten entscheidend. Relevant sind Insert-Rate, Indexgröße, Joins, Replikation, Cache und Backup. Nativer UUID-Typ, Binärdarstellung und Byteordnung beeinflussen Ergebnisse.

Auch betriebliche Fragen zählen: Lassen sich Werte in Logs kopieren? Ist zeitliche Sortierung im Support hilfreich? Performance ist eine Eigenschaft unter mehreren.

Eine Migration schreibt bestehende IDs nicht neu

Primärschlüssel zu ersetzen bedeutet Foreign Keys, externe Links, Events und Caches zu aktualisieren. Der Nutzen einer neuen Version rechtfertigt dieses Risiko fast nie. Neue Datensätze können ab einem Stichtag die neue Policy nutzen.

Gemischte Fixtures schützen die Übergangsphase. Tests sollten alte und neue Versionen, kanonische Darstellung und ungültige Werte enthalten.

Rollout und Rückfall müssen vorab definiert sein

Ein schrittweiser Rollout kann zunächst nur einen internen Ressourcentyp oder einen kleinen Prozentsatz neuer Datensätze umstellen. Dashboards sollten Ablehnungen nach Client, Endpoint und UUID-Version zeigen. So wird ein veralteter Validator sichtbar, bevor er den gesamten Schreibpfad blockiert.

Ein Rückfall bedeutet normalerweise, wieder v4 für neue Datensätze zu erzeugen, nicht bereits ausgegebene v7-Werte zu ersetzen. Alle Consumer müssen deshalb dauerhaft mit der gemischten Population umgehen können. Diese Asymmetrie sollte in Migrationsplan und Tests ausdrücklich stehen.

Metadatenleckage muss konkret bewertet werden

Der Zeitanteil von v7 kann ungefähre Erstellungsfenster und relative Aktivität verraten. Bei öffentlich sichtbaren Bestellungen oder vertraulichen Workflows kann das unerwünscht sein. Bei Logs, Events oder internen Datensätzen verbessert dieselbe Eigenschaft Diagnose und Indexverhalten.

Die Bewertung sollte sich auf reale Angreifer und bereits sichtbare Metadaten beziehen. Ein pauschales Verbot ignoriert Nutzen, eine pauschale Einführung ignoriert Datenschutz. Bei Bedarf kann eine separate zufällige öffentliche ID die interne v7-Identität abschirmen.

Die Entscheidung endet in einer gemeinsamen Konvention

Teams sollten Bibliothek, Version, Storage und akzeptierte Eingaben dokumentieren. Sonst erzeugt jeder Dienst trotz koordinationsfreier Technik eine eigene inkompatible Variante.

v4 ist ein starker Default für zufällige, zeitlich undurchsichtige IDs. v7 passt zu index- und zeitordnungsorientierten Systemen. Namensbasierte Versionen passen zu reproduzierbaren Abbildungen. Die passende Wahl ist diejenige, deren Eigenschaften das konkrete System wirklich nutzt.