> uuidv7 generator <
// Zeitlich geordnete, sortierbare UUIDs (RFC 9562, 2024) — 48-Bit-Unix-ms-Zeitstempel + 74 Zufallsbits, lokal erzeugt
// EINE UUIDV7 DEKODIEREN / UNTERSUCHEN
Fügen Sie unten eine beliebige UUID ein, um den eingebetteten Zeitstempel, die Version und die Variante zu extrahieren. Funktioniert mit v7 und meldet, wenn die Eingabe eine andere UUID-Version ist.
Spezifikationskonforme UUIDv7
Implementiert das zeitlich geordnete UUID-Format aus RFC 9562 (Mai 2024): 48-Bit-Unix-Millisekunden-Zeitstempel, 4-Bit-Version 7, 12-Bit-rand_a, 2-Bit-Variante, 62-Bit-rand_b. Gegen die Testvektoren der Spezifikation verifiziert.
Chronologische Sortierreihenfolge
Sortieren Sie numerisch oder lexikografisch und Sie erhalten die Einfügereihenfolge — perfekt für B-Baum-Primärschlüssel, Zeitreihen-Indizes und Log-Korrelation. Keine zufälligen v4-Seitenteilungen oder fragmentierten Indizes mehr.
Monotonie innerhalb derselben Millisekunde
Wenn mehrere UUIDs in dieselbe Millisekunde fallen, wird der Zufallsanteil streng inkrementiert, sodass die Ausgabe innerhalb dieser ms sortiert bleibt. Schalten Sie es ab für reines RFC 9562 Methode 1 (Zufallsfüllung), falls Sie das bevorzugen.
Beliebige UUIDv7 untersuchen
Fügen Sie eine v7-UUID ein und der Decoder extrahiert den eingebetteten Zeitstempel (ms + ISO 8601), die Versionsbits, die Variantenbits und die Felder rand_a / rand_b. Nützlich für Debugging, Log-Archäologie und Audit-Trails.
// ÜBER UUIDV7
So funktioniert UUIDv7:
Eine UUIDv7 ist ein 128-Bit-Bezeichner mit dem Aufbau unix_ts_ms (48) | ver (4) | rand_a (12) | var (2) | rand_b (62). Die ersten 48 Bit sind der aktuelle Unix-Zeitstempel in Millisekunden, big-endian, wodurch die UUID zeitlich monoton steigend ist. Die nächsten 4 Bit kodieren die Version (binär 0111 = dezimal 7), sodass die dritte durch Bindestriche getrennte Gruppe immer mit der Ziffer 7 beginnt. rand_a sind 12 Zufallsbits, die für Sub-Millisekunden-Auflösung oder als zusätzliche Entropie verwendet werden. Das 2-Bit-Variantenfeld ist auf 10 festgelegt (sodass das erste Zeichen der vierten Gruppe immer 8, 9, a oder b ist). Die verbleibenden 62 Bit (rand_b) stammen bei jeder Erzeugung aus crypto.getRandomValues(). Die Gesamtentropie pro UUID beträgt 74 Zufallsbits, was bei jeder realistischen Erzeugungsrate kollisionsresistent ist.
Beispiel:
018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55 (ts=2024-05-08T15:00:00.000Z)
Standards & Referenzen:
- >RFC 9562 — Universally Unique IDentifiers (UUIDs), Mai 2024 (löst RFC 4122 ab, definiert v6/v7/v8)
- >RFC 4122 — die ursprüngliche UUID-Spezifikation von 2005 (weiterhin maßgeblich für v1-v5)
- >Web Crypto API (W3C) —
crypto.getRandomValues()CSPRNG, verwendet für die 74 Zufallsbits - >PostgreSQL-Verhalten von
gen_random_uuid()(standardmäßig v4, v7 in pgcrypto-Erweiterungen / Forks) - >draft-peabody-dispatch-new-uuid-format — der ursprüngliche v6/v7/v8-Vorschlag, aus dem RFC 9562 wurde
Warum UUIDv7 verwenden:
- >Datenbank-Primärschlüssel mit Einfüge-Lokalität — Seiten bleiben gepackt, Indizes fragmentieren nicht
- >Ersetzt ein Paar aus Sequenz + UUID: eine Spalte, sortierbar UND global eindeutig
- >Ersetzt v4-Primärschlüssel in schreibintensiven Tabellen, um das Problem zufälliger Einfüge-Seitenteilungen zu beheben
- >Log-Korrelations-IDs, die ohne separate Zeitstempelspalte nach Erstellungszeit sortieren
- >Verteilte Systeme, in denen mehrere Schreiber geordnete IDs ohne Koordinator benötigen
- >Event Sourcing / Append-only-Logs, bei denen die chronologische Reihenfolge der natürliche Index ist
- >S3- / Objektspeicher-Schlüssel, bei denen die Präfixsortierung der Einfügereihenfolge entspricht
- >Ersetzt Snowflake / KSUID / ULID, wo ein Standardformat vorzuziehen ist
Verwandte Tools:
- >UUID-Generator — erzeugt v4 (zufällig) und v1 (Zeitstempel), wenn Sie die Sortierreihenfolge von v7 nicht benötigen
- >GUID-Generator — derselbe Bezeichner unter der Microsoft-Bezeichnung
- >Timestamp-Konverter — wandelt die eingebetteten Unix-ms zurück in lokale Zeit / ISO 8601
- >Epoch-Konverter — untersucht den 48-Bit-Zeitstempelanteil in jeder Zeitzone
- >Passwort-Generator — kryptografisch zufällige Tokens, wenn Sortierbarkeit nicht erforderlich ist
// BEISPIELAUSGABEN
Einzelne UUIDv7, jetzt erzeugt
count=1, format=standard, timestamp=current
output:
018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55
Massen-Batch mit Monotonie in derselben Millisekunde
count=5, format=standard, monotonic=on
output:
018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a56 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a57 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a58 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a59
Benutzerdefinierter historischer Zeitstempel — Nachfüllen einer Migration
count=1, timestamp=custom, value=1577836800000 (2020-01-01)
output:
016f5e66-e800-7c9a-b403-2f1d4a7c91ee
Kompaktes Format für URLs / Dateinamen
count=1, format=no-hyphens
output:
018f5c2e90c07a4fb6ee8dfe3c2b0a55
Dekodierte UUIDv7 — die eingebetteten Felder untersuchen
input = 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55
output:
ts_ms = 1715180400000 ISO = 2024-05-08T15:00:00.000Z ver = 7 var = 10 (RFC 4122) rand_a = 0xa4f rand_b = 0x36ee8dfe3c2b0a55
// SELBST IMPLEMENTIEREN
Die meisten Sprachen haben seit dem Erscheinen von RFC 9562 im Jahr 2024 entweder einen Stdlib-Helfer oder eine Ein-Datei-Implementierung für UUIDv7. Unten finden Sie die kanonischen Rezepte, die Sie in Ihre Codebasis einfügen können — in Browser-JS, Node.js, Go, Python und PostgreSQL.
UUIDv7 in reinem Browser-/Node-JS — RFC-9562-Aufbau
function uuidv7() {
const ts = BigInt(Date.now());
const rand = new Uint8Array(10);
crypto.getRandomValues(rand);
const b = new Uint8Array(16);
b[0] = Number((ts >> 40n) & 0xFFn);
b[1] = Number((ts >> 32n) & 0xFFn);
b[2] = Number((ts >> 24n) & 0xFFn);
b[3] = Number((ts >> 16n) & 0xFFn);
b[4] = Number((ts >> 8n) & 0xFFn);
b[5] = Number( ts & 0xFFn);
b[6] = (rand[0] & 0x0F) | 0x70; // version = 7
b[7] = rand[1];
b[8] = (rand[2] & 0x3F) | 0x80; // variant = RFC 4122
for (let i = 9; i < 16; i++) b[i] = rand[i - 6];
const h = Array.from(b, x => x.toString(16).padStart(2,'0')).join('');
return `${h.slice(0,8)}-${h.slice(8,12)}-${h.slice(12,16)}-${h.slice(16,20)}-${h.slice(20)}`;
}
// usage:
const id = uuidv7();
console.log(id); // -> '018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55'
// generate a batch and verify chronological sort:
const batch = Array.from({ length: 5 }, uuidv7);
batch.sort(); // sorts by creation time without a separate timestampNode.js v26.1.0+ — eingebautes crypto.randomUUIDv7()
import { randomUUIDv7 } from 'node:crypto';
// Added in Node.js v26.1.0 (2026-05-07).
// Returns an RFC 9562 version 7 UUID. The first 48 bits encode a
// millisecond Unix timestamp; the rest is CSPRNG output.
const id = randomUUIDv7();
// -> '018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55'
// The CSPRNG output is cached for performance: Node generates enough
// entropy upfront for the next ~128 UUIDs. Pass disableEntropyCache: true
// when you need each call to draw fresh randomness, e.g. directly after
// a fork() or in tight high-security loops.
const freshId = randomUUIDv7({ disableEntropyCache: true });
// IMPORTANT: per the Node docs, "the embedded timestamp relies on a
// non-monotonic clock and is not guaranteed to be strictly increasing."
// If two UUIDs land in the same millisecond OR the system clock steps
// backwards, the IDs may not sort in creation order. Use a userland
// monotonic-v7 library (e.g. uuidv7 on npm) when strict ordering matters.Go — google/uuid v1.6+ bringt UUIDv7 nativ mit
package main
import (
"fmt"
"github.com/google/uuid"
)
func newID() uuid.UUID {
id, err := uuid.NewV7()
if err != nil {
panic(err)
}
return id
}
func main() {
id := newID()
fmt.Println(id.String()) // 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55
fmt.Println(id.Time()) // embedded creation timestamp
}Python 3.13+ — stdlib uuid.uuid7()
import uuid
# Python 3.13 added uuid7() and uuid8() to the standard library.
uid = uuid.uuid7()
print(uid) # 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55
print(uid.version) # 7
# For older Python use the 'uuid7' or 'uuid-utils' PyPI packages, or:
# from uuid_extensions import uuid7PostgreSQL 18+ — native uuidv7()-Funktion
-- PG 18 ships uuidv7() natively. Use it as a primary key default:
CREATE TABLE events (
id uuid PRIMARY KEY DEFAULT uuidv7(),
body jsonb,
ts timestamptz NOT NULL DEFAULT now()
);
-- For older Postgres, install the pg_uuidv7 extension or generate client-side.
-- Migration tip: keep INDEX on (id) only — v7 already sorts chronologically,
-- so a separate (created_at) index is usually redundant.// HÄUFIGE FALLSTRICKE
> UUIDv7 verrät die Erstellungszeit — nicht für undurchsichtige Tokens verwenden
Die ersten 48 Bit jeder v7 sind ein Unix-Millisekunden-Zeitstempel. Jeder, der die UUID sieht, kann dekodieren, wann der Datensatz erstellt wurde, mit welcher Rate IDs ausgegeben werden und (mit mehreren Stichproben) die Serveruhr annähern. Das ist in Ordnung für interne Datenbank-Primärschlüssel und Log-IDs, aber für Passwort-Reset-URLs, Freigabelinks, Sitzungs-IDs oder Einladungscodes verwenden Sie stattdessen UUIDv4 oder eine per CSPRNG erzeugte Zufallszeichenkette.
> Uhren-Rücksprung bricht die Monotonie
Wenn die Systemuhr rückwärts springt (NTP-Schritt, VM-Migration, Schaltsekunde), können naiv erzeugte v7-UUIDs Werte erzeugen, die vor zuvor ausgegebenen IDs sortieren. RFC 9562 §6.2 empfiehlt Methode 2 (monotoner Zufall): die zuletzt erzeugte UUID verfolgen und, wenn der Zeitstempel nicht voranschreitet, stattdessen den Zufallsanteil inkrementieren. Der Schalter Monoton dieses Tools macht genau das.
> v7 ist in sicherheitskritischen Kontexten kein Drop-in-Ersatz für v4
Zufällig aussehende IDs (v4) werden oft versehentlich als Bearer-Tokens verwendet: „wer die UUID kennt, kann die Zeile lesen.“ v7 hat nur 74 Zufallsbits und ein vorhersehbares Zeitstempel-Präfix, was zwar weiterhin kollisionsresistent ist, aber weit weniger Unvorhersehbarkeit bietet als die 122 Zufallsbits von v4. Wenn etwas als Berechtigung behandelt wird, erzeugen Sie ein separates kryptografisches Token, anstatt den v7-Primärschlüssel wiederzuverwenden.
> Zeichenkettenvergleich funktioniert nur in kleingeschriebener, bindestrichgetrennter Form
Die chronologische Sortierung von v7 beruht auf dem lexikografischen Vergleich der kanonischen 36-Zeichen-Kleinbuchstaben-Zeichenkette — oder auf dem byteweisen Vergleich des zugrunde liegenden 16-Byte-Werts. Das Mischen von Groß- und Kleinschreibung, das Entfernen von Bindestrichen auf halbem Weg oder das Speichern einiger Zeilen als {...}-umklammert und anderer ohne führt jeweils zu einer Sortierreihenfolge, die nicht mehr der Erstellungszeit entspricht. Wählen Sie eine kanonische Form pro Spalte und erzwingen Sie sie mit einer CHECK-Bedingung.
> 48-Bit-Zeitstempel läuft im Jahr 10889 über
2^48 Millisekunden sind ungefähr 8.925 Jahre nach der Unix-Epoche — das Zeitstempelfeld läuft am 02.08.10889 UTC über. Wenn Ihr Code behauptet, dass der eingebettete Zeitstempel in einem sinnvollen Bereich liegt, setzen Sie die Obergrenze auf 281.474.976.710.655 ms (das Maximum, das eine vorzeichenlose 48-Bit-Ganzzahl aufnehmen kann), anstatt ein nahezu zukünftiges Jahr fest zu codieren, das in einem Jahrhundert falsch sein wird.
>> häufig gestellte fragen
F: Was ist UUIDv7?
A: UUIDv7 ist ein in RFC 9562 (Mai 2024) definierter 128-Bit-Bezeichner, der einen 48-Bit-Unix-Millisekunden-Zeitstempel mit 74 Bit Zufälligkeit und den Standard-Versions- + Variantenbits kombiniert. Das Ergebnis ist eine global eindeutige ID, die auch chronologisch nach Erstellungszeit sortiert — das Beste aus beiden Welten. Sie wurde speziell entwickelt, um den Datenbankindex-Schmerz zu beheben, der durch zufällige UUIDv4-Primärschlüssel verursacht wird, bei denen jede Einfügung auf einer anderen B-Baum-Seite landet und massive Schreibverstärkung verursacht.
F: Wie unterscheidet sich UUIDv7 von UUIDv4?
A: UUIDv4 ist vollständig zufällig (122 Zufallsbits) und hat über die Versions- + Variantenfelder hinaus keine Struktur. Zwei v4, die eine Mikrosekunde auseinander erzeugt wurden, sortieren an völlig unterschiedliche Positionen, was großartig für Unvorhersehbarkeit, aber schrecklich für B-Baum-Indizes ist. UUIDv7 setzt einen 48-Bit-Unix-Millisekunden-Zeitstempel an den Anfang, sodass v7, die zeitlich nahe erzeugt wurden, auch im Speicher nahe sortieren. Kompromiss: v7 verrät die Erstellungszeit und hat nur 74 statt 122 Zufallsbits — weiterhin kollisionsresistent, aber als geheimes Token ungeeignet.
F: Sollte ich von UUIDv4 auf UUIDv7 migrieren?
A: Für interne Datenbank-Primärschlüssel in schreibintensiven Tabellen — ja, fast immer. Die Indexfragmentierung, die v4 verursacht, kann die Kosten der eigentlichen Abfragen in den Schatten stellen, besonders bei PostgreSQL oder MySQL mit InnoDB-Cluster-Indizes. Für Tokens, die Benutzern angezeigt, in URLs eingebettet oder als Berechtigungen behandelt werden („wer die UUID kennt, kann auf die Ressource zugreifen“), behalten Sie v4 oder verwenden Sie ein separates Zufallstoken — v7 verrät die Erstellungszeit. Ein gängiges Muster sind v7-Primärschlüssel für interne Joins plus ein separater zufälliger Slug für die öffentlich sichtbare URL.
F: Ist UUIDv7 dasselbe wie ULID, KSUID oder Snowflake?
A: Konzeptionell ähnlich — alle vier sind zeitlich geordnete IDs — aber die Bit-Layouts und Kodierungen unterscheiden sich. ULID verwendet Crockford base32 und ein anderes Millisekunden-Layout. KSUID kodiert einen 32-Bit-Zeitstempel + 128-Bit-Nutzlast als 27 base62-Zeichen. Snowflake ist eine Twitter-spezifische 64-Bit-ID mit Worker-IDs. UUIDv7 ist das IETF-Standardäquivalent, kodiert in der kanonischen 8-4-4-4-12-Hex-Form, sodass jede UUID-Bibliothek, jeder Datenbank-UUID-Typ und jeder JDBC-/ODBC-Treiber sie bereits versteht. Wenn Sie 2025+ neu anfangen, bevorzugen Sie v7 — es ist der Standard.
F: Wie viele UUIDv7 kann ich pro Millisekunde vor Kollisionen erzeugen?
A: Innerhalb einer einzelnen Millisekunde sorgen nur die 74 Zufallsbits (12 in rand_a + 62 in rand_b) für Eindeutigkeit. Nach der Geburtstags-Kollisionsschranke können Sie in derselben ms etwa 2^37 ≈ 137 Milliarden v7 erzeugen, bevor eine 50%-Kollisionschance besteht — für jedes realistische System praktisch unbegrenzt. Über Millisekunden hinweg unterscheidet der Zeitstempel selbst, sodass das globale Kollisionsrisiko über die Lebensdauer eines Systems vernachlässigbar ist. Mit aktiviertem Schalter Monoton sind Kollisionen innerhalb einer Millisekunde konstruktionsbedingt null (der Zufallsanteil wird inkrementiert).
F: Kann ich den Zeitstempel aus einer UUIDv7 extrahieren?
A: Ja — der Zeitstempel sind die ersten 48 Bit, also die ersten 12 Hex-Zeichen mit entfernten Bindestrichen. Verketten Sie die ersten drei Bindestrichgruppen (8 + 4 = 12 hex digits), parsen Sie sie als Hexadezimal-Ganzzahl und Sie haben den Unix-Zeitstempel in Millisekunden. Verwenden Sie den Decoder oben, um dies interaktiv zu tun, oder im Code: parseInt(uuid.replace(/-/g,'').slice(0,12), 16). Das Ergebnis ist der Millisekunden-Moment, in dem die UUID erzeugt wurde, genau auf die Systemuhr zu diesem Zeitpunkt.
F: Wie sieht die Versionsziffer in einer UUIDv7 aus?
A: Die dritte durch Bindestriche getrennte Gruppe beginnt immer mit der Ziffer 7. Zum Beispiel: 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55. Die vierte Gruppe beginnt immer mit 8, 9, a oder b — das sind die vier möglichen Werte, bei denen die oberen zwei Bit 10 sind (die RFC-4122-Variante). Wenn die Versionsziffer nicht 7 ist, ist die UUID eine andere Version (häufig 4 für zufällig oder 1 für zeitbasierte v1) und sortiert nicht chronologisch.
F: Unterstützen PostgreSQL / MySQL UUIDv7 nativ?
A: PostgreSQL 18 (veröffentlicht im September 2025) bringt uuidv7() als eingebaute Funktion mit. Frühere Versionen benötigen die pg_uuidv7-Erweiterung oder clientseitige Erzeugung. MySQL 8.x hat kein natives v7; verwenden Sie den UUID_TO_BIN(uuid, 1)-Helfer (der Zeitstempel-Bytes für die Sortierreihenfolge vertauscht) nur für v1 — für v7 erzeugen Sie clientseitig. SQL Server, Oracle und SQLite erwarten alle clientseitige v7-Erzeugung. Die meisten ORMs (Hibernate, Entity Framework, Sequelize, Prisma, SQLAlchemy) unterstützen v7 inzwischen entweder nativ oder über ein Plugin.
F: Ist die Monoton-Option RFC-9562-konform?
A: Ja. RFC 9562 §6.2 beschreibt explizit drei Methoden, um die Reihenfolge innerhalb einer Millisekunde sicherzustellen: (1) Zufallsfüllung, (2) monotoner Zufall — einen Zähler inkrementieren, wenn der Zeitstempel nicht voranschreitet, (3) Sub-Millisekunden-Zeitstempelpräzision. Das Kontrollkästchen Monoton in diesem Tool implementiert Methode 2: Wenn zwei UUIDs denselben 48-Bit-Zeitstempel teilen, wird der Zufallsanteil der zweiten auf previous_random + 1 gesetzt, anstatt neu gezogen zu werden. Dies garantiert eine strenge Reihenfolge bei der Batch-Erzeugung und bleibt dabei vollständig spezifikationskonform.
F: Werden meine Daten irgendwohin gesendet?
A: Nein. Die gesamte UUIDv7-Erzeugung, -Dekodierung, -Sortierung, das Kopieren und Herunterladen geschieht vollständig in Ihrem Browser als reines JavaScript. Die Seite stellt nie eine Netzwerkanfrage, wenn Sie auf GENERIEREN, DEKODIEREN, KOPIEREN oder HERUNTERLADEN klicken — Sie können dies mit dem Netzwerk-Tab der DevTools Ihres Browsers überprüfen. Wir protokollieren keine Zeitstempel, benutzerdefinierten Seeds, erzeugten UUIDs oder dekodierten Ausgaben. Die Seite selbst ist statisches HTML, das von einem CDN ausgeliefert wird, sodass keine Eingabe jemals unsere Infrastruktur erreicht. Das macht das Tool sicher für den Einsatz mit Produktions-Datenbank-IDs, internen Logs oder anderen Daten, die Sie lieber nicht über einen Drittanbieter-Server leiten möchten.
F: Kann ich UUIDv7 in Java / .NET / Rust verwenden?
A: Ja. Java hat com.fasterxml.uuid:java-uuid-generator 5.0+ und JDK 21 hat es über Bibliotheks-Helfer. .NET 9 bringt Guid.CreateVersion7() in der BCL mit. Rust verwendet Uuid::now_v7() der uuid-Crate hinter dem v7-Feature-Flag. Die meisten anderen Ökosysteme (Elixir, Ruby, PHP, Swift, Kotlin) haben ebenfalls gut gepflegte Pakete — suchen Sie im Paketregister der Sprache nach „uuidv7“ oder „uuid v7“. Das Wire-Format ist über alle hinweg identisch, sodass eine in Go erzeugte v7 von JavaScript ohne jegliche Transformation geparst und der Zeitstempel extrahiert werden kann.
F: Hat Node.js einen eingebauten UUIDv7-Generator?
A: Ja — seit Node.js v26.1.0 (veröffentlicht am 07.05.2026) stellt die Standardbibliothek crypto.randomUUIDv7([options]) bereit. Importieren Sie es als import { randomUUIDv7 } from 'node:crypto' und rufen Sie es ohne Argumente auf, um eine RFC-9562-v7-UUID-Zeichenkette zu erhalten. Die einzige unterstützte Option ist disableEntropyCache (Boolean, Standard false); standardmäßig cacht Node im Voraus genügend Zufallsdaten, um die nächsten ~128 UUIDs zu erzeugen, was dieselbe Optimierung wie bei crypto.randomUUID() ist. Wichtiger Vorbehalt aus den offiziellen Docs: „der eingebettete Zeitstempel beruht auf einer nicht-monotonen Uhr und ist nicht garantiert streng steigend.“ Mit anderen Worten: Zwei in derselben Millisekunde erzeugte UUIDs oder beliebige UUIDs, die über einen NTP-Schritt / VM-Uhren-Rückwärtsversatz hinweg erstellt wurden, sortieren möglicherweise nicht in Erstellungsreihenfolge. Wenn Sie strenge Monotonie innerhalb einer Millisekunde benötigen, verwenden Sie eine Userland-Implementierung, die RFC 9562 §6.2 Methode 2 folgt (das npm-Paket uuidv7 oder dieses Tool mit aktiviertem Schalter Monoton).
F: Wie speichere ich UUIDv7 effizient in einer Datenbank?
A: Speichern Sie sie als 16-Byte-Binärtyp statt als 36-Zeichen-Zeichenkette — Sie sparen 20 Byte pro Zeile, halbieren die Indexgröße und gewinnen einen schnelleren Vergleichspfad. Verwenden Sie den uuid-Typ von PostgreSQL, MySQL BINARY(16), SQL Server uniqueidentifier oder SQLite BLOB. Fügen Sie eine CHECK-Bedingung hinzu, dass das Versions-Nibble gleich 7 ist, wenn Sie eine Erzwingung wünschen. Mit v7 clustern die Zeilen natürlich nach Erstellungszeit, sodass ein abdeckender Index auf (uuid_pk) normalerweise ausreicht — Sie benötigen keinen separaten (created_at)-Index für chronologische Abfragen.