UUID v4 contre UUID v7 contre ULID: quel identifiant unique devriez-vous utiliser?

Les entiers automatiques étaient la clé primaire par défaut pendant des décennies. Ils sont compacts et rapides, mais ils nécessitent une base de données centrale pour distribuer des numéros, divulguer le nombre d'enregistrements que vous avez, et rendre la fusion des données de plusieurs systèmes douloureuse. Les identifiants uniques à l'échelle mondiale résolvent ces problèmes: tout serveur, application mobile ou client hors ligne peut créer un identifiant qui ne sera jamais en conflit. La question est de savoir de quelle sorte. Ce guide compare les trois options les plus populaires en 2026: UUID version 4, UUID version 7 et ULID.

Un rappel rapide sur les UUID

Un UUID (Universally Unique Identifier) est une valeur de 128 bits, généralement écrite sous forme de 32 chiffres hexadécimaux en cinq groupes:

550e8400-e29b-41d4-a716-446655440000

La norme actuelle, la RFC 9562 (publiée en 2024, remplaçant la RFC 4122), définit plusieurs versions. Quelques bits encodent la version et la variante; le reste dépend de la version. Le troisième groupe commence toujours par le numéro de version, donc vous pouvez distinguer un v4 d'un v7 en un coup d'œil.

UUID v4: purement aléatoire

Un UUID de version 4 contient 122 bits aléatoires plus 6 bits fixes pour la version et la variante.

Les points forts

• Triviale à générer: chaque langage et base de données a une fonction intégrée, comme crypto.randomUUID() dans JavaScript ou gen_random_uuid() dans PostgreSQL.
• Rien ne révèle: pas d'horodatage, pas d'identifiant de machine, pas de séquence.
• La probabilité de collision est négligeable. Vous auriez besoin de générer environ 2,7 × 10^18 ID pour une chance de 50% d'un seul double.

Les faiblesses

• L'ordre aléatoire nuit aux index de base de données. Les index d'arbres B, utilisés par PostgreSQL, MySQL et SQL Server, fonctionnent mieux lorsque de nouvelles clés arrivent dans un ordre croissant. Les touches aléatoires atterrissent partout dans l'index, provoquant des divisions de page, une mauvaise localisation du cache et une amplification d'écriture. Sur les grands tableaux, le débit d'insertion peut diminuer considérablement et les indices augmenter plus que nécessaire.
• Pas triable par temps de création, donc vous avez besoin d'une colonne created_at séparée pour les requêtes chronologiques.

UUID v7: dans l'ordre temporel

La version 7 place un horodatage Unix de 48 bits en millisecondes à l'avant, suivi de 74 bits de hasard (certaines implémentations utilisent une partie de celui-ci comme compteur pour ordonner dans la même milliseconde).

01928c3e-5b7a-7c4d-9f3e-2a1b4c5d6e7f
└─timestamp─┘ └version 7

Les points forts

• Les nouveaux identifiants augmentent à peu près, donc les inserts s'ajoutent à la fin de l'index comme des touches d'augmentation automatique. Cela maintient les index compacts et écrit rapidement.
• Tri par types d'ID par temps de création, ce qui rend la pagination basée sur le curseur simple: WHERE id > :last_id ORDER BY id LIMIT 50.
• Il s'agit toujours d'un UUID standard: il s'adapte aux colonnes natives uuid, aux ORM et aux API qui acceptent déjà les UUID.
• Vous pouvez extraire le temps de création de l'ID pour le débogage.

Les faiblesses

• Le temps de création est visible par tous ceux qui voient l'ID. Pour la plupart des enregistrements, ce n'est pas dangereux; pour certains, comme les comptes d'utilisateurs dans un produit sensible à la vie privée, il peut révéler quand quelqu'un s'est inscrit.
• Il faut une horloge assez précise. De grands sauts d'horloge vers l'arrière peuvent produire des identifiants qui trient plus tôt que ceux existants; de bonnes bibliothèques gèrent cela avec des compteurs monotones.
• Les fonctions de génération native sont plus récentes. PostgreSQL 18 a ajouté uuidv7(); sur les anciennes versions, générer dans le code d'application.

ULID: texte triable et compact

ULID (Universally Unique Lexicographically Sortable Identifier) est antérieur à UUID v7 et utilise la même idée: un horodatage de 48 bits de millisecondes suivi de 80 bits aléatoires. La différence réside dans la forme du texte: 26 caractères de Crockford Base32.

01J9Z3K8M2Q7X4V5B6N8P0R2T4

Les points forts

• Plus courte que la chaîne UUID de 36 caractères et URL-safe.
• Il n'est pas sensible aux majuscules et exclut les lettres ambiguës (I, L, O, U), il est donc plus facile de lire à haute voix ou d'écrire.
• Le tri des chaînes lexicographiques équivaut au tri chronologique, ce qui aide dans les systèmes qui stockent les identifiants sous forme de texte, tels que les magasins de valeurs clés ou les noms de fichiers journaux.

Les faiblesses

• Ce n'est pas un UUID, donc il ne s'adapte pas aux types de colonnes UUID natifs sans conversion (bien que ses 128 bits puissent être stockés dans un seul).
• Une spécification communautaire plutôt qu'une norme IETF, avec un comportement légèrement différent entre les bibliothèques.
• Comme V7, il expose le temps de création.

Comparaison parallèle

Immobilier	UUID v4	UUID v7	Le numéro ULID
Taille	128 bits	128 bits	128 bits
Longueur du texte	36	36	26
Par ordre temporel	Je ne veux pas .	- Je sais .	- Je sais .
Les fuites de temps de création	Je ne veux pas .	Oui (ms)	Oui (ms)
La norme	RFC 9562	RFC 9562	Spécifications communautaires
Type DB natif	uuid	uuid	Généralement texte ou binaire
Insérateurs adaptés à l'index	Les pauvres.	C' est bon !	C' est bon !

Conseils de stockage

Quoi que vous choisissiez, stockez les identifiants en 16 octets, pas en texte. Une chaîne de caractères de 36 caractères prend plus du double de l'espace, et chaque index et clé étrangère lui faisant référence multiplie le coût. PostgreSQL a un type natif uuid; les utilisateurs de MySQL peuvent utiliser BINARY(16) avec UUID_TO_BIN(uuid, 1), où le deuxième argument réordonne v1 timestamps pour v7 utilise l'ordre par défaut, car il est déjà ordonné par temps.

Exposer les identifiants dans les API sous forme de texte canonique. Les clients devraient les traiter comme des chaînes opaques et ne jamais les interpréter.

Considérations en matière de sécurité

Aucune de ces cartes n'est un secret. Ne les utilisez pas comme jetons de réinitialisation de mot de passe ou identifiants de session simplement parce qu'ils sont difficiles à deviner. Un UUID v4 a suffisamment de hasard pour ne pas être éprouvable, mais v7 et ULID ont des préfixes d'horodatage prévisibles qui réduisent l'entropie efficace. Pour les secrets, générez au moins 128 bits aléatoires avec un générateur cryptographique et traitez-les comme des mots de passe, en stockant idéalement seulement un hachage voir MD5 vs SHA-256 pour lequel utiliser le hachage.

Considérez également l'énumération. Les entiers séquentiels permettent à n'importe qui de deviner /orders/1001, /orders/1002. Les identifiants aléatoires ou chronologiques rendent cela peu pratique, mais ils ne remplacent pas les contrôles d'autorisation sur chaque demande.

Lequel choisir ?

• Clé primaire de base de données dans un nouveau système: UUID v7. Vous obtenez une génération distribuée et de bonnes performances d'index avec une compatibilité totale UUID.
• Identifiants publics pour lesquels le temps de création doit rester privé: UUID v4, ou une clé interne v7 combinée à un identifiant public aléatoire distinct.
• Les magasins basés sur du texte, les noms de fichiers ou les identifiants que les utilisateurs peuvent taper: ULID, pour sa forme plus courte et insensible aux majuscules.
• ** Système existant sur v4 avec des problèmes de performance:** considérez v7 pour les nouveaux tableaux; mélanger des versions dans une colonne est techniquement acceptable car les deux sont des UUID valides.

Génération d'identifiants

Pour les tâches rapides données de départ, appareils de test, insertions manuelles un générateur d'UUID basé sur un navigateur peut produire jusqu'à 1 000 valeurs v4, v7 ou ULID à la fois en utilisant crypto.getRandomValues. Dans le code d'application, utilisez la bibliothèque standard de votre langue ou un package bien entretenu et générez des identifiants aussi proches que possible de la création d'enregistrements.

Résumé

UUID v4 est aléatoire et privé mais disperse les index de base de données. UUID v7 ajoute un préfixe timestamp qui maintient les insertions rapides et les identifiants triables tout en restant un UUID standard. ULID propose le même ordre avec un format de texte plus court et plus convivial. Pour la plupart des nouvelles applications, UUID v7 est le meilleur par défaut; atteindre v4 lorsque le timing doit rester caché et ULID lorsque les humains ou les systèmes basés sur du texte gèrent les identifiants.