Générez des UUID v4 ou v7 localement avec le générateur UUID — sans envoi, sans compte.
Pourquoi les identifiants triables comptent
Les clés primaires aléatoires dispersent les insertions dans les index B-tree et LSM, provoquant des scissions de pages et une amplification d'écriture. Un identifiant ordonné dans le temps garde les nouvelles valeurs denses et les insertions rapides.
UUID v7 et ULID résolvent cela de la même façon : ils intègrent un horodatage Unix de 48 bits en millisecondes au début de la valeur.
UUID v7
UUID v7 est défini par RFC 9562. Il utilise le format canonique avec traits d'union 8-4-4-4-12, un nibble de version, un champ de variante et environ 74 bits aléatoires.
Sa force est l'adéquation à l'écosystème : tout système qui analyse des UUID aujourd'hui comprend v7, et les bases de données ajoutent de plus en plus un support natif UUIDv7.
RFC 9562 définit la disposition : les 48 premiers bits contiennent l'horodatage Unix en millisecondes, puis viennent le nibble de version (7), le champ de variante et les bits aléatoires restants. Comme l'horodatage est en tête, la comparaison octet par octet correspond à l'ordre de création.
La spécification autorise aussi un compteur monotone qui remplace une partie des bits aléatoires quand plusieurs valeurs naissent dans la même milliseconde.
ULID
ULID (Universally Unique Lexicographically Sortable Identifier) encode le même horodatage de 48 bits plus 80 bits aléatoires dans une chaîne Crockford Base32 de 26 caractères, généralement en majuscules.
Ce n'est ni une RFC ni une norme UUID, mais c'est populaire dans les écosystèmes JavaScript et Go, et il se trie lexicographiquement dans le même ordre que l'heure de création.
Crockford Base32 omet les lettres I, L, O et U pour éviter toute confusion avec les chiffres 0 et 1 ; c'est pourquoi 128 bits tiennent en 26 caractères au lieu des 36 d'un UUID.
Côte à côte
Ils divergent sur l'emballage. Un UUID avec traits d'union fait 36 caractères et est insensible à la casse ; une ULID fait 26 caractères, en majuscules par convention, et se trie comme une simple chaîne. L'horodatage intégré est la même valeur de 48 bits en millisecondes, et l'heure de création se laisse extraire – par exemple avec le convertisseur d'horodatage Unix.
| Propriété | UUID v7 | ULID |
|---|---|---|
| Norme | RFC 9562 | Spécification communautaire |
| Format | 8-4-4-4-12, avec traits d'union | Crockford Base32, 26 caractères |
| Bits aléatoires | ~74 | 80 |
| Sensibilité à la casse | Insensible à la casse | Majuscules par convention |
| Écosystème | Analyseurs UUID partout | Croissant, propre à la pile |
Ce qui décide
- Utilisez UUID v7 quand votre base de données ou vos outils comprennent déjà les UUID
- Utilisez ULID quand votre pile l'utilise déjà ou que vous voulez des clés chaîne compactes
- Pour les identifiants publics impossibles à deviner, continuez d'utiliser UUID v4
- Ne stockez pas les UUID comme chaînes dans MySQL si vous pouvez utiliser BINARY(16)
- Pour des clés compactes dans les URL, la chaîne ULID de 26 caractères est plus courte qu'un UUID avec traits d'union
- Traitez les deux comme opaques : un identifiant triable n'est pas un secret, gardez v4 pour les jetons
FAQ
Q.ULID et UUID v7 sont-ils compatibles ?
A.Non, ils utilisent des encodages différents, donc une chaîne ULID n'est pas un UUID valide et inversement. Un UUID est 16 octets en 36 caractères hexadécimaux ; une ULID est une chaîne Crockford Base32 de 26 caractères. Ils résolvent le même problème – des identifiants ordonnés dans le temps et résistants aux collisions –, mais les formats ne sont pas interchangeables.
Q.ULID est-il plus triable qu'UUID v7 ?
A.Les deux se trient par le même préfixe d'horodatage de 48 bits, donc le comportement d'ordre est équivalent. Le tri lexicographique fonctionne directement sur les chaînes ULID ; UUID v7 se trie en octets ou en chaîne canonique.
Q.Dois-je migrer de ULID vers UUID v7 ?
A.Seulement si le coût de migration est faible et que votre écosystème tire parti de l'analyse RFC 9562. Le changement touche les valeurs stockées, les index et tout le code qui analyse ou affiche des identifiants. Les deux formats sont des choix valides ; la cohérence au sein de votre système compte plus que le format.
- Un compromis pragmatique : gardez ULID là où il existe déjà, utilisez UUID v7 pour les nouvelles tables.
Références
- RFC 9562 – Universally Unique IDentifiers (UUIDs) : https://www.rfc-editor.org/rfc/rfc9562
- Spécification ULID : https://github.com/ulid/spec
- Implémentation de référence ULID en JavaScript : https://github.com/ulid/javascript
- Paquet uuid (prise en charge de v7) : https://github.com/uuidjs/uuid
Générez des UUID localement
v4 ou v7, un par un ou par lots, dans votre navigateur.
Choisissez selon l'écosystème
Si votre base de données ou ORM gère déjà les UUID, v7 s'intègre avec le moins de friction. Si votre pile est construite autour d'ULID, changer de format apporte peu.
Aucun des deux n'est un secret : gardez UUID v4 pour les jetons et identifiants impossibles à deviner, et générez l'un ou l'autre localement avec le générateur UUID.
Ma règle de base : choisissez le format que votre base de données et votre ORM parlent déjà, puis restez-y. Un changement de format plus tard signifie migrer les données et reconstruire les index.