Erzeugen Sie UUID v4 oder v7 lokal mit dem UUID-Generator – ohne Upload, ohne Konto.
Warum sortierbare IDs zählen
Zufällige Primärschlüssel streuen Einfügungen in B-Tree- und LSM-Indizes und verursachen Page-Splits und Write-Amplification. Eine zeitgeordnete ID hält neue Werte dicht und Einfügungen schnell.
UUID v7 und ULID lösen das gleich: Beide betten einen 48-Bit-Unix-Zeitstempel in Millisekunden am Anfang des Werts ein.
UUID v7
UUID v7 ist durch RFC 9562 definiert. Es nutzt das kanonische Format 8-4-4-4-12 mit Bindestrichen, ein Versions-Nibble, ein Variant-Feld und etwa 74 zufällige Bits.
Die Stärke liegt im Ökosystem: Systeme, die heute UUIDs parsen, verstehen auch v7, und Datenbanken bieten zunehmend natives UUIDv7-Support.
RFC 9562 legt den Aufbau exakt fest: Die ersten 48 Bits enthalten den Unix-Zeitstempel in Millisekunden, danach folgen das Versions-Nibble (7), das Variant-Feld und die restlichen Zufallsbits. Weil der Zeitstempel am Anfang steht, entspricht der Byte-Vergleich der 16-Byte-Form der Erstellungsreihenfolge.
Die Spezifikation erlaubt außerdem einen monotonen Zähler, der einen Teil der Zufallsbits ersetzt, wenn mehrere Werte in derselben Millisekunde entstehen – so bleiben Zeilen aus derselben Millisekunde auch bei Masseneinfügungen in stabiler Reihenfolge.
ULID
ULID (Universally Unique Lexicographically Sortable Identifier) kodiert denselben 48-Bit-Zeitstempel plus 80 Zufallsbits in einen 26 Zeichen langen Crockford-Base32-String, üblicherweise in Großbuchstaben.
ULID ist kein RFC und kein UUID-Standard, aber in JavaScript- und Go-Ökosystemen verbreitet und lexikografisch in Erstellungsreihenfolge sortierbar.
Crockford Base32 verzichtet bewusst auf die Buchstaben I, L, O und U, damit keine Verwechslung mit den Ziffern 0 und 1 möglich ist; deshalb passen die insgesamt 128 Bits in 26 Zeichen statt in die 36 Zeichen einer UUID mit Bindestrichen.
Die Spezifikation enthält eine Monotonie-Regel: Jede weitere ULID in derselben Millisekunde erhöht einen Zähler, sodass die Sortierung auch bei Massenerzeugung stabil bleibt – nützlich in verteilten Systemen, in denen mehrere Prozesse dieselbe Uhr verwenden.
UUID v7 vs. ULID im Überblick
Unterschiedlich ist vor allem die Verpackung. Eine UUID mit Bindestrichen ist 36 Zeichen lang und nicht case-sensitiv; eine ULID ist 26 Zeichen, konventionell großgeschrieben und als einfacher String sortierbar. Der eingebettete Zeitstempel ist in beiden dasselbe 48-Bit-Millisekunden-Präfix, sodass sich der Erstellungszeitpunkt aus beiden Formaten auslesen lässt – zum Beispiel mit dem Unix-Zeitstempel-Konverter.
| Eigenschaft | UUID v7 | ULID |
|---|---|---|
| Standard | RFC 9562 | Community-Spec |
| Format | 8-4-4-4-12, mit Bindestrichen | 26 Zeichen Crockford Base32 |
| Zufallsbits | ~74 | 80 |
| Groß-/Kleinschreibung | Nicht case-sensitiv | Konventionell großgeschrieben |
| Ökosystem | UUID-Parser überall | Wachsend, stackabhängig |
So wählen Sie
- UUID v7, wenn Ihre Datenbank oder Tooling UUIDs bereits versteht
- ULID, wenn Ihr Stack es bereits nutzt oder Sie kompakte String-Schlüssel wollen
- Für öffentliche, nicht erratbare IDs weiterhin UUID v4 verwenden
- UUIDs in MySQL möglichst als BINARY(16) statt als String speichern
- Für kompakte Schlüssel in URLs oder Cache-Präfixen ist die 26 Zeichen lange ULID kürzer als eine UUID mit Bindestrichen
- Behandeln Sie beide als undurchsichtig: Eine sortierbare ID ist kein Geheimnis, verwenden Sie v4 weiterhin für Tokens und nicht erratbare Werte
FAQ
Q.Sind ULIDs und UUID v7 kompatibel?
A.Nein. Sie verwenden unterschiedliche Kodierungen; ein ULID-String ist keine gültige UUID und umgekehrt. Eine UUID besteht aus 16 Bytes, geschrieben als 36 Hexadezimalzeichen mit Bindestrichen; eine ULID ist eine 26 Zeichen lange Crockford-Base32-Zeichenkette. Beide lösen dasselbe Problem – zeitgeordnete, kollisionsresistente IDs –, aber die Formate sind nicht austauschbar, und ein Parser für das eine lehnt das andere ab.
Q.Ist ULID besser sortierbar als UUID v7?
A.Beide sortieren nach demselben 48-Bit-Zeitstempel-Präfix, das Sortierverhalten ist also äquivalent. Lexikografisches Sortieren funktioniert direkt für ULID-Strings; UUID v7 sortiert als Bytes oder als kanonischer String. Weil der Zeitstempel auch in der kanonischen Form am Anfang steht, funktioniert das Sortieren des Strings ebenfalls, der Byte-Vergleich ist aber günstiger.
Q.Sollte ich von ULID auf UUID v7 migrieren?
A.Nur wenn die Migrationskosten gering sind und Ihr Ökosystem tatsächlich von RFC-9562-Parsing profitiert. Der Wechsel betrifft gespeicherte Werte, Indizes und jeden Code, der IDs parst oder anzeigt – rechnen Sie das gegen den Nutzen. Beide Formate sind valide; Konsistenz im eigenen System zählt mehr als das Format.
- Ein pragmatischer Mittelweg: ULID dort behalten, wo es bereits existiert, und UUID v7 für neue Tabellen verwenden.
Referenzen
- RFC 9562 – Universally Unique IDentifiers (UUIDs): https://www.rfc-editor.org/rfc/rfc9562
- ULID Specification: https://github.com/ulid/spec
- ULID-JavaScript-Referenzimplementierung: https://github.com/ulid/javascript
- uuid-Paket (mit v7-Unterstützung): https://github.com/uuidjs/uuid
Nach Ökosystem wählen
Wenn Datenbank oder ORM bereits UUIDs verarbeiten, ist v7 der reibungsloseste Weg. Wenn Ihr Stack auf ULID aufbaut, bringt ein Formatwechsel wenig.
Keines von beiden ist ein Geheimnis: behalten Sie UUID v4 für Tokens und nicht erratbare IDs und erzeugen Sie beide lokal mit dem UUID-Generator.
Meine Faustregel: Nehmen Sie das Format, das Datenbank und ORM bereits sprechen, und bleiben Sie dabei. Ein späterer Wechsel bedeutet Datenmigration und den Umbau der Indizes – diese Kosten übersteigen meist den Unterschied der Formate.