UUID v4 y v7: cuándo usar cada uno y cómo validar

Qué es un UUID

Un UUID (Universally Unique Identifier) es un identificador de 128 bits diseñado para ser único sin coordinación entre máquinas. Se representa habitualmente como 32 caracteres hexadecimales en grupos 8-4-4-4-12 separados por guiones (por ejemplo, 550e8400-e29b-41d4-a716-446655440000). El estándar vigente es RFC 9562, publicado en 2024 como sucesor de RFC 4122; mantiene compatibilidad con todos los UUIDs ya en circulación y añade las nuevas versiones v6, v7 y v8.

De los ocho tipos definidos, dos cubren prácticamente todo el uso real moderno: v4 (aleatorio) y v7 (timestamp + aleatorio, ordenable por tiempo). El resto tiene casos de uso específicos (v3/v5 derivan un UUID determinista a partir de un namespace y un nombre, v1 incrusta el timestamp y el node field del emisor, v6 es una variante ordenable anterior a v7 que quedó obsoleta, v8 es completamente custom).

UUID v4: aleatorio y ampliamente soportado

v4 es la opción universal por defecto. 122 bits de aleatoriedad criptográfica (los otros 6 codifican versión y variante), formato canonical reconocible y soporte nativo en todas las plataformas (Postgres tiene gen_random_uuid(), Java tiene UUID.randomUUID(), Node tiene crypto.randomUUID()). Si solo necesitas un identificador único y no importa el orden, v4 es la opción con menos fricción.

La cantidad de entropía es astronómicamente alta. El espacio de valores posibles es de unos 5.3 × 10^36. Para que la probabilidad de colisión llegue al 0.0001%, tendrías que generar miles de millones de UUIDs por segundo durante décadas. En la práctica, siempre que el generador use una fuente criptográfica (Web Crypto, /dev/urandom, BCryptGenRandom), las colisiones no son un riesgo real.

UUID v7: ordenable por tiempo

v7 reserva los 48 bits más significativos para un timestamp Unix en milisegundos big endian. El resultado es un UUID lexicográficamente ordenable: si generas dos UUIDs v7 con segundos de diferencia, el más reciente es siempre mayor en orden alfabético. El resto del espacio (los 74 bits que no son timestamp, version ni variant) es aleatorio, así que dos UUIDs generados en el mismo milisegundo siguen siendo distintos.

La motivación principal son las claves primarias de bases de datos. Postgres, MySQL, SQLite y otros motores relacionales usan índices B-tree para sus PKs. Con v4, cada inserción cae en una posición aleatoria del índice, lo que provoca splits frecuentes de páginas y fragmentación. Con v7, las inserciones son cuasi- secuenciales: las nuevas filas casi siempre van al final del índice, lo que mejora la localidad de cache, reduce los splits y baja el coste de I/O en tablas grandes. Es el patrón que ULID popularizó y que el estándar UUID adoptó en RFC 9562.

UUID v4 vs UUID v7: comparativa

Cuándo usar UUID en bases de datos

La elección entre integer autoincremental y UUID como clave primaria depende de tres ejes:

• Sistemas distribuidos: si necesitas generar IDs en varios servidores o en cliente sin coordinación, UUID es la opción. Un integer autoincremental requiere ronda al servidor o secuencias coordinadas.
• Exposición pública del ID: un integer autoincremental filtra información de orden y volumen (un cliente con ID 1234 sabe que probablemente hay 1234 clientes). Un UUID no.
• Coste de almacenamiento e índice: un UUID ocupa 16 bytes (Postgres lo guarda binario, no como string), frente a 4-8 bytes de un integer. En tablas con miles de millones de filas, la diferencia importa. Con v4 además fragmenta el índice; con v7 menos.

Recomendación pragmática: usar v7 como PK cuando el sistema necesita IDs distribuibles y no quieres pagar la fragmentación de v4. Mantener integer autoincremental cuando ya funciona y no tienes el problema de generación distribuida.

Validar y normalizar UUIDs

La forma canonical RFC 9562 es lowercase con guiones en el formato 8-4-4-4-12. Cualquier sistema serio debería normalizar a esa forma al recibir un UUID externo: al comparar UUIDs en una tabla, en una cookie o en una URL, un mismatch de casing puede dar falsos negativos. La herramienta UUID generator de ToolsOps tiene un modo Validar que acepta input con guiones, sin guiones, en mayúsculas o minúsculas, y devuelve la versión, la variante y el canonical normalizado.

La versión se lee del nibble alto del 7º byte (carácter 14 con guiones); la variante se lee de los bits altos del 9º byte (carácter 19). El subconjunto realmente usado en producción es variant RFC 4122 (bits 10xx), que cubre todas las versiones que un sistema moderno emite o consume.

Errores comunes

• Usar v4 como clave primaria de una tabla grande y descubrir tarde la fragmentación del índice. Si llegas tarde, valora tablas particionadas por tiempo antes que regenerar IDs.
• Tratar el formato canonical como secret cuando lo es solo estructural. v4 tiene entropía suficiente pero su forma es reconocible; para secrets prefiere crypto.getRandomValues(new Uint8Array(32)) en base64url.
• Generar UUIDs con Math.random(). Sin fuente criptográfica las colisiones reales son posibles y los IDs son predecibles. Usa siempre Web Crypto o el equivalente del runtime.
• Aceptar un v1 como input sin saber qué hace con el node field. Si tu sistema procesa UUIDs externos, mejor restringir a v4 y v7 a propósito.
• Suponer que un v7 tiene precisión sub-milisegundo. Solo los 48 bits altos son timestamp; dos UUIDs generados en el mismo ms difieren en los bits aleatorios y su orden relativo es arbitrario.
• Persistir UUIDs como string en una tabla grande sin convertir a binario. Postgres y MySQL guardan UUID binario nativo (16 bytes) que ocupa la mitad que el VARCHAR(36) y es más rápido de indexar.

Cómo usar el generador de ToolsOps

El generador y decodificador de UUID de ToolsOps tiene tres modos. En Generar eliges v4 o v7 y una cantidad entre 1 y 100, con opciones de mayúsculas y de quitar los guiones para formatos no canonical. En Validar pegas un UUID y la herramienta detecta versión y variante. En Decodificar pegas un v7 y obtienes el timestamp embebido como ISO UTC, hora local y edad relativa.

La generación corre 100% en el navegador con Web Crypto API. Ni los UUIDs producidos ni el input que pegas en Validar o Decodificar se envían a un servidor. Para validar firmas u otro contenido autenticado, la herramienta hermana es el decodificador y verificador de JWT. Para verificar la integridad de archivos descargados, la calculadora de hash y checksum.