UUID-v7-Generator

Erzeugen Sie in großer Zahl UUID v7 in Ihrem Browser — den RFC-9562-Standard mit einem eingebetteten 48-Bit-Zeitstempel in Millisekunden, wodurch IDs nach Erzeugungsreihenfolge sortierbar sind. Standard-, Großbuchstaben-, Format ohne Bindestriche, mit geschweiften Klammern und URN-Format werden unterstützt, und die IDs passen direkt in bestehende UUID-Spalten.

UUID v7 im Vergleich zu UUID v4 und ULID

Format Länge Nach Erzeugungsreihenfolge sortierbar Kompatibel mit bestehenden UUID-Spalten Beschreibung
UUID v7 36 Zeichen (inklusive 4 Bindestriche) Ja (die ersten 48 Bit sind ein Zeitstempel in Millisekunden) Ja (Standard-UUID-Typ, weiterhin hexadezimal) In RFC 9562 standardisiert. Kombiniert einen Unix-Zeitstempel mit zufälligen Bits und ermöglicht so Sortierbarkeit nach Erzeugungszeit, ohne die Kompatibilität mit bestehender UUID-Infrastruktur zu verlieren. Das Format, das dieses Tool erzeugt.
UUID v4 36 Zeichen (inklusive 4 Bindestriche) Nein (vollständig zufällig) Ja (Standard-UUID-Typ) Ein vollständig zufälliger 128-Bit-Bezeichner, standardisiert in RFC 9562. Enthält keine Information über seine Herkunft und ist die am weitesten verbreitete Variante.
ULID 26 Zeichen Ja (die ersten 10 Zeichen sind ein Zeitstempel) Nein (Base32 erfordert einen eigenen Spaltentyp) Eine vom UUID-Standard (RFC 4122/9562) unabhängige Spezifikation, die Crockfords Base32 verwendet. Kürzer als UUID v7, lässt sich aber nicht direkt in einer nativen UUID-Spalte speichern.

Tipps zur Nutzung

  • Jede UUID v7 wird direkt im Browser über die Web-Crypto-API erzeugt — es wird nichts an die Server von toolbase.cc übertragen.
  • Da die ersten 48 Bit einer UUID v7 einen Unix-Zeitstempel in Millisekunden darstellen, genügt eine einfache Sortierung der erzeugten Werte als Zeichenkette, um die chronologische Erzeugungsreihenfolge zu erhalten.
  • Eine UUID v7 lässt sich direkt in jeder Spalte speichern, die bereits UUID-v4-Werte enthält (etwa eine CHAR(36)-Spalte oder der native uuid-Typ von PostgreSQL) — für die Migration sind keine Schemaänderungen nötig.
  • Das Format "ohne Bindestriche" eignet sich gut für URL-Pfadsegmente oder Dateinamen, während das Format "mit geschweiften Klammern" der GUID-Notation entspricht, die in Windows-COM- bzw. Registrierungskontexten verwendet wird.
  • Wenn Sie zwischen UUID v7 und ULID (Crockfords Base32, 26 Zeichen) unentschlossen sind: Wählen Sie UUID v7, wenn Ihr System bereits eine native UUID-Spalte voraussetzt, und ULID, wenn Ihnen die kürzestmögliche Zeichenkette wichtiger ist.

Häufig gestellte Fragen

Der entscheidende Unterschied ist, ob sich die Kennung nach dem Erzeugungszeitpunkt sortieren lässt. UUID v4 ist ein vollständig zufälliger 128-Bit-Wert ohne inhärente Ordnung, während UUID v7 in den ersten 48 Bit einen Unix-Zeitstempel in Millisekunden trägt, sodass ein einfacher Zeichenkettenvergleich die Erzeugungsreihenfolge offenbart.

Beide sind nach Erzeugungszeit sortierbar, unterscheiden sich aber in der Darstellung. UUID v7 erlaubt eine Migration unter Beibehaltung der Kompatibilität mit bestehenden UUID-typisierten Spalten und Bibliotheken, während ULID ein kürzeres, unabhängiges 26-Zeichen-Format auf Basis von Crockfords Base32 verwendet. Wählen Sie UUID v7, wenn Ihr System bereits einen nativen UUID-Typ voraussetzt, und ULID, wenn in einem neuen System eine möglichst kurze Kennung im Vordergrund steht.

Im Mai 2024 wurde UUID v7 offiziell als IETF-RFC 9562 standardisiert. Dasselbe Dokument fügte neben den bereits bestehenden UUID-Versionen 1 bis 5 die Variante v6 mit umgeordnetem Zeitstempel sowie die auf Unix-Zeitstempeln basierende Variante v7 hinzu.

Ja. Ein vollständig zufälliger Wert wie UUID v4 wird an zufälligen Positionen im Index eingefügt, was häufig zur Fragmentierung von B-Tree-Indizes führt, während UUID v7 annähernd zeitlich sortiert ist, sodass neue Zeilen nahe dem Ende des Index landen und sich die Einfügeleistung verbessert. PostgreSQL 18 hat sogar eine native Funktion uuidv7() ergänzt, was die breite Akzeptanz bei den wichtigsten Datenbanken widerspiegelt.
ツールくん

Übrigens – wie UUID v7 der UUID-Familie die Zeit zurückgab

UUID v7 wurde im Mai 2024 als IETF-RFC 9562 standardisiert — die erste größere Überarbeitung der UUID-Spezifikation seit dem ursprünglichen RFC 4122 von 2005, also rund zwei Jahrzehnte zuvor. Diese Überarbeitung fügte die sortierbaren Varianten v6 und v7 sowie die Variante v8 für benutzerdefinierte Felder hinzu, motiviert durch die lange bekannte Schwäche, dass die vollständige Zufälligkeit von UUID v4 die Effizienz von Datenbankindizes beeinträchtigt.

Das Design von UUID v7 ähnelt stark dem unseres Schwestertools ULID: Beide setzen einen Zeitstempel in Millisekunden an den Anfang und füllen den Rest mit zufälligen Bits. Der entscheidende Unterschied liegt in der Darstellung — ULID verwendet ein vom UUID-Standard unabhängiges 26-Zeichen-Format auf Basis von Crockfords Base32, während UUID v7 die 36-stellige hexadezimale Notation beibehält, die UUIDs seit RFC 4122 auszeichnet. Dank dieser Entscheidung lässt sich UUID v7 ohne jede Änderung direkt in bestehende UUID-typisierte Spalten, Bibliotheken und API-Verträge einfügen.

Die Unterstützung für UUID v7 verbreitete sich schon kurz nach der Veröffentlichung schnell über die wichtigsten Datenbanken und Sprachlaufzeiten. PostgreSQL bietet seit Version 18 eine native Funktion uuidv7(), und Bibliotheken anderer wichtiger Sprachen und ORMs haben ihre v7-Unterstützung ebenfalls rasch ausgebaut. Genau dieses Gleichgewicht zwischen der Bequemlichkeit der Sortierbarkeit nach Erzeugungszeit und der Kompatibilität, bestehende UUID-Investitionen nicht zu brechen, erklärt, warum UUID v7 neben ULID so schnell übernommen wurde.

Weitere Tools in dieser Kategorie