Un UUID es un identificador de 128 bits escrito como 32 dígitos hexadecimales en cinco grupos. La versión 4 llena casi todo el valor con datos aleatorios. La versión 7 coloca un timestamp Unix en milisegundos en los bits más significativos, así que los identificadores se ordenan por el momento en que se crearon.

La diferencia dejó de ser teórica en mayo de 2024, cuando la RFC 9562 estandarizó las versiones 6, 7 y 8 y dejó obsoleta la RFC 4122 original. Esta guía compara las dos versiones entre las que de verdad vas a elegir, muestra cómo leer el timestamp de un v7 dentro del ID y cubre los casos en los que v7 es la respuesta equivocada.

01Qué cambió la RFC 9562

La RFC 4122 definió la familia de UUID que la mayoría de los sistemas sigue usando: la versión 1 combinaba un timestamp con un identificador de nodo, las versiones 3 y 5 hasheaban un nombre con MD5 o SHA-1, y la versión 4 era puro dato aleatorio. La RFC 9562 conserva todo eso y añade diseños nuevos.

Dos de esas filas llevan una advertencia de privacidad. Las versiones 1 y 6 pueden incluir un identificador de nodo derivado de una dirección MAC, y la especificación dice que las direcciones MAC plantean riesgos de privacidad y no deberían usarse en un UUID. Si todavía generas valores v1, ese es un motivo para cambiar.

02Cómo funciona UUIDv4

La versión 4 es el diseño más simple de la familia: toma 122 bits de datos aleatorios y sobrescribe dos campos pequeños para que quien lea pueda distinguir la versión y la variante.

xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx
                ^    ^
                |    +-- variante: bits altos 10
                +------- versión: 4

El 4 del tercer grupo es el nibble de versión, y el primer carácter del cuarto grupo queda restringido a 8, 9, a o b para que los bits de variante sean 10. Todos los demás bits son aleatorios.

El margen es enorme. La cota del cumpleaños sitúa una probabilidad de colisión del 50% cerca de 2^61,2 valores, unos 2,7 x 10^18 IDs. Generando mil millones de UUID por segundo, tardarías unos 86 años en llegar a ese punto.

El requisito de aleatoriedad no es decorativo. La versión 4 solo es impredecible si los bytes vienen de una fuente aleatoria criptográficamente segura, que es lo que exige la sección de datos aleatorios de la especificación. Una implementación con Math.random() produce una cadena con forma de UUID con mucha menos entropía de la que promete el formato.

03Cómo funciona UUIDv7

La versión 7 cambia algo de aleatoriedad por orden. Sus primeros seis bytes son un contador big-endian de milisegundos desde la época Unix, y los campos restantes siguen las reglas habituales de versión y variante:

Sin contar los bits de versión y variante, quedan 74 bits para la unicidad dentro del mismo milisegundo. La especificación permite que esos bits sean datos puramente aleatorios o un contador sembrado con cuidado, y señala que las implementaciones deben asegurar que los UUID generados por lotes sigan siendo monotónicos.

El timestamp de 48 bits se agota en el año 10889, así que la longevidad no es motivo para evitar v7. El coste es que el ID ya no es opaco: cualquiera que lo tenga puede leer cuándo se creó. Las dos secciones siguientes tratan ambas consecuencias.

04Leer la fecha de creación de un UUIDv7

Como el timestamp está al principio, puedes decodificarlo sin ninguna librería. Toma los 12 primeros caracteres hexadecimales, interprétalos en base 16 y trata el resultado como milisegundos Unix.

01a10665-2c90-7250-9fa2-05b104d55e28
-------- ----
    |      |
    |      +-- últimos 8 dígitos hexadecimales del timestamp de 48 bits
    +--------- primeros 16 bits

hex  01a106652c90
dec  1791108656272
date 2026-10-04T10:10:56.272Z

Esos valores salen de una ejecución local del 2026-10-04 con el paquete uuid 11.1.0 sobre Node.js 24.14.1. El comando y el paso de decodificación fueron:

node -e "const {v7}=require('uuid'); const id=v7();
  console.log(id, parseInt(id.replace(/-/g,'').slice(0,12),16))"

Ejecútalo dos veces y verás que el campo de milisegundos crece entre llamadas. Cinco valores consecutivos generados en el mismo proceso se ordenaron correctamente como cadenas simples, porque la librería siembra un contador monotónico y lo incrementa cuando el reloj no ha avanzado.

El contador es por proceso. Dos workers en la misma máquina, o dos contenedores con relojes ligeramente distintos, pueden producir valores v7 cuyo orden no coincide con el orden en que se escribieron. El orden es una propiedad de un generador bien comportado, no del formato por sí solo.

Un UUIDv7 es un timestamp que puedes leer, no un timestamp en el que puedas confiar.

Los relojes derivan, NTP puede retroceder y cada nodo tiene su propia idea del ahora. Trata la hora incrustada como una pista para depurar, no como la fecha de creación autoritativa de un registro.

05Orden y localidad del índice

El beneficio de poner el timestamp primero aparece dentro de un índice de base de datos. La especificación dice con claridad que los valores de las versiones 6 y 7 se ordenan como bytes crudos sin necesidad de analizarlos, y que los UUID ordenados por tiempo se benefician de la localidad del índice, con diferencias reales que pueden llegar a un orden de magnitud o más frente a inserciones aleatorias.

Ese es el argumento para preferir v7 sobre v4 como clave primaria. Una clave aleatoria se inserta en una posición aleatoria de un B-tree, así que cada fila nueva puede tocar una página hoja distinta y el conjunto de trabajo crece con la tabla. Una clave ordenada por tiempo se inserta cerca del final, donde acaba de ocurrir la inserción anterior, así que las páginas calientes se mantienen pequeñas.

El orden también funciona en formato de texto, porque la representación hexadecimal es de ancho fijo y el byte más significativo va primero. No hace falta decodificar nada para obtener el orden cronológico:

01a10665-2c90-7250-9fa2-05b104d55e28   anterior
01a10665-2c91-73bf-8070-fa5b3b1fd080   posterior

Hay tres advertencias prácticas. Primero, v7 concentra las claves nuevas al final del índice, que es exactamente la forma que quiere una carga de inserción en un solo nodo y exactamente la forma que un sistema distribuido puede convertir en un shard caliente; si haces sharding por prefijo del ID, v4 reparte mejor. Segundo, un salto del reloj hacia atrás puede producir valores mal ordenados. Tercero, los valores v4 y v7 pueden convivir en la misma columna, pero una columna mezclada solo está parcialmente ordenada, así que no supongas que ordenar filas históricas significa algo.

Si lo que necesitas es un identificador ordenable legible por personas en lugar de un UUID, ULID ofrece el mismo prefijo de milisegundos de 48 bits con otra codificación. No es un reemplazo directo: ULID son 26 caracteres base32 y no tiene campos de versión ni de variante, así que un ULID no es un UUID válido y los tipos de base de datos que validan la estructura lo rechazan.

06Por qué UUIDv7 no es un secreto

Un identificador opaco no debería contarle nada a un atacante. Un UUID v7 sí: revela cuándo se creó la fila, al milisegundo, y el orden en que llegaron los registros. Con dos IDs puedes saber cuál vino antes sin tocar la base de datos.

La especificación lo aborda directamente: señala que un timestamp junto con un contador revela el orden de creación y afirma que, si se necesitan UUID para cualquier operación de seguridad, debería usarse UUIDv4. Si generas enlaces de restablecimiento de contraseña, tokens de sesión o identificadores de URL firmadas, v7 es la versión equivocada.

UUIDv4 tampoco es una respuesta de seguridad completa. Sus 122 bits aleatorios son impredecibles cuando el generador usa una fuente segura, pero sigue siendo un identificador de propósito general y no un token diseñado para eso. Para sesiones y enlaces de un solo uso, un token aleatorio dedicado de 256 bits da más margen y una intención más clara a quien lea el código después.

Elige la versión por el modelo de amenaza, no por la moda.

Si el ID debe ser impredecible o no debe revelar el orden de creación, usa v4. Si el ID es una clave de base de datos cuyo patrón de inserción domina el rendimiento, usa v7. Los dos no son intercambiables en ambos sentidos.

07¿Cuál deberías usar?

La mayoría de los sistemas acaban usando los dos, en papeles distintos. Esta tabla es la versión corta del intercambio:

El almacenamiento importa menos que la elección de versión. Una columna nativa uuid en PostgreSQL guarda los mismos 16 bytes en ambos casos, y la forma textual siempre son 36 caracteres con guiones. Lo que cambia es el patrón de inserción y lo que el valor expone.

08Generar v4 y v7 en el navegador

El Generador de UUID de UrsaKit produce ambas versiones sin enviar nada a un servidor.

1. Elige una versión en el selector Version: UUID v4 (random) o UUID v7 (time-ordered). El valor por defecto es v4.
2. Ajusta How many entre 1 y 500. El valor por defecto es 5.
3. Activa o desactiva las opciones de formato: Uppercase (activada por defecto), Keep hyphens, Braces {} y Quotes "".
4. Pulsa Generate y usa Copy all o Download.

La salida siguiente procede de una ejecución real con los ajustes por defecto el 2026-10-04:

version 4, default options       A0ACD050-B919-44BC-BEB3-B55076F2F736
version 7, default options       01A10666-3D98-732B-9AFA-E9439D6029BE
version 7, no hyphens, lowercase 01a106663d98732b9afae9439d6029be

Son valores reales de esa ejecución. Las mayúsculas y los guiones están activados por defecto; desactivarlos solo cambia la representación, no los 128 bits que hay debajo. El valor central se decodifica como 2026-10-04T10:12:06.168Z, unos 70 segundos después del valor usado en el ejemplo de timestamp anterior.

Si depuras un valor v7, pega su campo de timestamp en un conversor de timestamp para ver la fecha en UTC y en hora local, o usa un conversor de bases numéricas para comprobar la aritmética hexadecimal a mano. Cuando el ID viaje después dentro de un payload de API, un validador de JSON es la comprobación barata de que el resto del cuerpo sigue bien formado.

09Fuentes

• RFC 9562 — Universally Unique IDentifiers (UUIDs) (fecha de consulta: 2026-10-04)
• RFC 4122 — A Universally Unique IDentifier (UUID) URN Namespace (fecha de consulta: 2026-10-04)
• ULID Specification (fecha de consulta: 2026-10-04)