UUID v1, v4, v7 : quelle version choisir ?
UUID v4 reste le défaut, mais UUID v7 (RFC 9562, 2024) le détrône pour les bases SQL. Comparatif et critères de choix.
La RFC 9562 (mai 2024) a officialisé les UUID v6, v7 et v8, complétant la RFC 4122 originelle. Le choix de la version a un impact direct sur les performances et la vie privée. Voici comment trancher.
Tableau comparatif
| Version | Source d'entropie | Trié par date | MAC dévoilée | Performance B-tree |
|---|---|---|---|---|
| v1 | Timestamp + MAC | ~ (peu intuitif) | ✅ (problème) | Mauvaise |
| v4 | 122 bits aléatoires | ❌ | — | Mauvaise (random) |
| v6 | Timestamp réordonné | ✅ | — | Bonne |
| v7 | Timestamp Unix + 74 bits aléatoires | ✅ | — | Excellente |
UUID v1 — Le pionnier (1996), à éviter
Combine un timestamp (60 bits, précision 100 nanosecondes depuis 1582) et une adresse MAC (48 bits). Inconvénient majeur : la MAC dévoile le matériel qui a généré l'UUID, un problème de vie privée révélé en 1999 dans l'affaire Melissa Worm. Beaucoup d'implémentations modernes remplacent la MAC par un nombre aléatoire — ce qui revient à un v4 avec timestamp non standard.
UUID v4 — Le défaut historique, à garder pour la plupart des cas
122 bits 100 % aléatoires (sur 128). Aucune fuite d'information. Probabilité de collision négligeable. Limitation : insertion dans un index B-tree (PostgreSQL, MySQL) provoque des page splits aléatoires, fragmentant l'index et dégradant les performances sur les grandes tables (millions de lignes).
À utiliser pour :
- Tokens de session, magic links, identifiants temporaires.
- API idempotency keys.
- Identifiants d'objets en stockage cloud (S3, etc.).
- Tout cas sans contrainte de tri ou de performance d'index.
UUID v7 — Le nouveau défaut pour les bases SQL
Standardisé en mai 2024 (RFC 9562). Structure :
- 48 bits de timestamp Unix en millisecondes (suffisant jusqu'en 10889 après J.-C.).
- 4 bits version (7).
- 74 bits aléatoires.
Conséquence pratique : les UUID v7 générés successivement sont triés par date de création, donc insérés en fin d'index B-tree — comportement similaire à un auto-incrément. Performance d'écriture multipliée par 10 à 100× sur les grandes tables PostgreSQL/MySQL.
Implémentations 2026
- PostgreSQL 17+ :
uuid_generate_v7()(extensionpgcrypto). - JavaScript :
crypto.randomUUID()génère du v4 ; pour v7 utiliser les libsuuidv7ouuuid@10. - Python 3.12+ :
uuid.uuid7()(PEP 728, en cours). - Rust : crate
uuid≥ 1.7.
Recommandation pratique
| Cas d'usage | Version recommandée |
|---|---|
| Clé primaire SQL (PostgreSQL, MySQL) | v7 |
| Clé primaire NoSQL (MongoDB, DynamoDB) | v4 (l'index n'est pas un B-tree) |
| Token de session, magic link | v4 (l'aléa total est mieux pour la sécurité) |
| Idempotency key d'API | v4 |
| Identifiant logué (analytics) | v4 ou v7 selon contexte |
| Tout nouveau projet | v7 par défaut, sauf besoin de pure imprévisibilité |