UUID v4 vs UUID v7 vs ULID: ¿Qué ID único debe utilizar?

Los enteros automáticamente incrementados fueron la clave primaria predeterminada durante décadas. Son compactos y rápidos, pero requieren una base de datos central para distribuir números, filtrar cuántos registros tiene y hacer que fusionar datos de múltiples sistemas sea doloroso. Los identificadores únicos a nivel mundial resuelven estos problemas: cualquier servidor, aplicación móvil o cliente fuera de línea puede crear un ID que nunca chocará. La pregunta es de qué tipo. Esta guía compara las tres opciones más populares en 2026: UUID versión 4, UUID versión 7 y ULID.

Una actualización rápida de los UUID

UUID (Universally Unique Identifier) es un valor de 128 bits, generalmente escrito como 32 dígitos hexadecimales en cinco grupos:

550e8400-e29b-41d4-a716-446655440000

El estándar actual, RFC 9562 (publicado en 2024, que reemplaza al RFC 4122), define varias versiones. Unos pocos bits codifican la versión y la variante; el resto depende de la versión. El tercer grupo siempre comienza con el número de versión, así que puedes distinguir un v4 de un v7 a simple vista.

UUID v4: puramente aleatorio

Un UUID de versión 4 contiene 122 bits aleatorios más 6 bits fijos para la versión y la variante.

• Las fortalezas *

• Trivial para generar: cada lenguaje y base de datos tiene una función incorporada, como crypto.randomUUID() en JavaScript o gen_random_uuid() en PostgreSQL.
• No revela nada: ni marca de tiempo, ni identificador de máquina, ni secuencia.
• La probabilidad de colisión es insignificante. Tendrías que generar alrededor de 2.7 × 10^18 IDs para una probabilidad del 50% de un único duplicado.

** Debilidades **

• El orden aleatorio perjudica los índices de la base de datos. Los índices de árboles B, utilizados por PostgreSQL, MySQL y SQL Server, funcionan mejor cuando las nuevas claves llegan en orden creciente. Las teclas aleatorias aterrizan en todo el índice, causando divisiones de páginas, mala localización de la caché y amplificación de escritura. En las tablas grandes, el rendimiento de inserción puede disminuir significativamente y los índices crecen más grande de lo necesario.
• No se puede ordenar por tiempo de creación, por lo que necesita una columna created_at separada para consultas cronológicas.

UUID v7: ordenado por tiempo

La versión 7 coloca una marca de tiempo de 48 bits de Unix en milisegundos en la parte delantera, seguida de 74 bits de aleatoriedad (algunas implementaciones usan parte de ella como contador para ordenar dentro del mismo milisegundo).

01928c3e-5b7a-7c4d-9f3e-2a1b4c5d6e7f
└─timestamp─┘ └version 7

• Las fortalezas *

• Los nuevos IDs están aumentando, así que las inserciones se añaden al final del índice como teclas de incremento automático. Esto mantiene los índices compactos y escribe rápido.
• Ordenación por tipos de ID por tiempo de creación, lo que hace que la paginación basada en el cursor sea simple: WHERE id > :last_id ORDER BY id LIMIT 50.
• Todavía es un UUID estándar: se ajusta a las columnas nativas uuid, ORM y API que ya aceptan UUID.
• Puedes extraer el tiempo de creación de la ID para depurar.

** Debilidades **

• El tiempo de creación es visible para cualquiera que vea la identificación. Para la mayoría de los registros eso es inofensivo; para algunos, como las cuentas de usuario en un producto sensible a la privacidad, puede revelar cuándo alguien se registró.
• Requiere un reloj razonablemente preciso. Los grandes saltos del reloj hacia atrás pueden producir ID que ordenan antes que los existentes; las buenas bibliotecas manejan esto con contadores monótonos.
• Las funciones de generación nativas son más recientes. PostgreSQL 18 añadió uuidv7(); en versiones anteriores, generar en código de aplicación.

ULID: texto clasificable y compacto

ULID (Universally Unique Lexicographically Sortable Identifier) es anterior a UUID v7 y utiliza la misma idea: una marca de tiempo de 48 bits de milisegundos seguida de 80 bits aleatorios. La diferencia es la forma de texto: 26 caracteres de Crockford Base32.

01J9Z3K8M2Q7X4V5B6N8P0R2T4

• Las fortalezas *

• Más corto que la cadena UUID de 36 caracteres y seguro para URL.
• No es sensible a mayúsculas y excluye letras ambiguas (I, L, O, U), por lo que es más fácil de leer en voz alta o escribir.
• La clasificación de cadenas lexicográficas es igual a la clasificación cronológica, que ayuda en sistemas que almacenan IDs como texto, como almacenes de valores clave o nombres de archivos de registro.

** Debilidades **

• No es un UUID, por lo que no se ajusta a los tipos de columna nativos de UUID sin conversión (aunque sus 128 bits se pueden almacenar en uno).
• Una especificación comunitaria en lugar de un estándar IETF, con un comportamiento ligeramente diferente entre bibliotecas.
• Al igual que V7, expone el tiempo de creación.

Comparación recíproca

Propiedad	UUID v4	UUID v7	Ultrasolar
Tamaño	128 bits	128 bits	128 bits
Duración del texto	36	36	26
En orden de tiempo	- No , no es así .	- ¿ Qué?	- ¿ Qué?
Se filtra el tiempo de creación	- No , no es así .	Sí (ms)	Sí (ms)
Estándar	RFC 9562 (en inglés)	RFC 9562 (en inglés)	Especificación comunitaria
Tipo DB nativo	uuid	uuid	Por lo general texto o binario
Inserciones compatibles con el índice	Es pobre.	Es bueno.	Es bueno.

Consejos de almacenamiento

Sea lo que sea que elijas, almacena IDs como 16 bytes, no como texto. Una cadena de 36 caracteres ocupa más del doble de espacio, y cada índice y clave extranjera que hace referencia a ella multiplica el costo. PostgreSQL tiene un tipo nativo uuid; los usuarios de MySQL pueden usar BINARY(16) con UUID_TO_BIN(uuid, 1), donde el segundo argumento reordena las marcas de tiempo v1 para v7 utiliza el orden por defecto, ya que ya está ordenado por tiempo.

Exponer los ID en las API en su forma de texto canónico. Los clientes deben tratarlos como cadenas opacas y nunca analizar el significado de ellos.

Consideraciones de seguridad

Ninguna de estas identificaciones son secretas. No los use como símbolos de restablecimiento de contraseña o identificadores de sesión solo porque sean difíciles de adivinar. Un UUID v4 tiene suficiente aleatoriedad como para ser inevaluable, pero v7 y ULID tienen prefijos de marca de tiempo predecibles que reducen la entropía efectiva. Para los secretos, generar al menos 128 bits aleatorios con un generador criptográfico y tratarlos como contraseñas, idealmente almacenando sólo un hash ver MD5 vs SHA-256 para el cual usar el hash.

También considere la enumeración. Los enteros secuenciales permiten a cualquiera adivinar /orders/1001, /orders/1002. Las identificaciones aleatorias o ordenadas en el tiempo hacen que esto sea poco práctico, pero no sustituyen a los controles de autorización en cada solicitud.

¿Cuál debería elegir?

• ** Claves primarias de la base de datos en un nuevo sistema:** UUID v7. Obtiene generación distribuida y buen rendimiento de índice con compatibilidad completa UUID.
• Identificadores públicos en los que el tiempo de creación debe permanecer privado: UUID v4, o una clave interna v7 combinada con un ID público aleatorio separado.
• Tiendas basadas en texto, nombres de archivos o IDs: ULID, para su forma más corta, sin sensibilidad a mayúsculas y minúsculas.
• ** Sistema existente en v4 con problemas de rendimiento:** Considere v7 para nuevas tablas; mezclar versiones en una columna está técnicamente bien porque ambas son UUID válidas.

Generar identificadores

Para tareas rápidas datos iniciales, accesorios de prueba, inserciones manuales un generador de UUID basado en navegador puede producir hasta 1.000 valores v4, v7 o ULID a la vez utilizando crypto.getRandomValues. En el código de la aplicación, use la biblioteca estándar de su idioma o un paquete bien mantenido y genere IDs lo más cerca posible de la creación de registros.

Resumen

UUID v4 es aleatorio y privado pero dispersa índices de base de datos. UUID v7 agrega un prefijo de marca de tiempo que mantiene las inserciones rápidas y los IDs clasificables mientras permanecen como un UUID estándar. ULID ofrece el mismo ordenamiento con un formato de texto más corto y amigable. Para la mayoría de las nuevas aplicaciones, UUID v7 es el mejor predeterminado; alcance para v4 cuando el tiempo debe permanecer oculto y ULID cuando los humanos o sistemas basados en texto manejan los ID.