UUID v4 o v7: qué son y cuándo usar cada uno

Qué aspecto tiene un UUID

Un UUID (identificador único universal) es un valor de 128 bits, escrito como 32 dígitos hexadecimales en cinco grupos separados por guiones: cf217f18-8cc6-4677-aa1e-5b7bc89ae6eb, 36 caracteres en total. Dos pequeños campos dentro de él indican de qué tipo es: una versión (la primera cifra del tercer grupo; aquí es 4) y una variante (la primera cifra del cuarto grupo). El estándar que los define es el RFC 9562, publicado en 2024, que deja obsoleto el antiguo RFC 4122.

Versión 4: aleatoria

El UUIDv4 está pensado para generar UUID a partir de números realmente aleatorios o pseudoaleatorios. De los 128 bits, 6 los fijan la versión y la variante, así que quedan 122 bits aleatorios. Es la versión a la que casi todo el mundo se refiere con «un UUID»: sin marca de tiempo, sin datos de la máquina, solo azar. Puedes crear uno en tu navegador con el generador de UUID, que produce los que necesites y funciona en local.

Versión 7: ordenada por tiempo

El UUIDv7, novedad del RFC 9562, coloca una marca de tiempo Unix en milisegundos (los milisegundos desde la medianoche del 1 de enero de 1970 UTC, sin segundos intercalares) en los 48 bits más significativos y rellena el resto con bits aleatorios. Como la marca de tiempo va primero, los UUID creados más tarde se ordenan después de los anteriores.

Eso importa en las bases de datos. El RFC 9562 explica que las versiones de UUID que no están ordenadas por tiempo, como la v4, tienen mala localidad en los índices de base de datos: los valores creados seguidos no quedan cerca unos de otros en el índice, así que las inserciones se hacen en posiciones aleatorias, con el coste de rendimiento que eso implica en las estructuras habituales. Una clave v7, en cambio, se añade cerca del final del índice. Si el UUID va a ser la clave primaria de una tabla grande, normalmente conviene la v7; si el identificador nunca se usa para ordenar ni como clave, la v4 sirve.

La marca de tiempo de una v7 es un arma de doble filo: te da orden, pero también muestra cuándo se creó el registro. El RFC 9562 señala que la marca de tiempo incrustada supone una superficie de ataque muy pequeña, porque indica el orden de creación. Si la fecha de creación es sensible, mejor la v4.

¿Qué probabilidad hay de una colisión?

Con 122 bits aleatorios hay unos 5,3 × 10³⁶ valores v4 posibles. La probabilidad de que dos de n UUID aleatorios coincidan es aproximadamente n² ÷ (2 × 5,3 × 10³⁶). Poniendo números:

• Mil millones de UUID: una probabilidad de alrededor de 10^-19, una entre diez trillones.
• Un billón de UUID: alrededor de 10^-13.
• Para llegar siquiera a una probabilidad entre mil millones de un solo duplicado habría que generar unos 103 billones.
• Para un 50 % de probabilidad hacen falta unos 2,7 trillones (2,7 × 10¹⁸).

Para cualquier aplicación real, la probabilidad de que dos UUID v4 honestos coincidan es muy inferior a la de un fallo de hardware. La salvedad es «honestos»: se supone una buena fuente de aleatoriedad. El RFC 9562 advierte de que descubrir que una fuente de números aleatorios es predecible produce una vulnerabilidad, y por eso los UUID deben salir de un generador criptográficamente seguro, no de algo como Math.random().

Lo que un UUID no es

Aquí es donde la gente se equivoca. Un UUID es un identificador, no un secreto. El RFC 9562 dice que las implementaciones no deben suponer que los UUID son difíciles de adivinar y que no deben usarse como capacidades de seguridad, es decir, identificadores cuya mera posesión da acceso. Así que no uses un UUID como enlace de restablecimiento de contraseña, clave de API, enlace compartido que deba seguir siendo privado ni token de sesión. Para eso, usa un valor aleatorio largo de un generador seguro (en cómo crear contraseñas seguras se explica qué es «suficientemente largo») y trátalo como un secreto. Un UUID en una URL está bien como ID; que «cualquiera con esta URL pueda verlo» es otra decisión de diseño, y un UUID por sí solo no lo hace seguro.

Evita también las versiones antiguas basadas en la hora y la dirección MAC para trabajo nuevo: el RFC 9562 dice que las direcciones MAC suponen riesgos inherentes para la privacidad y no deberían usarse en un UUID.

Consejos prácticos

• Guárdalos de forma compacta. Un UUID son 16 bytes; muchas bases de datos tienen un tipo UUID nativo más pequeño y rápido que una cadena de 36 caracteres.
• Compáralos en un solo formato. El estándar no distingue mayúsculas de minúsculas en el texto, pero mezclarlas al comparar causa errores; normaliza a minúsculas.
• No saques significado de ellos salvo que conozcas la versión. Solo las versiones basadas en tiempo (v1, v6 y v7) llevan una marca de tiempo.
• No los acortes. Cortar un UUID a sus 8 primeros caracteres destruye la garantía de unicidad.

Fuentes y más información

• RFC 9562: Universally Unique IDentifiers (UUIDs)

Datos comprobados el 3 de octubre de 2026.