UUID-v7-Generator

Jahrelang mussten Ingenieurteams, die die Kollisionsresistenz einer UUID wollten, aber die indexfreundliche Ordnung einer sequenziellen Ganzzahl, ihren eigenen nicht-standardmäßigen Hybrid bauen — üblicherweise eine zufällige UUID mit einem manuell generierten Zeitstempel voranstellend, ein Ansatz, den mehrere bekannte Unternehmen verteilter Systeme in verschiedenen Formen nutzten, bevor irgendein offizieller Standard dafür existierte. RFC 9562 formalisierte dieses Muster in eine offizielle UUID-Version speziell, damit Implementierungen über verschiedene Sprachen und Datenbanken hinweg dieselbe zeitlich geordnete Struktur erzeugen und erkennen können, ohne dass jedes Team unabhängig eine leicht unterschiedliche, inkompatible Variante derselben Idee neu erfindet.

Die führenden 48 Bits einer UUID v7 kodieren einen Unix-Zeitstempel in Millisekunden, was dem Wert seine Sortierreihenfolge gibt — zwei UUID-v7-Werte als flache Zeichenketten zu vergleichen spiegelt korrekt wider, welche zuerst generiert wurde, da der Zeitstempelanteil den Vergleich dominiert. Die restlichen Bits bleiben mit kryptografisch zufälligen Daten gefüllt, exakt wie bei v4, daher ist der Wert genauso resistent gegen Erraten, wie es eine vollständig zufällige UUID wäre; nur ihr Sortierverhalten ändert sich, nicht ihre Unvorhersehbarkeit.

Über die reine Einfügegeschwindigkeit hinaus hat ein zeitlich geordneter Primärschlüssel einen zweiten praktischen Vorteil, der Tag für Tag zählt: Zeilen kommen natürlich in Erstellungsreihenfolge aus einer einfachen `ORDER BY id`-Abfrage zurück, ohne eine separate `created_at`-Spalte und einen zusätzlichen Index darauf zu brauchen, nur um Datensätze chronologisch zu sortieren. Für eine Tabelle, die häufig „neueste zuerst" abgefragt wird — ein Aktivitätsprotokoll, eine Warteschlange, eine Audit-Spur — gibt ein v7-Primärschlüssel diese Sortierung als Nebeneffekt der ID selbst kostenlos, statt als separate zu pflegende Kosten.