UUID v7-generator

Vad är UUID v7 och hur fungerar formatet internt

UUID v7 är ett 128‑bitars identifierarformat som definierats i RFC 9562. Till skillnad från äldre versioner bygger det på en kombination av tid och slump. De första 48 bitarna utgör en Unix millisekund‑tidsstämpel räknad från epoken 1970‑01‑01. Därefter följer 74 bitar slumpmässiga data, plus två bitar för variant‑ och versionsfält. Den fullständiga textrepresentationen är 36 tecken lång (32 hexadecimala siffror och fyra bindestreck i standardfallet).

Tidsstämpeln gör att ID:n som skapas vid olika tidpunkter automatiskt blir kronologiskt sorterade när de jämförs som strängar. Det innebär att om du genererar en UUID v7 nu och en om en minut, kommer den första att vara lexikografiskt mindre än den andra. De första tolv hexadecimala tecknen (48 bitar) kodar millisekundvärdet, så en snabb blick på strängens början avslöjar skapelsetidpunkten.

De slumpmässiga bitarna hämtas från webbläsarens kryptografiskt starka slumptalsgenerator (Crypto.getRandomValues). I praktiken innebär det att sannolikheten för kollision mellan två ID som genereras vid olika tillfällen är försumbar – även vid massgenerering inom samma millisekund räcker de 74 slumpbitarna för att garantera unikhet långt över praktiska gränser.

Varför tidsbaserad sortering förbättrar databasprestanda

I relationsdatabaser lagras primärnycklar ofta i B‑trädstrukturer. När nycklarna är slumpmässiga (som i UUID v4) sprids varje ny insättning över hela indexet. Det leder till sid‑splittringar, fragmentering och ökad skrivbelastning. Med UUID v7 hamnar nycklar som skapas inom samma tidsperiod i närheten av varandra i indexet. Det minskar antalet sidbyten och förbättrar cache‑träffar radikalt.

Fenomenet är särskilt påtagligt i system med hög insättningsfrekvens. Ett B‑träd med en monotont ökande nyckel (som en sekvens eller en tidsstämpel) kräver i princip bara att den högra kanten av indexet uppdateras. UUID v7 uppnår samma effekt utan att man förlorar fördelarna med global unikhet – varje ID är fortfarande ogissbart och kan genereras oberoende av en central sekvensgenerator.

Observera dock att UUID v7 inte garanterar strikt ordning för ID som skapats inom samma millisekund. Två ID:n med samma tidsstämpel sorteras efter sina slumpbitar, vilket innebär att sorteringsordningen inom millisekunden inte nödvändigtvis motsvarar den verkliga skapelseordningen. För de flesta applikationer är detta oväsentligt – skillnaden i tid är ändå bara en millisekund.

UUID v7 jämfört med UUID v4: slump, index och språk

Största fördelen med v7 är indexprestandan. I praktiken har många projekt bytt från v4 till v7 enbart för att minska fragmenteringen i databasen. Samtidigt behåller man alla andra fördelar: ID:n kan genereras offline, de är unika över hela systemet, och de kräver inget samordningsprotokoll.

En vanlig fråga är om v7 är lika säkert som v4. Eftersom de slumpmässiga bitarna i v7 hämtas från samma kryptografiskt starka källa som i v4, finns ingen praktisk skillnad i ogissbarhet. Tidsstämpeln läcker visserligen information om när ID:t skapades, men det är sällan ett säkerhetsproblem – snarare en användbar metadatakälla.

Begränsningar: samma millisekund, strikt ordning och parallellgenerering

UUID v7 är inte en strikt sekvens. Om två processer genererar varsitt ID i exakt samma millisekund, kan ordningen mellan dem vara vilken som helst. Det beror på att slumpbitarna avgör sorteringen inom samma tidsskiva. För applikationer som kräver total ordning (t.ex. händelseloggar där sekvensnummer måste garanteras) räcker inte v7 ensamt – man måste då kombinera med en lokal räknare eller använda ett format som ULID (som lägger till en slumpmässig komponent inom millisekunden, men inte heller ger strikt ordning i alla implementeringar).

Formatets längd (36 tecken) kan vara en nackdel i mycket datortäta miljöer, men det är samma som för tidigare UUID‑versioner och standardiserat över hela ekosystemet. Om lagringsutrymme är en begränsning kan man överväga att lagra ID:t binärt (16 byte) istället för som text.

En annan aspekt: om systemet genererar ID:n med mycket hög frekvens (flera miljoner per sekund) kan tidsstämpelns millisekundprecision bli en flaskhals. Men för de flesta applikationer – och för det här verktygets maxgräns på 100 ID:n – är det helt irrelevant.

Lokal generering i webbläsaren: integritet och stark slump

Verktyget genererar alla ID:n lokalt i användarens webbläsare med hjälp av crypto.getRandomValues. Ingenting skickas till BroBroGo eller någon annan server. Det innebär att känsliga projekt kan använda sidan utan att exponera sina data. Ingen nätverksfördröjning påverkar genereringstiden – alla 100 ID:n skapas på några mikrosekunder efter att ett alternativ ändrats.

Eftersom slumptalsgeneratorn är kryptografiskt stark, är resultatet lika säkert som om du genererat dem på en server med OpenSSL. Detta är särskilt viktigt för säkerhetsmedvetna utvecklare som inte vill lita på en serverbaserad tjänst för att skapa ogissbara nycklar.

Användaren kan justera två visningsalternativ: versaler och bindestreck. Att slå på versal (UPPERCASE) gör att alla bokstäver i hex‑strängen blir versaler (A–F). Att stänga av bindestreck tar bort de fyra strecken, vilket ger en kompakt 32‑teckens sträng. Varken formatet eller slumpen påverkas – det är endast presentationen som förändras.

Användningsområden och målgrupp

UUID v7 är idealiskt för:

• Distribuerade system där noder måste generera unika ID:n oberoende av varandra, men ändå vill ha kronologisk sortering.
• Databasprimärnycklar i system med hög skrivfrekvens – indexprestandan blir dramatiskt bättre jämfört med UUID v4.
• Händelseloggar och revisionsspår där skapelsetidpunkten är en viktig metadata, och där ID:n måste vara sorterbara över flera noder.
• Migrering från UUID v4 – samma längd och API, bättre prestanda, ingen ändring i applikationskoden utöver vilken funktion som anropas.

Utvecklare som bygger mikrotjänster, IoT‑plattformar eller någon form av händelsebutik har stor nytta av formatets egenskaper. Databasadministratörer uppskattar den minskade indexfragmenteringen. Och säkerhetsmedvetna ingenjörer kan fortsätta lita på att ID:n inte går att gissa.

FAQ – vanliga frågor om UUID v7

Vad är skillnaden mellan UUID v7 och ULID?
Båda är tidsbaserade format. UUID v7 använder 48 bitars tidsstämpel och 74 bitars slump, totalt 128 bitar (36 tecken). ULID använder 48 bitars tidsstämpel och 80 bitars slump, men representeras med 26 tecken i en annan teckenuppsättning (Crockford Base32). UUID v7 är standardiserat via RFC 9562 och har bredare verktygsstöd inom exempelvis Java,.NET och Python.

Kan jag sortera UUID v7 i SQL?
Ja, om du lagrar dem som strängar (CHAR(36) eller VARCHAR(36)) fungerar lexikografisk sortering. För bästa prestanda i PostgreSQL finns det datatyper som uuid (lagrar 16 byte) – sortering fungerar även där, men den binära representationen är annorlunda än textsträngen. Kontrollera dokumentationen för din databas.

Varför är UUID v7 36 tecken långt?
Det är standardrepresentationen för UUID enligt RFC 4122/RFC 9562: 32 hexadecimala tecken grupperade med fyra bindestreck (8-4-4-4-12). Utan bindestreck blir det 32 tecken. Längden kommer av att man måste representera 128 bitar i hexadecimal form (4 bitar per tecken = 32 tecken) plus fyra avgränsare.

Hur säker är slumpen i webbläsarens crypto.getRandomValues?
Den anses kryptografiskt stark och är densamma som används för TLS‑nycklar. Det finns inga kända sårbarheter i moderna webbläsare. För de flesta applikationer är den långt mycket bättre än Math.random() eller andra pseudoslumptalsgeneratorer.

Vad händer om jag genererar 100 ID:n samtidigt?
Alla får samma tidsstämpel (den aktuella millisekunden) men unika slumpbitar. De blir sorterade efter slumpen, inte efter den inbördes genereringstiden. Det är helt normalt och ofarligt.

Kan UUID v7 ersätta auto‑increment helt?
Ja, i många fall. Det kräver dock att du accepterar en något större lagringsvolym (16 byte mot 4–8 byte för heltal) och att sorteringen inom millisekunder är odefinierad. För distribuerade system utan central sekvensgenerator är v7 ett utmärkt val.