Elke moderne database, elk gedistribueerd systeem en elke API gebruikt unieke identificaties — en in 2026 is de standaard die deze regelt fundamenteel veranderd. Een UUID (Universally Unique Identifier, universeel unieke identificatie) is een 128-bit label dat informatie tussen computersystemen kan identificeren zonder enige centrale coördinatie. Onder de nieuwe RFC 9562 (die RFC 4122 in mei 2024 verving) is het landschap verschoven: UUID v4 blijft de standaardkeuze voor willekeurige ID’s, maar UUID v7 is nu de aanbevolen standaard voor primaire sleutels van databases, omdat de tijdgeordende structuur fragmentatie van B-tree-indexen voorkomt.
Deze gids behandelt het volledige beeld: hoe UUID’s werken, welke versie wanneer te gebruiken en hoe je ze correct implementeert.
RFC 9562 begrijpen: de moderne UUID-standaard
Een UUID is een 128-bit getal waarvan de uniciteit praktisch gegarandeerd is — zonder centrale instantie. Volgens Wikipedia is de kans dat twee UUID’s botsen zo dicht bij nul dat dit voor echte toepassingen onmogelijk wordt geacht. Verschillende teams kunnen onafhankelijk gegevens labelen, ervan overtuigd dat hun ID’s niet zullen botsen.
In mei 2024 publiceerde de IETF RFC 9562 en nam de oude RFC 4122 uit gebruik. De update was een antwoord op de eisen van moderne gedistribueerde systemen, die ID’s nodig hadden die zowel uniek als op tijd sorteerbaar waren. Er werden drie nieuwe versies geïntroduceerd: v6, v7 en v8.
Anatomie van een UUID: versies en varianten
Je ziet een UUID meestal als 32 hexadecimale tekens, verdeeld in vijf groepen door streepjes (8-4-4-4-12):
550e8400-e29b-41d4-a716-446655440000
^
version
Twee sleutelvelden vertellen je hoe de UUID is gegenereerd:
| Veld | Locatie | Wat het je vertelt |
|---|---|---|
| Versie-bits | De eerste 4 bits van de 7e byte (eerste teken van de 3e groep) | Welk algoritme is gebruikt (bijv. “4” = v4, “7” = v7) |
| Variant-bits | 9e byte | De UUID-variant — RFC 9562 gebruikt een 10-bitpatroon |
Zoals SnapUtils uitlegt, scheiden de variant-bits moderne RFC 9562-UUID’s van oudere Apollo- of Microsoft-formaten.
Waarom UUID v7 de nieuwe gouden standaard voor databases is
Het grootste nadeel van UUID v4 is dat deze volledig willekeurig is. Bij gebruik als primaire sleutel in een B-tree-index moet de database nieuwe rijen op onvoorspelbare posities invoegen. Volgens CreateUUID veroorzaakt dit “paginasplitsingen” (page splits) — de database moet voortdurend gegevens herorganiseren om ruimte te maken, wat leidt tot tragere schrijfprestaties en verspild geheugen.
UUID v7 lost dit op door een 48-bit Unix Epoch-tijdstempel (milliseconde-nauwkeurigheid) aan het begin van de ID te plaatsen. Daardoor zijn de ID’s monotoon stijgend — nieuwe zijn altijd groter dan oude. De database kan gewoon aan het einde van de index toevoegen, wat je de prestaties van een opeenvolgend geheel getal geeft met de wereldwijde uniciteit van een UUID.
Hoe UUID v7 tijd en entropie in balans brengt
UUID v7 vult de resterende 74 bits met een CSPRNG (cryptografisch veilige pseudo-willekeurige getallengenerator). Volgens Wikipedia zou je ongeveer 1 miljard UUID’s per seconde gedurende 85 jaar moeten genereren om een 50% botsingskans te bereiken. Voor elke echte toepassing is UUID v7 in de praktijk botsingsvrij.
Best practices voor opslag: Binary(16) vs. String(36)
Hoe je UUID’s opslaat is net zo belangrijk als welke versie je gebruikt:
| Opslagformaat | Ruimte | Indexprestaties | Aanbeveling |
|---|---|---|---|
| Binary(16) | 16 bytes | Hoog (compact) | Best practice |
| Native UUID-type | 16 bytes | Hoog (geoptimaliseerd) | Beste voor PostgreSQL |
| String (Char 36) | 36–72 bytes | Laag (gefragmenteerd) | Vermijden |
SnapUtils raadt altijd aan om native types te gebruiken in plaats van strings. In PostgreSQL slaat het native uuid-type gegevens op in een compact 16-byte binair formaat, terwijl het standaard stringgebaseerde query’s ondersteunt.
UUID vs. GUID: is er een verschil?
Een GUID (Globally Unique Identifier, globaal unieke identificatie) is Microsofts implementatie van de UUID-standaard. Historisch gezien was er een verschil in byte-volgorde (endianness) — vroege Microsoft GUID’s gebruikten little-endian voor de eerste drie velden, terwijl standaard UUID’s big-endian (netwerkbyte-volgorde) gebruikten (SnapUtils).
Tegen 2026 is dit vooral een naamgevingsconventie. Onder RFC 9562 werken ze identiek. Een Guid.NewGuid() in .NET is volledig compatibel met een uuid.uuid4() in Python. Je hoort “GUID” in Windows/Azure-kringen en “UUID” in Linux- en open source-gemeenschappen.
Moderne UUID’s implementeren: taal voor taal
| Taal | UUID v4 | UUID v7 |
|---|---|---|
| Python | Ingebouwde uuid-module |
uuid6– of uuid7-pakket |
| JavaScript | crypto.randomUUID() |
uuid npm-pakket (v10+) |
| PostgreSQL | gen_random_uuid() (PG 13+) |
Native uuidv7() (PG 17+) of extensies |
| .NET | Guid.NewGuid() |
Community-pakketten |
| Rust | uuid-crate (v1.7+) |
uuid-crate met v7-feature |
Deterministische ID’s: UUID v5
Als je elke keer dezelfde ID nodig hebt voor een bepaalde invoer (zoals een URL of gebruikersnaam), gebruik dan UUID v5. Het hasht een naamruimte-UUID en een naam-string met SHA-1 — perfect voor deduplicatie wanneer je geen centrale database kunt raadplegen.
De privacyles van UUID v1
UUID v1 gebruikt een tijdstempel en het MAC-adres van de computer. Het is grotendeels in onbruik geraakt omdat het hardware-informatie lekt. Een beroemd voorbeeld: de maker van het Melissa-virus werd gepakt omdat UUID’s in geïnfecteerde Word-documenten zijn specifieke MAC-adres bevatten.
Geavanceerde RFC 9562: v6, v8 en speciale UUID’s
RFC 9562 voegde gespecialiseerde versies toe voor nichetoepassingen van gedistribueerde systemen:
| Versie | Doel | Wanneer te gebruiken |
|---|---|---|
| v6 | Herordende v1-tijdstempel — sorteerbaar met behoud van v1’s precisie | Migratie van verouderde v1-systemen |
| v8 | Aangepast — 122 bits voor door ontwikkelaar gedefinieerde gegevens | Experimentele of leveranciersspecifieke schema’s |
| Nil UUID | 00000000-0000-0000-0000-000000000000 |
Null-plaatsaanduiding |
| Max UUID | FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF |
Eindpuntmarkering van bereik |
Conclusie
RFC 9562 heeft unieke identificaties bijgewerkt voor het moderne cloud-tijdperk. De praktische richtlijnen:
- Primaire sleutels van databases → Gebruik UUID v7 voor tijdgeordende, fragmentatievrije invoegingen
- Algemene willekeurigheid → UUID v4 is nog steeds volkomen acceptabel
- Deduplicatie → UUID v5 geeft je deterministische ID’s
- Opslag → Gebruik altijd Binary(16) of native UUID-types, nooit strings
Actiepunt: Controleer je databaseschema’s. Als je UUID v4 als primaire sleutel gebruikt in tabellen met miljoenen rijen, dan is migratie naar UUID v7 een eenvoudige wijziging die de indexfragmentatie aanzienlijk kan verminderen en query’s kan versnellen.
Veelgestelde vragen
Is een UUID hetzelfde als een GUID?
Functioneel, ja. Een GUID is Microsofts implementatie van de UUID-standaard. Onder RFC 9562 gedragen ze zich identiek — je kunt ze uitwisselbaar gebruiken tussen .NET-, Java- en Python-toepassingen.
Kunnen twee UUID’s ooit botsen in een reëel scenario?
Wiskundig mogelijk, praktisch onmogelijk. Voor UUID v4 zou je ongeveer 2,71 quintiljoen ID’s moeten genereren om een 50% botsingskans te bereiken. Volgens Generate-Random.org geeft het genereren van 1 miljard UUID’s per seconde gedurende 85 jaar je slechts 50% kans op één enkele botsing.
Moet ik UUID’s als strings of binair opslaan in mijn database?
Geef altijd de voorkeur aan Binary(16) of het native UUID-type (beschikbaar in PostgreSQL). Een string van 36 tekens verbruikt meer dan twee keer zoveel ruimte en vertraagt index-opzoekingen en joins aanzienlijk.SnapUtils merkt op dat de prestatievoordelen van RFC 9562 worden gemaximaliseerd wanneer de opslag compact blijft.
Wanneer moet ik UUID v5 gebruiken in plaats van UUID v4?
Gebruik v5 wanneer je deterministische ID’s nodig hebt — dezelfde invoer produceert altijd dezelfde UUID, zonder een database te raadplegen. Gebruik v4 wanneer je volledige willekeurigheid nodig hebt en wilt zorgen dat de identificatie niet kan worden teruggeleid naar de bron.
