UUID v4 ou v7 : quelle différence ?

La réponse courte

Choisissez l'UUID v7 pour les nouvelles clés de base de données, les identifiants d'événements, les entrées de journal et les noms de fichiers que vous voulez garder dans l'ordre chronologique. Une nouvelle valeur v7 est toujours plus grande que les anciennes : elle s'ajoute donc à la fin de l'index comme le ferait un numéro auto-incrémenté, tout en pouvant être créée sur n'importe quel serveur ou dans le navigateur sans interroger la base.

Choisissez l'UUID v4 pour les jetons, les identifiants publics dont la date de création doit rester privée, et les systèmes qui l'utilisent déjà. Une valeur v4 ne divulgue rien, et pour la plupart des applications qui ne stockent pas des millions de lignes, son ordre aléatoire coûte peu. Les deux versions sont définies dans la RFC 9562, publiée en 2024, qui a remplacé l'ancienne RFC 4122 et ajouté les versions 6, 7 et 8.

Comment un UUID est construit

Tout UUID fait 128 bits, écrits sous forme de 32 chiffres hexadécimaux répartis en cinq groupes : 8-4-4-4-12, soit 36 caractères avec les tirets. Deux champs sont fixes dans tout UUID moderne. Le premier chiffre du troisième groupe est la version, lisible d'un coup d'œil : 4 pour aléatoire, 7 pour temps Unix. Le premier chiffre du quatrième groupe est la variante, toujours 8, 9, a ou b pour les UUID standard.

Exemple de v4 : 9b2f4c1e-3a7d-4e8b-a5c2-0f6d1e9a3b47. Exemple de v7 : 019a2b3c-4d5e-7f60-8a1b-2c3d4e5f6a7b. Dans l'exemple v7, les 12 premiers chiffres hexadécimaux (019a2b3c4d5e) sont l'heure de création en millisecondes, c'est pourquoi des identifiants créés à une seconde d'écart partagent presque tout leur début.

Pourquoi le v7 est plus rapide comme clé primaire

La plupart des bases de données stockent la clé primaire dans un index B-tree, trié par clé. Avec des clés v4 aléatoires, chaque insertion tombe à un endroit au hasard dans cet arbre. Dès que l'index dépasse la mémoire disponible, les insertions relisent sans cesse d'anciennes pages sur le disque, les pages se divisent à moitié vides et l'index devient plus gros que nécessaire. Avec InnoDB (MySQL et MariaDB), la table elle-même est rangée dans l'ordre de la clé primaire : c'est toute la table qui en souffre, pas seulement l'index.

Avec des clés v7, les nouvelles lignes vont au bord droit de l'index, les pages actives restent en mémoire et les pages se remplissent entièrement. Les tests publiés par les éditeurs de bases de données et par des utilisateurs montrent couramment des insertions nettement plus rapides et des index plus petits qu'avec le v4 sur les grosses tables, même si le gain exact dépend du moteur, de la taille des lignes et du matériel. Les requêtes par plage, comme les 100 dernières commandes, deviennent aussi moins coûteuses, car les lignes récentes sont voisines.

Stockez les UUID dans un type natif de 16 octets quand il existe (uuid dans PostgreSQL, BINARY(16) dans MySQL, uniqueidentifier dans SQL Server) plutôt qu'en texte de 36 caractères. Les clés en texte sont plus de deux fois plus grosses et plus lentes à comparer.

Notes par base de données : PostgreSQL, MySQL, SQL Server, .NET

• PostgreSQL : le type uuid se trie octet par octet, l'ordre du v7 est donc conservé. PostgreSQL 18 a ajouté une fonction intégrée uuidv7() ; avec les versions plus anciennes, l'application peut fournir la valeur.
• MySQL et MariaDB : stockez en BINARY(16) avec UUID_TO_BIN(valeur) sans l'option d'échange (swap), ce qui garde l'ordre du v7. La fonction UUID() de MySQL crée un UUID de version 1, pas un v7.
• SQL Server : uniqueidentifier compare d'abord le dernier groupe d'octets, les valeurs v7 n'y sont donc pas rangées dans l'ordre du temps. Si vous avez besoin de clés séquentielles dans SQL Server, NEWSEQUENTIALID() ou un bigint identity est souvent le choix le plus simple.
• .NET : Guid.NewGuid() renvoie un v4. Depuis .NET 9, Guid.CreateVersion7() renvoie un v7.
• JavaScript : crypto.randomUUID() dans les navigateurs et Node.js renvoie un v4 ; pour le v7, il faut une bibliothèque ou une petite fonction comme celle qui fait tourner le générateur de cette page.

Le risque de collision en chiffres réels

Avec 122 bits aléatoires, une collision de v4 relève du paradoxe des anniversaires. Il faudrait environ 2,7 trillions d'UUID (2,7 x 10^18, soit 2,7 milliards de milliards) pour avoir 50 % de chances d'obtenir un seul doublon, c'est-à-dire un milliard de nouveaux identifiants par seconde pendant environ 86 ans. Un générateur aléatoire défectueux, une copie d'instantané de machine virtuelle ou un bug qui réutilise une valeur sont des causes de doublons bien plus réalistes que le hasard.

Une valeur v7 a moins de bits aléatoires, mais ils n'ont besoin d'être uniques qu'au sein de la même milliseconde. Même un service qui génère un million d'identifiants dans une milliseconde ne court aucun danger pratique. Les générateurs tiennent aussi un compteur à l'intérieur de la milliseconde, comme celui-ci, pour que des identifiants créés en rafale restent strictement ordonnés.

Gardez quand même toujours une contrainte d'unicité sur la colonne. Elle ne coûte rien et transforme un événement impossible en erreur claire plutôt qu'en données corrompues.

UUID ou GUID, et les autres versions

GUID (globally unique identifier) est le nom que Microsoft donne à l'UUID. C'est la même valeur de 128 bits ; les outils Windows l'écrivent généralement en majuscules et parfois entre accolades, comme {3F2504E0-4F89-41D3-9A0C-0305E82C3301}. Les options de format du générateur (Majuscules, Tirets, Accolades { }) couvrent ces styles.

La version 1 combine un horodatage et l'adresse de la carte réseau ; on la recommande rarement aujourd'hui, car elle peut identifier la machine. La version 6 est la version 1 réordonnée pour se trier par date. Les versions 3 et 5 sont dérivées d'un nom avec MD5 ou SHA-1 : une même entrée donne toujours le même UUID. La version 8 est libre pour des structures personnalisées. ULID est un format populaire qui n'est pas un UUID mais repose sur la même idée que le v7 ; le v7, lui, entre dans n'importe quelle colonne uuid existante.

Quand le v7 n'est pas le bon choix

• Identifiants publics dont la date de création est sensible : un v7 dans une URL révèle quand un compte, une commande ou un document a été créé.
• Jetons, liens d'invitation et codes de réinitialisation de mot de passe : utilisez un v4 ou un jeton aléatoire plus long, jamais quelque chose qu'on pourrait deviner à partir de l'heure.
• Systèmes qui trient ou comparent les identifiants comme du texte ou avec un autre ordre d'octets, comme uniqueidentifier dans SQL Server.
• Tables existantes remplies de clés v4 : mélanger les versions fonctionne, mais vous ne gagnez l'avantage sur l'index que pour les nouvelles lignes.