UUID Generator

Wat is een UUID?

Een UUID (Universally Unique Identifier, RFC 4122 / RFC 9562) is een 128-bit identifier die zonder centrale autoriteit wordt gemaakt en toch praktisch wereldwijd uniek is. De tekstvorm bestaat uit 32 hexadecimale cijfers, gescheiden in vijf groepen `8-4-4-4-12` met koppeltekens, in totaal 36 tekens inclusief scheidingstekens.

Er bestaan meerdere versies. v1 gebruikt tijd + MAC-adres (privacyrisico), v3 en v5 leiden de ID af van een naam plus namespace (deterministisch), v4 is puur willekeurig (de moderne default), en v7 is tijdgeordend en lost het database-indexprobleem van v4 op.

Daarnaast zijn ULID en NanoID populaire niet-IETF alternatieven. ULID is een sorteerbare string van 26 tekens, NanoID een korte URL-veilige ID (vaak 21 tekens). Welke variant past, hangt vooral af van de geplande opslag en URL-layout.

v4 vs. v7 vs. ULID vs. NanoID

Een snel overzicht van de vier belangrijkste varianten:

Crockford base32 (ULID) laat I, L, O en U weg om verwarring met 1, 0 en V te voorkomen.

Wanneer kies ik welke variant?

Vuistregels uit het echte gebruik:

• UUID v4: solide default voor niet-gesorteerde ID's (sessies, idempotency keys, correlatie-ID's). 122 bits entropie, kans op botsing absurd laag.
• UUID v7: aanbevolen voor database primary keys. De eerste 48 bits zijn een unix-ms-tijdstempel, dus nieuwe rijen gaan naar de staart van B-tree-indexen (lage page-split-druk, goede locality).
• ULID: wanneer u een tijdgeordend ID wilt dat leesbaar blijft in URLs en logs. 26 tekens, korter dan UUID, maar geen RFC-standaard. Sommige tooling-stacks missen native ondersteuning.
• NanoID-21: ideaal voor zichtbare share links en slugs. 21 tekens, URL-veilig, ongeveer 126 bits entropie (meer dan UUID v4) bij een veel kortere lengte.

Waarom geen auto-increment ID's in productie?

Auto-increment ID's (bv. `BIGINT IDENTITY` of `SERIAL`) zijn eenvoudig, snel en index-vriendelijk, maar falen op verschillende moderne eisen:

• Lekken bedrijfsmetrieken: een concurrent die twee opeenvolgende ordernummers ziet, leert direct hoeveel orders er per dag passeren.
• Geven geen botbescherming: `/users/123` is wat elke brute-force-crawler van 1 tot n aftloopt, elk ID is triviaal opsombaar.
• Bemoeilijken gedistribueerde systemen: een multi-region setup of offline clients (mobiele apps, edge) moeten sequenties coördineren of een centrale ID-service draaien. UUID's omzeilen dat geheel.
• Kunnen niet client-side worden toegekend: een frontend kan geen auto-increment ID reserveren voor de INSERT (bv. voor optimistic UI). UUID's worden in de client gegenereerd en via de `INSERT` doorgegeven.
• Zijn niet testvriendelijk: tests die data terugrollen botsen met sequencewaarden of laten gaten achter. UUID's blijven stabiel doorheen tests.

Aanbeveling: gebruik auto-increment voor interne, puur operationele tabellen (migratielog, counters), en gebruik UUID v7 als default primary key voor domeinentiteiten (User, Order, Document).

UUID-prestaties in databases

Het meest voorkomende bezwaar tegen UUID's is "die slopen mijn indexprestaties". Dat klopte voorheen deels, maar is ofwel makkelijk op te lossen ofwel volledig vermeden met v7/ULID.

Het echte probleem is niet de grootte (16 bytes vs. 8 bytes voor een bigint), maar de willekeurige insert-volgorde: bij v4 belandt elke insert ergens midden in de B-tree, wat page splits, koude caches en write amplification veroorzaakt.

• Oplossing 1: gebruik UUID v7 of ULID in plaats van v4. De tijdgeordende bits zorgen ervoor dat nieuwe rijen naar de staart van de index gaan.
• Oplossing 2: gebruik in PostgreSQL het type `uuid`, in MySQL `BINARY(16)` (in plaats van `CHAR(36)`), wat 20 bytes per rij bespaart en vergelijkingen integer-snel maakt.
• Oplossing 3: plaats de clustered index op een andere sleutel (bv. monotoon stijgend) en houd de UUID als secundaire sleutel. Gebruikelijk in MS SQL Server.
• Oplossing 4: voor bulk-inserts, voer in op gesorteerde volgorde of gebruik een bulk loader die de index aan het einde herbouwt.

Op recente Postgres- en MySQL-versies is UUID v7 als primary key sneller dan v4 in vrijwel elke workload en ongeveer op gelijke voet met bigint auto-increment, terwijl alle voordelen behouden blijven (geen leak, gedistribueerde aanmaak, client-side).

Backends met hoge throughput bij KernelHost

Wie miljoenen UUID's per dag in een database opslaat, wil NVMe-storage, ECC RAM en stabiele uplink. KernelHost draait eigen dedicated en VPS-servers in Frankfurt FRA01 met DDoS-bescherming, IPv4 + IPv6 en 1 Gbit/s. Lage RTT naar Duitse en Oostenrijkse klanten, eerlijke prijzen. Bedrijfszetel Wenen (AT), datacenter Frankfurt (DE).

UUID FAQ