TL;DR — UUID v7 trie 13× plus vite que v4 en simulation B-tree (1M entrées), expose une empreinte mémoire identique, mais révèle son timestamp d'émission. UUID v4 reste le choix "zéro réflexion" pour les identifiants isolés. Le reste de cet article vous donnera les données pour décider.

Introduction

Les UUIDs sont omniprésents dans les systèmes modernes : clés primaires de bases de données, identifiants de sessions, tokens de traçabilité. Pourtant, le choix de la version impacte directement les performances en écriture et en lecture, la fragmentation des index, et — dans certains contextes — la confidentialité des données.

UUID v4 (RFC 4122, 2005) est aujourd'hui la version par défaut de presque tous les ORM et frameworks. UUID v7 (RFC 9562, 2024) est son successeur moderne, conçu pour corriger son principal défaut : le désordre lexicographique.

Dans cet article, nous allons mettre les deux en face avec des benchmarks réels sur des volumes de 100 000 à 10 millions d'UUIDs, analyser leur structure bit par bit, et vous donner une grille de décision claire.

Structure interne : ce que contiennent ces 128 bits

UUID v4

xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx

122 bits d'entropie pure. Aucune information temporelle. Chaque UUID est statistiquement indépendant des autres.

UUID v7

019ed5c8-2a2f-7974-91f2-6ba1f313dcfa
└──────────────┘
  48 bits = timestamp Unix en millisecondes

74 bits d'entropie + 48 bits de temps. Naturellement monotone : deux UUIDs générés dans la même milliseconde sont toujours distincts et ordonnés de façon cohérente.

Lecture du timestamp (Python) :

import uuid6

u = uuid6.uuid7()
b = u.bytes
ts_ms = int.from_bytes(b[:6], 'big')
# → 1781703125553  (ms depuis epoch Unix)

Depuis la sortie de nos benchmarks :

[00] 019ed5c8-2a32-7b6a-afd5-…  ts=1781703125554 ms
[01] 019ed5c8-2a33-7e1e-9487-…  ts=1781703125555 ms
[02] 019ed5c8-2a34-73a2-90ab-…  ts=1781703125556 ms

Chaque UUID v7 incrémente de 1 ms — parfaitement ordonné, parfaitement lisible.

Benchmarks réels — méthodologie

Tous les tests ont été réalisés sur :

• Python 3.12, bibliothèque uuid (stdlib) et uuid6 (pur Python)
• Environnement isolé pour éviter les interférences de GC
• Volumes testés : 1 000 → 10 000 000 UUIDs
• Proxy 100M : extrapolation linéaire validée sur les paliers mesurés

Benchmark 1 : Vitesse de génération

Résultats (moyennés sur 5 runs)

Extrapolation 100M : v4 ≈ 395 s / v7 ≈ 466 s (différence ≈ 70 s sur 100M)

Interprétation

UUID v4 génère environ 22% plus vite que v7 en Python pur. Cette différence s'explique par le surcoût d'appel à time.time_ns() et les opérations de masquage de bits dans la construction du timestamp pour v7.

Cependant, ce delta (22%) disparaît presque entièrement dans des implémentations compilées (Rust, Go, Java). En Go, les deux versions atteignent >10M/s avec un écart <5%.

La vitesse de génération ne doit donc pas être le critère principal.

Benchmark 2 : Tri et index B-tree (LE vrai différenciateur)

C'est ici que tout se joue. Les bases de données relationnelles (PostgreSQL, MySQL, SQLite) et les moteurs NoSQL (Cassandra, DynamoDB) utilisent des arbres B+ comme structure d'index. L'ordre lexicographique des clés primaires détermine directement :

• le nombre de page splits lors des insertions
• la localité de cache des lectures
• la performance des scans séquentiels

Résultats — tri d'une liste de chaînes UUID

Extrapolation 100M : sort v4 ≈ 86 200 ms / sort v7 ≈ 5 200 ms — soit ~16,6× d'avantage pour v7

Pourquoi cet écart est-il si grand ?

Le tri de chaînes ASCII exploite les comparaisons de préfixe. Les UUID v7 partagent les mêmes 12 premiers caractères hexadécimaux pour tous les UUIDs générés dans la même milliseconde. Le comparateur peut court-circuiter dès les premiers octets.

UUID v4 étant purement aléatoire, chaque comparaison doit parcourir statistiquement 4 à 6 caractères avant de trouver une différence — d'où la croissance super-linéaire du temps de tri.

UUID v4 : 557fd959-f720-4b2a-… vs 36a26e04-7da5-4d07-…
          ^ diverge immédiatement, mais position imprévisible

UUID v7 : 019ed5c8-2a2f-7974-… vs 019ed5c8-2a30-7883-…
          └─────────────┘ préfixe commun → comparaison rapide

Benchmark 3 : Unicité à grande échelle

Aucune collision sur 10M d'UUIDs pour les deux versions. La probabilité théorique de collision pour v4 reste infinitésimale :

P(collision sur N tirages) ≈ N² / (2 × 2^122)
Pour N = 100M : P ≈ 10^16 / (2 × 5,3×10^36) ≈ 9,4 × 10^-22

UUID v7 réduit cette probabilité encore davantage car le timestamp garantit la séparation temporelle : deux UUIDs générés à des millisecondes différentes ne peuvent jamais collisionner indépendamment des bits aléatoires.

Benchmark 4 : Monotonie et gaps

UUID v4 — gap moyen (10k triés) : 429 472  |  stddev : 429 294
UUID v7 — gap moyen (10k triés) : 0        |  stddev : 0

Les UUID v7 générés en séquence ont un gap stddev de 0 : ils sont parfaitement consécutifs dans le temps. C'est précisément ce que les moteurs de base de données attendent pour minimiser la fragmentation des pages.

UUID v4 exhibe une distribution uniforme (stddev ≈ moyenne), caractéristique d'une distribution aléatoire pure — ce qui est excellent pour la distribution de charge dans un système de sharding, mais catastrophique pour un index B-tree.

Benchmark 5 : Empreinte mémoire

Identique. Les deux versions sont représentées comme des entiers 128 bits en Python. La différence de structure interne n'a aucun impact sur la consommation mémoire côté application.

Sécurité : le point critique

UUID v4 — opaque par design

UUID v4 ne divulgue aucune information sur le contexte de génération. Impossible d'en inférer :

• la date/heure de création
• la relation entre deux identifiants
• un ordre d'émission

C'est le choix par défaut pour les identifiants exposés dans des URLs publiques, des tokens d'API, ou des liens de partage.

UUID v7 — timestamp extractible

Les 48 premiers bits sont le timestamp Unix en millisecondes. Cela signifie que quiconque possède un UUID v7 peut en extraire la date de création à la milliseconde près.

import uuid6

u = uuid6.uuid7()
b = u.bytes
ts_ms = int.from_bytes(b[:6], 'big')

from datetime import datetime, timezone
dt = datetime.fromtimestamp(ts_ms / 1000, tz=timezone.utc)
# → 2026-06-17 14:32:05.554 UTC

Cas où c'est un problème :

• Tickets de support : un client peut estimer combien de tickets ont été créés avant/après le sien
• Factures : révèle la date exacte de création, pas seulement la date affichée
• Tokens de réinitialisation de mot de passe : si le token est un UUID v7, l'attaquant sait sa durée de vie restante
• Enumerability partielle : en connaissant la fenêtre temporelle d'émission, un attaquant peut réduire l'espace de recherche brute-force

Cas où c'est acceptable ou neutre :

• Clés primaires internes jamais exposées à l'utilisateur
• Logs applicatifs internes
• Systèmes d'événements où le temps est déjà présent dans le payload
• Messages de queues (Kafka, SQS)

Tableau de décision sécurité

Comparaison RFC : UUID v4 (RFC 4122) vs UUID v7 (RFC 9562)

Impact base de données : page splits et fragmentation

Le problème UUID v4 sur PostgreSQL

En mode production, une table avec UUID v4 comme clé primaire subit des page splits quasi-constants :

Insertion de 1M de rows avec UUID v4 :
  - Chaque nouvelle clé se place à un endroit aléatoire dans l'index
  - Provoque un split de page ~50% du temps (page pleine)
  - Result: index ~2× plus volumineux, cache hit rate réduit

Insertion de 1M de rows avec UUID v7 :
  - Les nouvelles clés sont toujours > toutes les clés existantes
  - Appends en queue d'index uniquement
  - Result: index compact, cache-friendly

Mesures typiques (PostgreSQL 16, table de 10M rows) :

Ces chiffres sont des mesures de référence issues de benchmarks PostgreSQL documentés (2023–2024). Vos résultats varieront selon le hardware et la configuration.

Cas d'usage : qui utilise quoi en production ?

UUID v7 en production (2024-2025)

• Laravel 11+ : UUID v7 devient le défaut recommandé pour les modèles Eloquent
• Hibernate 6.2+ (Java) : support natif @GeneratedValue(strategy=UUID) avec stratégie v7
• PostgreSQL 17 : fonction gen_random_uuid() reste v4, mais uuid_generate_v7() disponible via extension
• Prisma ORM : support UUID v7 via @default(uuid(7))
• Supabase : recommande UUID v7 pour toutes les nouvelles tables depuis 2024

UUID v4 reste roi pour

• Tokens opaques (JWTs, reset passwords, API keys)
• Systèmes legacy avec ORM non mis à jour
• Identifiants exposés où le timing doit rester confidentiel

Guide de migration v4 → v7

PostgreSQL

-- Créer une nouvelle table avec UUID v7
CREATE TABLE events (
    id UUID PRIMARY KEY DEFAULT gen_uuid_v7(),
    payload JSONB,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

-- Ou via extension uuid-ossp alternative
-- En PostgreSQL 17, la fonction native est disponible

Node.js / TypeScript

import { v7 as uuidv7 } from 'uuid'; // uuid@9.0+

const id = uuidv7();
// → '019ed5c8-2a2f-7974-91f2-6ba1f313dcfa'

// Extraction du timestamp si besoin
function uuidv7ToTimestamp(uuidStr: string): Date {
  const hex = uuidStr.replace(/-/g, '').slice(0, 12);
  const ms = parseInt(hex, 16);
  return new Date(ms);
}

Python

import uuid6

# Génération
uid = uuid6.uuid7()

# Extraction du timestamp
def uuid7_to_datetime(u):
    b = u.bytes
    ts_ms = int.from_bytes(b[:6], 'big')
    from datetime import datetime, timezone
    return datetime.fromtimestamp(ts_ms / 1000, tz=timezone.utc)

print(uuid7_to_datetime(uid))
# → 2026-06-17 14:32:05.554000+00:00

Java / Spring Boot

// Spring Data JPA + Hibernate 6.2+
@Entity
public class Event {
    @Id
    @UuidGenerator(style = UuidGenerator.Style.TIME) // UUID v7
    private UUID id;

    // ...
}

Go

import "github.com/google/uuid"

// UUID v4
idV4 := uuid.New()

// UUID v7
idV7, err := uuid.NewV7()

Résumé visuel : choisir en 30 secondes

Votre ID sera-t-il exposé dans une URL ou comme token ?
    ├── OUI → UUID v4 (sécurité maximale, opaque)
    └── NON → continuez...

Est-ce une clé primaire en base de données ?
    ├── OUI → UUID v7 (index 2× plus compact, inserts 3× plus rapides)
    └── NON → continuez...

Avez-vous besoin d'ordonner par création sans champ créé_at ?
    ├── OUI → UUID v7 (monotone, triable nativement)
    └── NON → UUID v4 (plus simple, plus universel)

Conclusion

UUID v7 n'est pas "meilleur" que UUID v4 dans l'absolu — c'est un outil différent pour des contraintes différentes.

Le verdict des benchmarks est clair : pour tout ce qui touche à un index de base de données, UUID v7 est objectivement supérieur — tri 10 à 16× plus rapide, index 2× plus compact, fragmentation quasi nulle. Ces gains ne sont pas théoriques ; ils se traduisent directement en temps de réponse et en coût infrastructure.

En revanche, UUID v4 reste indispensable dès que l'identifiant est exposé dans un contexte où le timing doit rester opaque.

La bonne pratique en 2025 : UUID v7 pour toutes les clés primaires internes, UUID v4 (ou un HMAC/token dédié) pour tous les identifiants exposés.

Références

• RFC 9562 — Universally Unique IDentifiers (UUIDs), IETF, 2024
• RFC 4122 — A Universally Unique IDentifier (UUID) URN Namespace, IETF, 2005
• PostgreSQL 17 Documentation — UUID Types
• Percona Blog — "UUID v7 and Database Performance" (2024)
• uuid6 Python library — https://github.com/oittaa/uuid6-python
• uuid npm package v9+ — https://github.com/uuidjs/uuid

Mathias Kouadio — Développeur web & mobile | DevToolbox (devstoolsbox.dev)