UUID vs NanoID

Anatomie : ce que contient chaque identifiant

Les UUID encodent leurs propres métadonnées. Les bits 48–51 portent la version — 1 pour temps plus MAC, 4 pour aléatoire, 7 pour aléatoire ordonné dans le temps — et deux bits de plus fixent la variante. Un v4 a toujours l’air aléatoire ; un v7 commence par un horodatage lisible, car ses 48 premiers bits sont des millisecondes depuis l’époque Unix et les UUID frappés le même jour partagent un préfixe.

Les NanoID ne portent aucune métadonnée. Chaque caractère est un tirage indépendant dans l’alphabet, choisi par masquage et échantillonnage par rejet au-dessus de crypto.getRandomValues, si bien que chaque symbole reste uniformément probable. Cette pureté explique pourquoi le format se plie à tout — changez l’alphabet ou la longueur, gardez l’algorithme — et pourquoi un NanoID ne révèle rien sur le moment où il a été créé.

Maths des collisions : pourquoi aucun des deux ne collisionne jamais

La borne d’anniversaire dit qu’un identifiant aléatoire de n bits atteint une probabilité de collision de 50 % autour de 2^(n/2) tirages. Pour l’UUID v4, c’est environ 2^61 — à peu près 2.3 milliards de milliards d’identifiants — avant même que la probabilité d’un seul doublon n’atteigne une chance sur deux ; les 126 bits de NanoID repoussent la barre un peu plus loin. En pratique, les deux sont des systèmes où cela n’arrive jamais — tout doublon que vous rencontrez est un bug de code, pas un événement d’entropie.

Cette équivalence explique pourquoi le débat sur la taille compte moins qu’on ne le croit : 21 caractères NanoID ne sont pas plus sûrs qu’un UUID v4 — la même garantie en moins d’octets. Les raisons honnêtes de choisir relèvent de l’adéquation opérationnelle — stockage, URL, outillage — pas du risque de collision.

Bases de données : le problème de localité d’index

Insérez une clé aléatoire dans un index B-tree et la ligne peut atterrir sur n’importe quelle page ; remplissez les pages à moitié dans un ordre aléatoire et chaque insertion risque une scission de page, des écritures supplémentaires et un cache plus froid. C’est la taxe de fragmentation que paient aussi bien l’UUID v4 que NanoID — NanoID inclus, car il est tout aussi aléatoire. Sur une clé primaire indexée à forte charge d’écriture, ni l’un ni l’autre n’est adapté aux index par défaut.

L’UUID v7 est le remède livré dans la norme elle-même : ses 48 bits de tête sont un horodatage en millisecondes, si bien que les nouvelles clés se trient presque toujours vers le bord droit de l’index. NanoID ne peut pas l’offrir : aucune composante temporelle, rien à trier. Dans une colonne indexée, le vrai choix est v7 contre tout le reste.

• v4 et NanoID dispersent les insertions dans l’arbre — scissions de pages et échecs de cache à grande échelle.
• Le type uuid de Postgres stocke 16 octets bruts ; une clé texte de 36 caractères en stocke 37 ou plus.
• L’avantage texte de NanoID — 21 caractères contre 36 — ne tient que tant que l’alphabet reste documenté.

URL, alphabets et curseur de longueur

L’alphabet de NanoID est compatible URL par construction : A-Za-z0-9_- n’exige aucun encodage pourcentage nulle part dans une URL, donc un identifiant peut être un segment de chemin, une valeur de requête ou un slug sans aucun échappement. Les UUID sont techniquement compatibles URL aussi — chiffres hexadécimaux et tirets ne demandent jamais d’encodage — mais 36 caractères font une chaîne visible bien longue pour un lien.

L’alphabet personnalisé est la caractéristique la plus pratique de NanoID : codes numériques uniquement, liens courts en minuscules — échangez les 64 symboles, gardez l’algorithme. Respectez la règle selon laquelle l’entropie vaut la longueur multipliée par le log2 de la taille de l’alphabet : un NanoID en minuscules de 8 caractères vaut environ 38 bits, acceptable pour un code d’une heure, imprudent comme clé primaire. Les UUID n’offrent pas ce curseur ; le format est fixé à 128 bits.

Quand choisir l’un ou l’autre

Choisissez les UUID quand l’identifiant vit dans l’infrastructure : clés primaires de base de données (v7), échanges entre équipes et fournisseurs, tout ce qu’un tiers doit valider, partout où une primitive intégrée bat une dépendance. La norme est le produit — chaque langage, ORM et base de données la parle déjà.

Choisissez NanoID quand l’identifiant est visible des utilisateurs : URL courtes, liens d’invitation, noms de fichiers, valeurs de cookies, identifiants de requête dans les logs. La recommandation s’inverse proprement — si vous vous battez sans fin contre la largeur d’un UUID dans une URL, ce lien veut du NanoID ; si vous vous surprenez à réimplémenter NanoID dans un backend dont la base de données pourrait servir des clés nativement, cette colonne veut un UUID v7.