Matriz de especificaciones UUID: RFC 4122 frente a RFC 9562
El Grupo de Trabajo de Ingeniería de Internet (IETF) ratificó RFC 9562 en 2024 para modernizar el estándar histórico RFC 4122. La elección de la versión de UUID adecuada depende de los requisitos de agrupamiento de datos, las necesidades de entropía criptográfica y las restricciones de seguridad:
| Versión | Estándar | Mecanismo de generación | Ordenable por tiempo | Caso de uso principal |
|---|---|---|---|---|
| UUID v4 | RFC 4122 | Pseudoaleatorio criptográfico (CSPRNG) | No (Uniformemente aleatorio) | Identificadores únicos de propósito general, tokens de sesión, claves de API, trazabilidad distribuida (Predeterminado) |
| UUID v7 | RFC 9562 (2024) | Época Unix ms (48b) + Aleatorio (74b) | Sí (Monotónico / Big-Endian) | Claves primarias en bases de datos relacionales (PostgreSQL, MySQL InnoDB, SQLite), índices B-Tree agrupados |
| UUID v1 | RFC 4122 | Marca gregoriana (60b) + ID de nodo (48b) | No estándar (Tiempo bajo primero) | Sistemas empresariales heredados; el generador web usa bits de nodo aleatorios según RFC 4122 §4.5 para preservar la privacidad |
| UUID v3 / v5 | RFC 4122 | Hash MD5 (v3) / SHA-1 (v5) de espacio de nombres | No | Identificadores deterministas derivados de espacio de nombres y cadena de nombre (p. ej., URI, asignación DNS) |
| UUID v6 | RFC 9562 | Marca gregoriana de 60 bits reordenada de v1 | Sí (Monotónico) | Sustitución directa en sistemas v1 heredados que requieren ordenación cronológica en índices B-Tree |
| UUID v8 | RFC 9562 | Estructura de bits personalizada / definida por proveedor | Específico de la implementación | Arquitecturas empresariales a medida con cargas binarias no estándar dentro de un contenedor UUID de 128 bits |
| Nil / Max UUID | RFC 4122 / 9562 | Todos los 128 bits a 0x00 (Nil) o 0xFF (Max) | Límites de contorno | Valores centinela, valores predeterminados no inicializados (00000000-0000-0000-0000-000000000000) y límites de consulta por rangos |
Estructura binaria y disposición de 128 bits
Un UUID estándar está compuesto por exactamente 128 bits (16 octetos / 32 caracteres hexadecimales) organizados en cinco grupos separados por guiones: 8-4-4-4-12. En el orden estándar de bytes de red (big-endian), ciertas posiciones de bits determinan el número de versión y la variante RFC:
UUID v4 (Aleatorio)
RFC 4122 §4.4- xxxxxxxx-xxxx: 48 bits de datos pseudoaleatorios.
- 4xxx: 4 bits de versión (
0100₂ = 4) seguidos de 12 bits pseudoaleatorios. - yxxx: 2 bits de variante (
10₂; carácter hexadecimal 8, 9, a o b) seguidos de 14 bits pseudoaleatorios. - xxxxxxxxxxxx: 48 bits finales pseudoaleatorios. Entropía total: 122 bits.
UUID v7 (Época en milisegundos)
RFC 9562 §5.7- tttttttt-tttt: Marca de tiempo de época Unix sin signo de 48 bits en milisegundos (big-endian).
- 7xxx: 4 bits de versión (
0111₂ = 7) seguidos de 12 bits de datos aleatorios o contador monotónico. - yxxx: 2 bits de variante (
10₂) seguidos de 14 bits aleatorios. - xxxxxxxxxxxx: 48 bits finales de datos aleatorios. Entropía aleatoria total: 74 bits.
Data1, Data2, Data3) en formato little-endian nativo de la arquitectura x86. Aunque la representación textual es idéntica, las conversiones binarias entre GUIDs COM y UUIDs RFC estándar deben considerar esta transposición de endianness.Rendimiento en bases de datos: por qué UUIDv7 resuelve el problema de los árboles B-Tree
En motores de bases de datos relacionales como PostgreSQL, MySQL (InnoDB) y SQLite, las claves primarias dictan la disposición física de las páginas de índices B-Tree agrupados en disco. El patrón de generación de sus claves primarias repercute de forma directa en el rendimiento de escritura y la eficiencia del almacenamiento:
La penalización de escritura aleatoria con UUIDv4
Dado que los valores de UUIDv4 son uniformemente aleatorios, cada inserción apunta a una página impredecible del índice B-Tree. Cuando el volumen de datos supera la memoria RAM disponible, el motor de la base de datos debe leer reiteradamente páginas de índice aleatorias del disco, dividir páginas saturadas en dos nodos semivacíos (page splits) y reescribir los nodos superiores. Esto genera:
- Grave amplificación de escritura y sobrecarga de E/S aleatoria en disco
- Inflación del tamaño del índice con factores de llenado de apenas el 50% debido a divisiones constantes
- Desalojo prematuro de páginas de caché esenciales del buffer pool de la base de datos
La solución secuencial de UUIDv7
UUIDv7 antepone a cada identificador una marca de tiempo de 48 bits en milisegundos. Esto asegura que los nuevos registros se agreguen de manera natural en la hoja más a la derecha del índice B-Tree agrupado, comportándose como los enteros autoincrementales clásicos:
- Cero divisiones de páginas intermedias en ingestas masivas secuenciales
- Empaquetado óptimo de páginas de índice (alcanzando densidades del 90–100%)
- Generación descentralizada en arquitecturas de microservicios sin bloqueos coordinados
| Estrategia de almacenamiento | Tamaño en disco por fila | Ocupación del índice (10M filas) | Localidad de inserción |
|---|---|---|---|
| UUIDv4 en VARCHAR(36) | 37 bytes (36 + prefijo de 1) | ~750 MB (debido a divisiones con 50% de llenado) | Completamente aleatoria |
| UUIDv4 en BINARY(16) / uuid | 16 bytes | ~320 MB | Aleatoria |
| UUIDv7 en BINARY(16) / uuid | 16 bytes | ~175 MB (empaquetado compacto) | Inserción monotónica consecutiva |
Probabilidad de colisión y límites de entropía criptográfica
En sistemas distribuidos, la probabilidad de colisión se evalúa mediante la aproximación del problema del cumpleaños: p ≈ 1 - exp(-n² / (2 × 2^k)), donde k corresponde a los bits de entropía aleatoria y n representa la cantidad de identificadores generados.
Límites de entropía en UUID v4
UUID v4 proporciona 122 bits de aleatoriedad criptográfica (2¹²² ≈ 5,3 × 10³⁶ combinaciones posibles).
- Para incurrir en una probabilidad de colisión de apenas 1 entre mil millones (
10⁻⁹), un sistema debe emitir 103 billones de UUIDs. - Generar 1.000 millones de UUIDs por segundo durante 100 años seguidos arroja una probabilidad de colisión inferior a
10⁻¹⁵.
Límites de concurrencia en UUID v7
UUID v7 contiene 74 bits de entropía combinados con resolución de milisegundos.
- En cada ventana de un único milisegundo, se admiten 2⁷⁴ (≈ 1,88 × 10²²) valores únicos.
- Incluso con 10.000 nodos independientes emitiendo identificadores en el mismo milisegundo exacto, el riesgo de colisión sigue siendo matemáticamente despreciable.
- Los contadores monotónicos definidos en RFC 9562 §6.2 garantizan ordenación estricta para múltiples IDs emitidos dentro del mismo pulso temporal.
Generación de UUID en lenguajes de programación
Implementaciones mediante bibliotecas estándar y paquetes de producción para entornos backend modernos y motores de bases de datos:
// RFC 4122 UUID v4 nativo (Navegador y Node 14.17+):
const v4 = crypto.randomUUID();
// RFC 9562 UUID v7 (mediante paquete 'uuid'):
import { v7 as uuidv7 } from 'uuid';
const v7 = uuidv7();Comparativa de esquemas de identificación: UUID frente a ULID, NanoID y TSID
Los equipos de ingeniería eligen esquemas de identificación considerando las características de indexación en bases de datos, la longitud del juego de caracteres y la estandarización formal:
| Identificador | Tamaño en bits | Longitud en texto | Ordenable | Estandarización | Caso óptimo |
|---|---|---|---|---|---|
| UUID v4 | 128 bits | 36 caracteres | No | IETF RFC 4122 | Tokens efímeros, IDs no agrupados |
| UUID v7 | 128 bits | 36 caracteres | Sí (milisegundos) | IETF RFC 9562 | Claves primarias agrupadas en bases de datos relacionales |
| ULID | 128 bits | 26 caracteres (Base32) | Sí (milisegundos) | Especificación comunitaria | Slugs compactos para URLs que requieren orden cronológico |
| NanoID | Configurable | 21 caracteres (Base64) | No | Biblioteca NPM | Identificadores breves para URLs públicas |
| TSID / Snowflake | 64 bits | 13 caracteres / BIGINT | Sí (milisegundos) | Propio / Twitter | Columnas de números enteros de 64 bits nativas |
Frequently Asked Questions
¿Qué versión de UUID debo elegir: UUID v4 o UUID v7?
Elija UUID v7 para claves primarias en bases de datos relacionales (PostgreSQL, MySQL, SQLite) o cualquier conjunto indexado mediante árboles B-Tree, ya que su prefijo de marca de tiempo en milisegundos de 48 bits previene la fragmentación del índice. Elija UUID v4 para identificadores únicos de propósito general, tokens de API, identificadores de sesión y trazabilidad distribuida donde no se requiera ordenación cronológica o no deba revelarse el momento de creación del registro.
¿Cuál es el riesgo real de una colisión de UUID en producción?
Prácticamente nulo. UUID v4 posee 122 bits de aleatoriedad criptográfica (2¹²² ≈ 5,3 × 10³⁶ valores posibles). Según el problema del cumpleaños, generar 103 billones de UUIDs conlleva solo una probabilidad de 1 entre mil millones de sufrir una sola colisión. UUID v7 combina una marca de tiempo en milisegundos de 48 bits con 74 bits de entropía (2⁷⁴ ≈ 1,88 × 10²² valores por milisegundo), garantizando operaciones libres de colisiones incluso en clústeres distribuidos de alta concurrencia.
¿Por qué UUID v7 es superior a UUID v4 para claves primarias en bases de datos?
Los valores aleatorios de UUID v4 dispersan las inserciones entre páginas arbitrarias del índice B-Tree, provocando divisiones frecuentes de nodos hoja (page splits), un 50% de fragmentación del índice y un alto volumen de operaciones de E/S aleatorias en disco una vez que la tabla supera la memoria RAM. UUID v7 añade como prefijo una marca de tiempo cronológica, garantizando que los nuevos registros se agreguen secuencialmente al extremo derecho del índice agrupado (clustered index), logrando el rendimiento de escritura de enteros autoincrementales con las ventajas de la generación descentralizada.
¿Cuál es la diferencia entre un UUID y un GUID de Microsoft?
UUID (Identificador Único Universal) y GUID (Identificador Único Global) representan el mismo concepto matemático de 128 bits. UUID es el estándar formal de la IETF (RFC 4122 / RFC 9562), mientras que GUID es la implementación histórica de Microsoft en Windows. Textualmente, ambos emplean la misma representación hexadecimal de 8-4-4-4-12 separada por guiones y son intercambiables. Internamente, los GUID antiguos de Windows utilizaban orden de bytes little-endian en los primeros tres grupos, mientras que los UUID RFC estándar emplean orden de red big-endian.
¿Cómo deben almacenarse los UUIDs en PostgreSQL, MySQL y SQLite para maximizar el rendimiento?
En PostgreSQL, almacene los UUIDs utilizando el tipo nativo de 16 bytes "uuid", que se indexa directamente en árboles B-Tree. En MySQL 8+, utilice "BINARY(16)" en lugar de "VARCHAR(36)" para reducir la ocupación del índice en un 55%, empleando UUID_TO_BIN() o UUID v7 nativo. En SQLite, utilice columnas "BLOB" de 16 bytes o "TEXT" de 32 caracteres. El almacenamiento binario junto con UUID v7 ordenado cronológicamente minimiza el espacio en disco y elimina el coste de rebalanceo de nodos B-Tree.
¿Cómo puedo validar un UUID existente y extraer su marca de tiempo de creación?
Acceda a la pestaña "Validador e inspector" y pegue la cadena de UUID. La herramienta verifica la conformidad con la sintaxis RFC 4122 / RFC 9562, detecta el número de versión (p. ej., v1, v4, v7) y los bits de variante, y extrae automáticamente la fecha y hora UTC incrustada en las versiones temporales (UUID v7 y UUID v1).
¿Por qué se desaconseja UUID v1 en aplicaciones web modernas y accede esta herramienta a mi dirección MAC?
En la especificación original RFC 4122, las implementaciones de servidor de UUID v1 incrustan la dirección física MAC IEEE 802 de 48 bits de la máquina host y una marca de tiempo gregoriana de 60 bits, lo que puede exponer la identidad física de la red en APIs públicas. En navegadores web, JavaScript no tiene acceso a la dirección MAC física debido al aislamiento de seguridad (sandbox). Conforme a RFC 4122 §4.5 para entornos sin acceso a MAC, esta herramienta genera un nodo pseudoaleatorio de 48 bits criptográficamente seguro con el bit de multidifusión activado, evitando cualquier fuga de identidad de hardware.
¿Cómo gestiona UUID v7 la concurrencia masiva dentro del mismo milisegundo?
La especificación RFC 9562 ofrece dos mecanismos para concurrencia sub-milisegundo: asignar parte del campo "rand_a" de 12 bits como un contador monotónico incremental, o recurrir a 74 bits de entropía aleatoria criptográficamente segura. Con 74 bits de aleatoriedad en cada fracción de milisegundo, un sistema puede generar miles de identificadores por milisegundo por nodo sin riesgo de colisión.