UUID v4 vs UUID v7 vs ULID: Welche eindeutige ID sollten Sie verwenden?

Auto-Inkrementerende Ganzzahlen waren jahrzehntelang der Standard-Primärschlüssel. Sie sind kompakt und schnell, aber sie erfordern eine zentrale Datenbank, um Zahlen zu verteilen, zu lecken, wie viele Datensätze Sie haben, und das Zusammenführen von Daten aus mehreren Systemen schmerzhaft zu machen. Globale eindeutige Identifikatoren lösen diese Probleme: Jeder Server, jede mobile App oder jeder Offline-Client kann eine ID erstellen, die nie kollidiert. Die Frage ist, welche Art. Dieser Leitfaden vergleicht die drei beliebtesten Optionen im Jahr 2026: UUID-Version 4, UUID-Version 7 und ULID.

Eine kurze Auffrischung der UUIDs

Eine UUID (Universally Unique Identifier) ist ein 128-Bit-Wert, der in der Regel als 32 hexadezimale Ziffern in fünf Gruppen geschrieben wird:

550e8400-e29b-41d4-a716-446655440000

Der aktuelle Standard, RFC 9562 (veröffentlicht 2024, ersetzt RFC 4122), definiert mehrere Versionen. Ein paar Bits kodieren die Version und Variante; der Rest hängt von der Version ab. Die dritte Gruppe beginnt immer mit der Versionnummer, so dass man einen V4 von einem V7 auf einen Blick unterscheiden kann.

UUID v4: rein zufällig

Eine Version 4 UUID enthält 122 zufällige Bits plus 6 feste Bits für Version und Variante.

• Stärken *

• Trivial zu generieren: Jede Sprache und Datenbank hat eine eingebaute Funktion, wie crypto.randomUUID() in JavaScript oder gen_random_uuid() in PostgreSQL.
• Es zeigt nichts: kein Zeitstempel, keine Maschinendatenbank, keine Sequenz.
• Die Wahrscheinlichkeit einer Kollision ist vernachlässigbar. Man müsste etwa 2,7 × 10^18 IDs generieren, um eine 50%ige Chance auf ein einziges Duplikat zu haben.

** Schwächen **

• Zufällige Reihenfolge beeinträchtigt Datenbankindizes. B-Baumindizes, die von PostgreSQL, MySQL und SQL Server verwendet werden, funktionieren am besten, wenn neue Schlüssel in zunehmender Reihenfolge ankommen. Zufällige Tasten landen überall im Index, was zu Seitenspaltungen, schlechter Cache-Lokalisierung und Schreibverstärkung führt. Bei großen Tabellen kann der Einfüge-Durchsatz erheblich sinken und die Indizes größer werden als nötig.
• Nicht sortierbar nach Erstellungszeit, also benötigen Sie eine separate Spalte created_at für chronologische Abfragen.

UUID v7: zeitlich geordnet

Version 7 platziert einen 48-Bit-Unix-Zeitstempel in Millisekunden an der Vorderseite, gefolgt von 74-Bit-Zufälligkeit (einige Implementierungen verwenden einen Teil davon als Zähler für die Bestellung innerhalb derselben Millisekunde).

01928c3e-5b7a-7c4d-9f3e-2a1b4c5d6e7f
└─timestamp─┘ └version 7

• Stärken *

• Neue IDs steigen ungefähr, so dass Einfügungen am Ende des Index wie automatische Zunahme Tasten hinzugefügt werden. Dadurch bleiben die Indexe kompakter und das Schreiben schneller.
• Sortieren nach ID-Sortierungen nach Erstellungszeit, wodurch die kurserbasierte Paginierung einfach wird: WHERE id > :last_id ORDER BY id LIMIT 50.
• Es ist immer noch eine Standard-UUID: Es passt zu nativen uuid-Spalten, ORMs und APIs, die bereits UUIDs akzeptieren.
• Sie können die Erstellungszeit aus der ID für das Debugging extrahieren.

** Schwächen **

• Die Erstellungszeit ist für jeden sichtbar, der die ID sieht. Für die meisten Datensätze ist das harmlos; für einige, wie Benutzerkonten in einem datenschutzsensiblen Produkt, kann es zeigen, wann sich jemand angemeldet hat.
• Erfordert eine ziemlich genaue Uhr. Große Uhrensprünge nach hinten können IDs erzeugen, die früher sortiert werden als bestehende; gute Bibliotheken behandeln dies mit monotonen Zählern.
• Native-Generationsfunktionen sind neu. PostgreSQL 18 hat uuidv7() hinzugefügt; bei älteren Versionen generieren Sie in Anwendungscode.

ULID: sortierbarer und kompakter Text

ULID (Universally Unique Lexicographically Sortable Identifier) geht vor UUID v7 an und verwendet die gleiche Idee: einen 48-Bit-Millisekunden-Zeitstempel gefolgt von 80 zufälligen Bits. Der Unterschied liegt in der Textform: 26 Zeichen von Crockford Base32.

01J9Z3K8M2Q7X4V5B6N8P0R2T4

• Stärken *

• Kurzer als die UUID-String mit 36 Zeichen und URL-sicher.
• Groß- und Kleinbuchstaben sind unempfindlich und schließen zweideutige Buchstaben (I, L, O, U) aus, so dass es einfacher ist, laut zu lesen oder zu tippen.
• Die lexikografische Zeichenfolge-Sortierung entspricht der chronologischen Sortierung, die in Systemen hilft, die IDs als Text speichern, wie z. B. Schlüsselwertspeicher oder Protokolldateinamen.

** Schwächen **

• Es ist keine UUID, also passt es nicht zu den nativen UUID-Spalttypen ohne Konvertierung (obwohl seine 128 Bits in einem gespeichert werden können).
• Eine Community-Spezifikation statt eines IETF-Standards, mit leicht unterschiedlichem Verhalten zwischen Bibliotheken.
• Wie V7 zeigt es die Schöpfungszeit.

Vergleich nebeneinander

Immobilien	UUID v4	UUID v7	ULID
Größe	128 Bits	128 Bits	128 Bits
Textlänge	36	36	26
Zeitgerichtet	- Nein .	- Ja , das ist es .	- Ja , das ist es .
Leaks Schöpfung Zeit	- Nein .	Ja (ms)	Ja (ms)
Standards	RFC 9562	RFC 9562	Gemeinschaftsspezifikation
Native DB-Typ	uuid	uuid	Normalerweise Text oder Binär
Indexfreundliche Einlagen	Sie sind arm.	Das ist gut.	Das ist gut.

Aufbewahrungsspitzen

Was auch immer Sie wählen, speichern Sie IDs als 16 Bytes, nicht als Text. Eine Zeichenfolge mit 36 Zeichen nimmt mehr als doppelt so viel Platz in Anspruch, und jeder Index und jeder fremde Schlüssel, der darauf verweist, multipliziert die Kosten. PostgreSQL hat einen nativen uuid-Typ; MySQL-Benutzer können BINARY(16) mit UUID_TO_BIN(uuid, 1) verwenden, wobei das zweite Argument v1-Zeitstempel für v7 die Standard-Reihenfolge verwendet, da es bereits zeitlich geordnet ist.

Identifizieren von IDs in APIs in ihrer kanonischen Textform. Die Kunden sollten sie als undurchsichtige Zeichenfolgen behandeln und niemals ihre Bedeutung aus ihnen entfernen.

Sicherheitsaspekte

Keine dieser Ausweise sind Geheimnisse. Verwenden Sie sie nicht als Passwort-Rücksetz-Token oder Session-Identifikatoren, nur weil sie schwer zu erraten sind. Eine UUID v4 hat genügend Zufälligkeit, um nicht zu testen, aber v7 und ULID haben vorhersehbare Zeitstempelpräfixe, die die effektive Entropie reduzieren. Für Geheimnisse generieren Sie mindestens 128 zufällige Bits mit einem kryptographischen Generator und behandeln Sie sie wie Passwörter, idealerweise speichern Sie nur einen Hash siehe MD5 vs SHA-256 für den Hash zu verwenden.

Betrachten Sie auch die Aufzählung. Sequentielle Ganzzahlen lassen jeden erraten /orders/1001, /orders/1002. Zufällige oder zeitlich geordnete IDs machen das unpraktisch, ersetzen jedoch nicht die Genehmigungsüberprüfungen bei jedem Antrag.

Welche sollten Sie wählen?

• Datenbank-Primärschlüssel in einem neuen System: UUID v7. Sie erhalten verteilte Erzeugung und gute Indexleistung mit voller UUID-Kompatibilität.
• Öffentliche Kennungen, bei denen die Erstellungszeit privat bleiben muss: UUID v4 oder ein interner Schlüssel v7 in Kombination mit einer separaten zufälligen öffentlichen ID.
• Textbasierte Speicher, Dateinamen oder IDs: ULID, für seine kürzere, groß- und kleinbuchstabenunempfindliche Form.
• ** Bestehendes System auf v4 mit Leistungsproblemen:** Betrachten Sie v7 für neue Tabellen; das Mischen von Versionen in einer Spalte ist technisch in Ordnung, da beide gültige UUIDs sind.

Erzeugung von IDs

Für schnelle Aufgaben Startdaten, Prüfvorrichtungen, manuelle Einfügungen kann ein browserbasierter [UUID-Generator] ((/tools/uuid) bis zu 1.000 V4, V7 oder ULID-Werte auf einmal mit crypto.getRandomValues erzeugen. Verwenden Sie im Anwendungscode die Standardbibliothek Ihrer Sprache oder ein gut gepflegtes Paket und generieren Sie IDs, die der Erstellung von Datensätzen möglichst nahe kommen.

Zusammenfassung

UUID v4 ist zufällig und privat, aber verstreut Datenbankindizes. UUID v7 fügt ein Zeitstempel-Präfix hinzu, das die Einfügungen schnell und die IDs sortierbar hält, während es eine Standard-UUID bleibt. ULID bietet die gleiche Reihenfolge mit einem kürzeren, freundlicheren Textformat. Für die meisten neuen Anwendungen ist UUID v7 der beste Standard; erreichen Sie v4, wenn das Timing versteckt bleiben muss, und ULID, wenn Menschen oder textbasierte Systeme die IDs verarbeiten.