UUID v4 vs UUID v7 vs ULID vs NanoID : Quel identifiant choisir ?

Choisir le bon format d'identifiant unique pour votre application est une décision qui affecte les performances de la base de données, la scalabilité et l'expérience développeur. Avec UUID v7 désormais un standard officiel (RFC 9562, publié en 2024), le paysage de la génération d'identifiants a considérablement changé. Ce guide compare les quatre options les plus populaires.

Tableau comparatif rapide

UUID v4 : Le standard établi

UUID v4 est le choix par défaut depuis plus d'une décennie. Il génère des identifiants de 128 bits utilisant 122 bits d'aléatoire, produisant le format familier xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx.

Points forts :

• Support universel des bibliothèques dans tous les langages de programmation
• Aucune coordination nécessaire — générez n'importe où, n'importe quand
• Simple et bien compris

Points faibles :

• La distribution aléatoire provoque une fragmentation de l'index B-tree dans les bases de données
• Aucune information temporelle — impossible de trier par ordre de création
• À grande échelle (millions de lignes), les performances d'insertion se dégradent significativement

// JavaScript
crypto.randomUUID();
// → "f47ac10b-58cc-4372-a567-0e02b2c3d479"

Essayez notre outil Générateur UUID →

UUID v7 : Le nouveau standard (RFC 9562)

UUID v7, finalisé dans la RFC 9562 (2024), est conçu spécifiquement pour être utilisé comme clés de base de données. Il combine un horodatage Unix de 48 bits (précision à la milliseconde) avec 74 bits d'aléatoire, produisant des UUID ordonnés par temps, entièrement compatibles avec l'infrastructure UUID existante.

Points forts :

• Ordonné par temps — trie naturellement par date de création
• Excellentes performances d'insertion en base de données (pas de fragmentation d'index)
• Compatible avec toutes les colonnes et outils UUID existants
• Support natif dans PostgreSQL 17+

Points faibles :

• Moins de bits aléatoires (74 vs 122) — toujours astronomiquement résistant aux collisions
• L'horodatage est intégré — révèle l'heure approximative de création
• Le support des bibliothèques est encore en croissance (mais rapide)

// Node.js (uuid library v9+)
import { v7 as uuidv7 } from 'uuid';
uuidv7();
// → "018e4f5c-6a7b-7000-8000-1234abcd5678"
//    ^^^^^^^^^^^^^^^^ timestamp portion

ULID : Triable lexicographiquement

ULID (Universally Unique Lexicographically Sortable Identifier) est antérieur à UUID v7 et partage une conception similaire : horodatage de 48 bits + 80 bits d'aléatoire. La différence clé est son encodage : Crockford Base32, produisant des chaînes compactes de 26 caractères comme 01ARZ3NDEKTSV4RRFFQ69G5FAV.

Points forts :

• Représentation compacte en chaîne (26 caractères vs 36 pour UUID)
• Monotonie intégrée — les ID générés dans la même milliseconde restent ordonnés
• Triable lexicographiquement en tant que chaîne (pas de comparaison spéciale nécessaire)
• Insensible à la casse et compatible URL

Points faibles :

• Pas un standard RFC — spécification communautaire uniquement
• Non compatible avec les colonnes UUID sans conversion
• Moins de support de bibliothèques que UUID

// JavaScript
import { ulid } from 'ulid';
ulid();
// → "01ARZ3NDEKTSV4RRFFQ69G5FAV"

NanoID : Compact et personnalisable

NanoID adopte une approche différente : au lieu d'un format fixe, il génère des chaînes aléatoires compactes et compatibles URL avec un alphabet et une longueur configurables. La valeur par défaut est de 21 caractères utilisant A-Za-z0-9_-.

Points forts :

• Très compact (21 caractères par défaut, personnalisable)
• Compatible URL par défaut
• Alphabet et longueur personnalisables
• Bibliothèque minuscule (~130 octets gzippés) — parfait pour le frontend
• Cryptographiquement robuste (utilise crypto.getRandomValues)

Points faibles :

• Pas d'ordonnancement temporel — mêmes problèmes de fragmentation B-tree que UUID v4
• Aucune spécification standard
• Non compatible avec l'infrastructure UUID

// JavaScript
import { nanoid } from 'nanoid';
nanoid();
// → "V1StGXR8_Z5jdHi6B-myT"

Guide de décision : Lequel choisir ?

Utilisez UUID v7 quand :

• Vous construisez une nouvelle application avec une base de données relationnelle
• Vous avez besoin d'identifiants ordonnés par temps pour un indexage efficace
• Votre système attend le format UUID standard (PostgreSQL, MySQL, etc.)
• Vous voulez le meilleur équilibre entre compatibilité et performance

Utilisez UUID v4 quand :

• Vous travaillez avec des systèmes qui ne supportent que UUID v4
• Vous avez besoin d'un maximum d'aléatoire sans fuite d'horodatage
• L'échelle de la base de données est petite à moyenne (< 1M lignes)

Utilisez ULID quand :

• Vous avez besoin de représentations de chaînes plus courtes
• Vous travaillez avec des systèmes qui trient les chaînes lexicographiquement
• La monotonie dans la même milliseconde est importante
• Vous n'avez pas besoin de compatibilité avec les colonnes UUID

Utilisez NanoID quand :

• Vous générez des identifiants dans le navigateur ou le frontend
• La taille du bundle compte (NanoID fait 130 octets)
• Vous avez besoin d'identifiants courts et compatibles URL
• Vous construisez des raccourcisseurs d'URL, des codes d'invitation ou des jetons de session

Benchmark de performance : Insertions en base de données

La différence la plus significative entre ces formats est la performance d'insertion en base de données. Les identifiants ordonnés par temps (UUID v7, ULID) maintiennent des insertions B-tree séquentielles, tandis que les identifiants aléatoires (UUID v4, NanoID) provoquent des divisions de pages aléatoires :

Les données de benchmark sont approximatives et varient selon le matériel, la version de la base de données et la structure des tables. La différence relative est cohérente dans tous les environnements.

Chemin de migration : UUID v4 vers UUID v7

Si vous envisagez de migrer de UUID v4 vers UUID v7, la bonne nouvelle est qu'ils partagent le même format 128 bits et la même représentation en chaîne. Dans la plupart des bases de données, vous pouvez commencer à générer des valeurs UUID v7 pour les nouvelles lignes tandis que les valeurs UUID v4 existantes restent valides :

-- PostgreSQL 17+
CREATE TABLE users (
  id UUID DEFAULT gen_random_uuid_v7() PRIMARY KEY,
  name TEXT NOT NULL
);

-- Older PostgreSQL with uuid-ossp or pgcrypto
-- Use application-level UUID v7 generation