UUID v4 vs v7 vs ULID: So wählen Sie den richtigen Identifier für Ihre Datenbank
Sie starten einen neuen Service, und die erste Entscheidung wirkt trügerisch einfach: Wie soll Ihr Primärschlüssel aussehen? Auto-inkrementierende Integer verraten Zeilenanzahlen, offenbaren die Erstellungsreihenfolge und versagen, sobald Daten aus mehreren Datenbanken zusammengeführt werden müssen. UUIDs lösen diese Probleme — aber jetzt müssen Sie sich entscheiden, welche UUID.
UUID v4 ist seit über einem Jahrzehnt der Standard. UUID v7, standardisiert in RFC 9562 im Mai 2024, verspricht bessere Datenbankleistung durch zeitbasierte Sortierung. Und ULID, die community-getriebene Alternative aus dem Jahr 2016, bietet ähnliche Vorteile in einem kompakteren Format. Jede Variante hat echte Kompromisse, die Leistung, Datenschutz und langfristige Wartbarkeit beeinflussen.
Dieser Leitfaden vergleicht alle drei — mit echten Benchmark-Daten, praxisnahen Migrationshinweisen und einem klaren Entscheidungsrahmen für 2026.
Was ist eine UUID? (Und warum „GUID” dasselbe ist)
Eine UUID (Universally Unique Identifier) ist ein 128-Bit-Wert, der ohne zentrale Instanz eindeutig sein soll. Das Standardformat besteht aus 32 Hexadezimalzeichen, getrennt durch Bindestriche: 550e8400-e29b-41d4-a716-446655440000.
Wer mit .NET oder Windows gearbeitet hat, kennt diese als GUIDs (Globally Unique Identifiers). Es handelt sich um dasselbe — GUID ist Microsofts Bezeichnung für den UUID-Standard. Bit-Layout, Generierungsalgorithmen und Speicherbedarf sind identisch.
UUID hat mehrere Versionen durchlaufen. Die heute relevanten:
| Version | Strategie | Standardisiert | Noch relevant? |
|---|---|---|---|
| v1 | Zeitstempel + MAC-Adresse | RFC 4122 (2005) | Größtenteils durch v7 ersetzt |
| v4 | Zufällig | RFC 4122 (2005) | Ja — der aktuelle Standard |
| v5 | Namensbasiert (SHA-1-Hash) | RFC 4122 (2005) | Nischenfälle |
| v7 | Zeitstempel + Zufall | RFC 9562 (2024) | Ja — die neue Empfehlung |
RFC 9562 ist in seiner Richtung eindeutig: „Implementations SHOULD utilize UUIDv7 instead of UUIDv1 and UUIDv6 if possible.”
UUID v4: Der Zufalls-Standard
UUID v4 erzeugt Identifier aus 122 Bit kryptographisch sicherem Zufall. Das ergibt einen Schlüsselraum von etwa 5,3 × 10³⁶ möglichen Werten — Sie müssten eine Milliarde UUIDs pro Sekunde über 86 Jahre generieren, um eine 50-prozentige Kollisionswahrscheinlichkeit zu erreichen.
So funktioniert es: 128 Bit insgesamt, wobei 6 Bit für Versions- (4) und Variantenmarkierungen reserviert sind. Die verbleibenden 122 Bit stammen aus einem CSPRNG wie crypto.getRandomValues().
Beispiel: f47ac10b-58cc-4372-a567-0e02b2c3d479
Die Einfachheit ist ihre Stärke. Keine Koordination nötig, keine Zeitstempel, die Informationen preisgeben, kein Zustand, der gepflegt werden muss. Jede große Programmiersprache und Datenbank hat v4-Unterstützung eingebaut.
Das Problem: Zufällige UUIDs fragmentieren Ihre Datenbank
Reine Zufälligkeit hat ihren Preis. Wenn Sie zufällige UUIDs in einen B-Tree-Index einfügen — den Standard bei PostgreSQL, MySQL und den meisten relationalen Datenbanken — landen neue Zeilen an beliebigen Positionen im Baum. Das verursacht:
- Page Splits: Die Datenbank teilt und reorganisiert ständig Indexseiten, anstatt am Ende anzufügen.
- Write Amplification: EnterpriseDB-Benchmarks zeigen, dass zufällige UUIDs 8× mehr WAL (Write-Ahead Log) erzeugen als sequenzielle Alternativen — 20 GB gegenüber 2,5 GB bei gleicher Arbeitslast.
- Durchsatz-Einbruch: Bei Datensätzen, die größer als der RAM sind, sinkt der Einfüge-Durchsatz mit zufälligen UUIDs auf 20–30 % des sequenziellen UUID-Durchsatzes.
- Verschwendeter Speicherplatz: PlanetScale berichtet, dass zufällige UUIDs die B+-Tree-Seitenauslastung von MySQL auf ca. 50 % senken, verglichen mit 94 % bei sequenziellen Schlüsseln.
Das ist kein theoretisches Problem. Buildkite erzielte eine 50-prozentige Reduktion der WAL-Rate auf ihrer primären Datenbank nach dem Wechsel zu zeitsortierten UUIDs. Shopify maß eine 50-prozentige Verringerung der INSERT-Dauer beim Umstieg von UUID v4 auf zeitsortierte Identifier für Idempotenzschlüssel im Zahlungssystem.
UUID v4 ist in Ordnung für kleine Tabellen, seltene Schreibvorgänge oder überall dort, wo die UUID nicht als Primärschlüssel dient. Für Systeme mit hohem Durchsatz summiert sich die Fragmentierungssteuer über die Zeit.
UUID v7: Zeitsortiert und datenbankfreundlich
UUID v7 löst das Fragmentierungsproblem, indem der Zeitstempel an den Anfang gestellt wird. Die höchstwertigen 48 Bit kodieren einen UNIX-Epoch-Zeitstempel in Millisekunden, gefolgt von ca. 74 Bit kryptographisch sicherem Zufall.
So funktioniert es:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
├─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤
| unix_ts_ms (48 bits) |
├─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤
| unix_ts_ms | ver | rand_a (12 bits) |
├─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤
|var| rand_b (62 bits) |
├─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤─┤Da UUIDs, die innerhalb derselben Millisekunde erzeugt werden, ein gemeinsames Zeitstempel-Präfix haben, gruppieren sie sich im B-Tree-Index zusammen. Neue Einfügungen hängen sich nahe am Ende des Baums an, statt zufällig verteilt zu werden — dasselbe Zugriffsmuster, das auto-inkrementierende Integer schnell macht.
Beispiel: 019078e5-d2c7-7b3a-8f1e-4a6d5c8b2e91 — die ersten 12 Hex-Zeichen kodieren den Erstellungszeitpunkt.
Was RFC 9562 geändert hat
Vor RFC 9562 existierten zeitsortierte UUIDs nur als informelle Vorschläge. Der RFC, veröffentlicht im Mai 2024, machte UUID v7 zu einem offiziellen IETF-Standard mit definiertem Bit-Layout. Er katalogisiert 16 verschiedene nicht-standardisierte zeitsortierte ID-Implementierungen — darunter ULID, Twitters Snowflake und Instagrams ShardId — die seine Entstehung motivierten.
Die praktische Auswirkung: Bibliotheksautoren haben jetzt eine einzige Spezifikation, gegen die sie implementieren können, und Datenbanken fügen native Unterstützung hinzu. PostgreSQL 18 (veröffentlicht Ende 2025) lieferte eine eingebaute uuidv7()-Funktion, die den Bedarf an Extensions oder Generierung auf Anwendungsebene beseitigt.
PostgreSQL 18s native uuidv7()-Funktion
PostgreSQL 18, veröffentlicht Ende 2025, fügt zwei neue Funktionen hinzu:
-- Zeitsortierte UUID v7 generieren
SELECT uuidv7();
-- Ergebnis: 019078e5-d2c7-7b3a-8f1e-4a6d5c8b2e91
-- Zufällige UUID v4 generieren (Alias für gen_random_uuid())
SELECT uuidv4();PostgreSQLs Implementierung fügt eine 12-Bit-Sub-Millisekunden-Zeitstempelfraktion hinzu, die eine bessere monotone Sortierung innerhalb eines einzelnen Backend-Prozesses ermöglicht. Das bedeutet, dass selbst Zeilen, die in derselben Millisekunde eingefügt werden, die Erstellungsreihenfolge beibehalten — wichtig für Tabellen mit hohem Durchsatz.
Für ältere PostgreSQL-Versionen können Sie UUID v7 auf Anwendungsebene generieren oder Extensions wie pg_idkit verwenden.
UUID v4 vs v7: Direktvergleich
| Eigenschaft | UUID v4 | UUID v7 |
|---|---|---|
| Format | 128-Bit, 36 Zeichen Hex | 128-Bit, 36 Zeichen Hex |
| Zufallsbits | 122 | ca. 74 |
| Nach Erstellungszeit sortierbar | Nein | Ja (ms-Präzision) |
| B-Tree-Index-Leistung | Schlecht bei großen Datenmengen | Hervorragend |
| Zeitstempel-Offenlegung | Keine | Ja (ms-Präzision) |
| RFC-Standard | RFC 4122 / RFC 9562 | RFC 9562 (Mai 2024) |
| Native Datenbankunterstützung | Alle großen Datenbanken | PostgreSQL 18+, wachsend |
| Bibliotheksunterstützung | Universell | Breit und wachsend |
| Speichergröße | 16 Bytes (binär) | 16 Bytes (binär) |
| Spaltentyp-Kompatibilität | uuid / BINARY(16) | uuid / BINARY(16) — gleiche Spalte, voll kompatibel |
Die entscheidende Erkenntnis: v4 und v7 sind spaltenkompatibel. Sie verwenden denselben uuid-Datentyp, denselben 16-Byte-Binärspeicher und dieselbe 36-Zeichen-String-Darstellung. Sie können beide in derselben Spalte speichern, was eine inkrementelle Migration unkompliziert macht.
Selbst ausprobieren: UUID Generator — generieren Sie UUID-v4-Identifier sofort in Ihrem Browser, mit Massengenerierung und Kopieren per Klick.
UUID v7 vs ULID: Brauchen Sie ULID noch?
ULID (Universally Unique Lexicographically Sortable Identifier) wurde 2016 eingeführt, um dasselbe Problem zu lösen, das UUID v7 jetzt adressiert: zeitsortierte, global eindeutige Identifier. So vergleichen sie sich:
| Eigenschaft | UUID v7 | ULID |
|---|---|---|
| Kodierung | 36 Zeichen Hex mit Bindestrichen | 26 Zeichen Crockford Base32 |
| Zeitstempel | 48-Bit ms-Epoch | 48-Bit ms-Epoch |
| Zufallsbits | ca. 74 | 80 |
| Standard | IETF RFC 9562 | Community-Spezifikation (kein RFC) |
| Monotone Sortierung | Implementierungsabhängig | Spec-definiertes Inkrement innerhalb derselben ms |
| Datenbanktyp | Nativer uuid-Spaltentyp | Erfordert CHAR(26) oder BINARY(16) |
| URL-sicher | Nein (Bindestriche) | Ja (Base32) |
| Zeitstempel gültig bis | Jahr 10889 | Jahr 10889 |
Wo UUID v7 gewinnt
-
Standardisierung. UUID v7 hat einen IETF-RFC. Jede Datenbank, jedes ORM und jede Sprachlaufzeit versteht bereits den UUID-Typ. ULID erfordert in den meisten Ökosystemen benutzerdefiniertes Parsing.
-
Native Datenbankunterstützung. ULIDs passen nicht ohne Konvertierung in PostgreSQLs nativen
uuid-Spaltentyp. Entweder speichern Sie sie als Strings (verschwendet Speicherplatz) oder konvertieren in Binär (verliert die Crockford-Kodierung). UUID v7 fügt sich direkt in bestehendeuuid-Spalten ein. -
Ökosystem-Dynamik. Bytebase prognostiziert, dass die Branche „allmählich maßgeschneiderte Lösungen aufgeben und auf UUIDv7 als Primärschlüssel für die meisten Anwendungsfälle konvergieren wird.” PostgreSQL 18s native
uuidv7()-Funktion beschleunigt diese Entwicklung.
Wo ULID weiterhin sinnvoll ist
-
Kompakte Darstellung. Mit 26 Zeichen gegenüber 36 sind ULIDs kürzer in URLs und APIs. Wenn die Stringlänge für Ihren Anwendungsfall relevant ist, ist ULID kompakter.
-
Etwas mehr Zufall. ULID bietet 80 Zufallsbits gegenüber ca. 74 bei UUID v7. In der Praxis haben beide astronomisch niedrige Kollisionsraten, aber ULID hat eine geringfügig größere Zufallskomponente.
-
Bestehende ULID-Infrastruktur. Wenn Ihr System bereits ULIDs nutzt und die Migrationskosten nicht trivial sind, gibt es keinen dringenden Grund zum Wechsel. Beide bieten vergleichbare Datenbankleistung, da sie dasselbe 48-Bit-Zeitstempel-Präfix teilen.
Für neue Projekte im Jahr 2026 ist UUID v7 die sicherere Wahl. Es ist standardisiert, wird nativ von Datenbanken unterstützt und erfordert nicht, dass Ihr Team ULID-Parsing-Logik pflegt.
Datenbankleistung: Echte Benchmarks
Der Leistungsunterschied zwischen zufälligen und zeitsortierten Identifiern ist in Produktionssystemen gut dokumentiert:
PostgreSQL
| Metrik | UUID v4 | UUID v7 / Sequenziell |
|---|---|---|
| INSERT-Durchsatz (großer Datensatz) | 20–30 % Basis | 100 % Basis |
| WAL-Volumen | ca. 20 GB | ca. 2,5 GB |
| Cache-Trefferquote | 85 % | 99 % |
Quelle: EnterpriseDB-Benchmark. Die Differenz wächst, wenn Datensätze den verfügbaren RAM übersteigen.
MySQL / InnoDB
MySQLs InnoDB-Engine nutzt Clustered Indexes, bei denen der Primärschlüssel die physische Zeilenreihenfolge bestimmt. Zufällige UUIDs sind hier besonders kostspielig:
- Die B+-Tree-Seitenauslastung sinkt auf ca. 50 % (gegenüber 94 % bei sequenziellen Schlüsseln)
- UUID gespeichert als
CHAR(36)ist 9× größer als ein 32-Bit-Integer BINARY(16)ist das empfohlene Speicherformat — 4× größer als ein Integer, aber kompakt genug für die meisten Workloads
Quelle: PlanetScale-Analyse.
Wann Sie bei Auto-Increment bleiben sollten
UUIDs sind nicht immer die Antwort. Auto-inkrementierende Integer bleiben die richtige Wahl, wenn:
- Sie eine einzelne Datenbank ohne Sharding-Pläne betreiben
- Der Schreibdurchsatz wichtiger ist als globale Eindeutigkeit
- Zeilenanzahlen keine sensiblen Informationen darstellen
- Sie keine IDs außerhalb der Datenbank generieren müssen
Für verteilte Systeme, Microservices oder jede Architektur, in der IDs auf Anwendungsebene erzeugt werden müssen, bietet UUID v7 sowohl die Leistung sequenzieller Schlüssel als auch die Flexibilität dezentraler Generierung.
So generieren Sie UUID v7
JavaScript / TypeScript
// Using the 'uuid' package (v10+)
import { v7 as uuidv7 } from 'uuid';
const id = uuidv7(); // '019078e5-d2c7-7b3a-8f1e-4a6d5c8b2e91'Python
# Python 3.x with uuid7 package
from uuid_extensions import uuid7
id = str(uuid7()) # '019078e5-d2c7-7b3a-8f1e-4a6d5c8b2e91'Go
// Using github.com/gofrs/uuid/v5
import "github.com/gofrs/uuid/v5"
id, _ := uuid.NewV7()
fmt.Println(id.String()) // "019078e5-d2c7-7b3a-8f1e-4a6d5c8b2e91"PostgreSQL 18+
-- Native function, no extension needed
CREATE TABLE orders (
id uuid PRIMARY KEY DEFAULT uuidv7(),
customer_id uuid NOT NULL,
created_at timestamptz DEFAULT now()
);Andere Sprachen
UUID-v7-Bibliotheken sind verfügbar für Rust (uuid Crate v1.4+), Java (uuid-creator), C# (UUIDNext) und PHP (symfony/uid).
Migration von UUID v4 zu v7
Sie verwenden bereits UUID v4 in der Produktion? Die gute Nachricht: Die Migration erfordert keinen Big-Bang-Umstieg.
v4 und v7 können koexistieren
Beide Versionen nutzen denselben uuid-Spaltentyp und dieselbe 16-Byte-Binärdarstellung. Sie können für neue Zeilen v7 generieren, während bestehende v4-Zeilen unangetastet bleiben. Abfragen, Joins und Indizes funktionieren identisch — der Datenbank ist egal, welche Version eine UUID hat.
Der einzige Verhaltensunterschied: Neue v7-Zeilen werden bei Sortierung nach Primärschlüssel nach älteren v4-Zeilen einsortiert, da das Zeitstempel-Präfix von v7 sie lexikographisch später einordnet. Falls Ihre Anwendung auf UUID-Sortierung angewiesen ist (was bei v4 nicht der Fall sein sollte), überprüfen Sie diese Annahme.
Migrations-Checkliste
- ID-Generierung aktualisieren — stellen Sie die UUID-Generierung auf Anwendungsebene auf v7 um. Für PostgreSQL 18+ ändern Sie den Spalten-Default auf
uuidv7(). - ORMs aktualisieren — die meisten ORMs delegieren die UUID-Generierung an die Anwendung oder Datenbank. Aktualisieren Sie den Generator, nicht den Spaltentyp.
- Index-Leistung überwachen — nach der Umstellung sind neue Einfügungen sequenziell. Mit der Zeit werden Ihre Indizes natürlich effizienter, je mehr v7-Zeilen dominieren.
- Nicht rückwirkend konvertieren — bestehende v4-Werte in v7 umzuwandeln ist unnötig und würde Fremdschlüssel-Referenzen brechen. Lassen Sie v4 und v7 koexistieren.
Datenschutz: Zeitstempel in Ihren IDs
UUID v7 kodiert den Erstellungszeitpunkt mit Millisekunden-Präzision. Jeder, der die UUID sehen kann, kann daraus ableiten, wann sie erstellt wurde. Für interne Datenbankschlüssel ist das selten ein Problem. Bedenken Sie jedoch die Auswirkungen auf:
- Öffentliche APIs — wenn Ihre API Entity-IDs offenlegt, können Clients bestimmen, wann Ressourcen erstellt wurden. Das könnte Geschäftsmuster offenbaren (Bestellvolumen, Nutzerwachstumsrate).
- Session-Tokens und API-Schlüssel — bevorzugen Sie UUID v4 für Geheimnisse. Der Zeitstempel in v7 bringt keinen Mehrwert für Tokens und gibt unnötig Timing-Informationen preis.
- Regulatorische Compliance — je nach Rechtsordnung könnten Erstellungszeitstempel in Identifiern als personenbezogene Daten gelten, wenn sie einem Nutzer zugeordnet werden können.
Ein pragmatischer Ansatz: Verwenden Sie UUID v7 für Datenbank-Primärschlüssel (intern), UUID v4 für extern sichtbare Tokens und API-Schlüssel.
Selbst ausprobieren: UUID Generator — brauchen Sie eine Reihe von UUIDs zum Testen? Generieren Sie bis zu 25 auf einmal, kopieren Sie einzeln oder laden Sie sie als Textdatei herunter.
Häufig gestellte Fragen
Können zwei UUIDs jemals identisch sein?
Theoretisch ja, praktisch nein. Die 122 Zufallsbits von UUID v4 ergeben einen Schlüsselraum von 5,3 × 10³⁶. Sie müssten eine Milliarde UUIDs pro Sekunde über 86 Jahre generieren, um eine 50-prozentige Kollisionswahrscheinlichkeit zu erreichen. UUID v7 hat weniger Zufallsbits (ca. 74), aber Kollisionen innerhalb derselben Millisekunde sind immer noch astronomisch unwahrscheinlich.
Sollte ich UUIDs als Strings oder binär speichern?
Binär. Eine UUID als CHAR(36) gespeichert benötigt 36 Bytes; als BINARY(16) nur 16 Bytes — weniger als die Hälfte des Speicherplatzes. PostgreSQLs nativer uuid-Typ speichert automatisch als 16-Byte-Binär. In MySQL verwenden Sie BINARY(16) und konvertieren auf Anwendungsebene. PlanetScale weist darauf hin, dass CHAR(36) 9× größer ist als ein 32-Bit-Integer, weshalb binäre Speicherung für große Tabellen unerlässlich ist.
Wie vergleicht sich UUID v7 mit Twitter Snowflake?
Beides sind zeitsortierte verteilte Identifier, aber sie dienen unterschiedlichen Zwecken. Snowflake-IDs sind 64-Bit (kleiner, schneller zu vergleichen), erfordern aber einen zentralen Koordinierungsdienst zur Zuweisung von Worker-IDs. UUID v7 ist 128-Bit und erfordert keine Koordination — jeder Knoten kann unabhängig eine generieren. RFC 9562 listet Snowflake explizit unter den 16 nicht-standardisierten Implementierungen, die UUID v7s Entstehung motivierten.
Wie generiere ich UUID v7 in PostgreSQL vor Version 18?
Vor der nativen Unterstützung haben Sie mehrere Optionen: die pg_idkit-Extension, Generierung auf Anwendungsebene (generieren Sie in Ihrem App-Code und übergeben Sie an die Datenbank) oder eine PL/pgSQL-Funktion, die Zeitstempel und Zufallsbytes manuell zusammensetzt. Ein Upgrade auf PostgreSQL 18 ist der sauberste Weg, wenn Ihre Infrastruktur es zulässt.
Ist UUID v7 sicher für API-Schlüssel?
Nein — verwenden Sie UUID v4 für Geheimnisse. Der Zeitstempel von UUID v7 verrät, wann der Schlüssel erstellt wurde, was im Sicherheitskontext eine unnötige Information darstellt. Für API-Schlüssel und Session-Tokens wollen Sie maximale Entropie ohne eingebettete Metadaten. Die 122 Bit reiner Zufälligkeit von UUID v4 aus einem CSPRNG sind dafür geeignet, obwohl dedizierte Token-Formate zusätzliche Funktionen wie eingebaute Ablaufzeiten bieten können.
Welche sollten Sie wählen? Ein Entscheidungsrahmen
Wählen Sie UUID v4, wenn:
- Sie maximale Zufälligkeit benötigen (Tokens, API-Schlüssel, Session-IDs)
- Der Erstellungszeitpunkt privat bleiben muss
- Sie UUIDs zu einer kleinen Tabelle mit wenigen Schreibvorgängen hinzufügen, bei der Index-Fragmentierung keine Rolle spielt
Wählen Sie UUID v7, wenn:
- Die UUID als Datenbank-Primärschlüssel dient
- Sie zeitbasierte Sortierung ohne zusätzliche
created_at-Spalte benötigen - Schreibdurchsatz bei großen Datenmengen wichtig ist
- Sie die Vorteile sequenzieller Schlüssel ohne zentrale Instanz nutzen möchten
Wählen Sie ULID, wenn:
- Sie eine kürzere String-Darstellung benötigen (26 Zeichen statt 36)
- Ihr System bereits auf ULID-Infrastruktur läuft
- Sie URL-sichere Identifier ohne Kodierung benötigen
Für die meisten neuen Projekte im Jahr 2026 ist UUID v7 die Standardempfehlung. Es kombiniert die dezentrale Generierung von UUID v4 mit der Datenbankleistung sequenzieller Schlüssel, unterstützt durch einen IETF-Standard und wachsende native Datenbankunterstützung. Die Konvergenz hin zu v7 ist in vollem Gange — PostgreSQL 18s eingebaute uuidv7()-Funktion ist das bisher deutlichste Signal.
Egal, wofür Sie sich entscheiden: Sie können UUID-v4-Identifier sofort mit dem UUID Generator erzeugen — oder Ihre API-Antworten mit UUIDs mit dem JSON Formatter formatieren.