Versiones de UUID Explicadas — Deje de usar v4 para todo

Algo en tu código tiene una línea que se ve así: id = uuid.v4(). Funciona. Sus pruebas pasan. Los usuarios nunca se quejan. Y la administradora de bases de datos se enoja silenciosamente cada vez que mira el plan de consulta.

El UUID v4 se convirtió en el predeterminado porque es simple, universalmente disponible y resistente a colisiones lo suficiente como para que nunca realmente se produzca un conflicto. Pero «funciona» y «es la herramienta adecuada» no son lo mismo; y para claves primarias en bases de datos, el v4 está haciendo que tu sistema se ralentice a medida que crece.

Lo que hace realmente el UUID v4 en tu base de datos

Las bases de datos relacionales usan índices de tipo B-tree para claves primarias. Un B-tree mantiene los datos ordenados para que la base de datos pueda encontrar filas en tiempo O(log n). Cuando se inserta una nueva fila, la base de datos necesita colocarla en la posición correcta ordenada en el índice.

Con UUID v4, cada nueva ID es aleatoria. 550e8400-e29b-41d4-a716-446655440000 podría ser seguida por f47ac10b-58cc-4372-a567-0e02b2c3d479 — no hay relación entre inserciones consecutivas. La base de datos debe navegar hasta una hoja aleatoria en el B-tree cada vez.

Esto causa dos problemas a gran escala:

• División de páginas: Cuando una página de hoja del B-tree se llena, la base de datos debe dividirla en dos páginas y actualizar el padre. Con inserciones aleatorias, las divisiones ocurren frecuentemente en toda el índice — no solo al final.
• Fallas en el caché: El pool de búfer de la base de datos mantiene las páginas recientemente utilizadas en memoria. Las inserciones secuenciales acaban en las mismas "páginas calientes". Las inserciones aleatorias dispersan las lecturas por todo el índice, haciendo que el caché se sobrecargue y obligando a lecturas de disco.

En una tabla con millones de filas y alto tráfico de escritura, esta fragmentación del índice suma a una latencia real. Si tu EXPLAIN ANALYZE muestra que las búsquedas en índice tardan más de lo que deberían, los UUIDs aleatorios podrían ser parte de la diagnosis.

El árbol familiar de UUID

UUID v1: Marcas de tiempo, direcciones MAC y por qué no se usa

El UUID v1 fue el original "ordenable" UUID. Codifica un intervalo de 60 bits de marca de tiempo en intervalos de 100 nanosegundos desde el 15 de octubre de 1582, combinado con una secuencia de reloj y la dirección MAC de tu máquina. El resultado es aproximadamente ordenable por tiempo.

La parte de la dirección MAC es lo que mató al v1. Elige la identificación de interfaz de red de tu servidor en cada ID que generas — en cada registro de usuario, cada pedido, cada evento. Los investigadores de seguridad demostraron que los UUID v1 generados por la misma máquina son predecibles una vez que tienes un ejemplo. Las organizaciones comenzaron a evitarlo para cualquier uso que involucre a usuarios, y la mayoría de las bibliotecas de UUID lo marcan como descontinuado.

UUID v4: Aleatorio, seguro y mal adaptado para claves primarias

El UUID v4 es 122 bits de datos aleatorios criptográficos (los bits restantes codifican la versión). La probabilidad de colisión para un millón de UUIDs es aproximadamente 1 en 10^18. Para fines prácticos, es cero.

Esa aleatoriedad es exactamente lo que necesitas para tokens de seguridad, IDs de sesión, claves API y IDs de correlación — cualquier caso en el que necesites un ID que no pueda ser adivinado o enumerado. Para esos casos, continúa usando v4. El problema es que «no puede ser adivinado» y «amigable con la base de datos» son propiedades opuestas.

¿Quieres experimentar con la generación de UUIDs? El Generador de UUID en IO Tools te permite generar v1, v4, v7 y otras variantes al mismo tiempo para ver la diferencia en la estructura.

UUID v7: La nueva predeterminada que deberías usar

El UUID v7 fue estandarizado por el IETF en el RFC 9562 en mayo de 2023. Coloca una marca de tiempo en milisegundos del sistema Unix en los 48 bits más significativos, seguida de un campo de versión de 4 bits, un contador de secuencia de 12 bits y 62 bits de datos aleatorios.

Lo que esto significa en la práctica: los UUIDs generados más tarde son lexicográficamente mayores. Las inserciones consecutivas se colocan en posiciones adyacentes en el B-tree. Sin dispersión aleatoria, sin divisiones innecesarias de páginas, sin estrés en el caché. Se comporta como un entero autoincrementable desde la perspectiva de la base de datos — mientras que sigue siendo globalmente único sin coordinación.

El contador de secuencia dentro del mismo milisegundo garantiza un orden monótono incluso para generadores de alta frecuencia. Si generas 10.000 UUIDs en un milisegundo, seguirán ordenándose correctamente. El sufijo aleatorio conserva suficiente entropía como para que las colisiones entre sistemas distribuidos sigan siendo extremadamente improbables.

Para cualquier sistema nuevo que use PostgreSQL, MySQL o otra base de datos relacionales, el UUID v7 debería ser tu predeterminado para claves primarias.

ULID: La alternativa que llegó antes

ULID (Identificador universalmente único y lexicográficamente ordenable) resolvió el mismo problema antes de que existiera el UUID v7. Usa 48 bits para la marca de tiempo en milisegundos del sistema Unix y 80 bits de datos aleatorios, codificados en Base32 de Crockford.

El resultado es una cadena de 26 caracteres que se ve así 01ARZ3NDEKTSV4RRFFQ69G5FAV en lugar del formato de 36 caracteres con guiones de UUID. Es seguro para URLs sin codificación, se ordena correctamente como cadena y es insensible a mayúsculas/minúsculas.

ULID no tiene un RFC del IETF — tiene una especificación de comunidad en ulid.github.io. Eso es suficiente para la mayoría de los equipos, pero si estás en un entorno regulado que requiere identificadores formalmente estandarizados, el UUID v7 es la opción más segura. ULID tiene fuerte soporte en los ecosistemas de JavaScript y Go, y si tu equipo ya lo está usando, no hay razón urgente para cambiarlo.

Comparación lado a lado

Propiedad	UUID v1	UUID versión 4	CUID2	Identificación única
No (guiones)	Parcialmente	No	Sí	Sí
Resistente a colisiones	Sí	Sí	Sí	Sí
Amigable con la base de datos	Parcialmente	No	Sí	Sí
Seguro en privacidad	No (dirección MAC)	Sí	Sí	Sí
Organización estandarizada	IETF RFC 4122	IETF RFC 4122	IETF RFC 9562	Especificación de comunidad
Longitud típica	36 caracteres	36 caracteres	36 caracteres	26 caracteres
Fuente de entropía	MAC + reloj	Aleatorio	Marca de tiempo + aleatorio	Marca de tiempo + aleatorio

Cuándo usar cada uno

CUID2 — úsalo para claves primarias en cualquier sistema nuevo. Es un estándar del IETF, tiene creciente soporte en bibliotecas (integrado nativamente en PostgreSQL 17, disponible mediante bibliotecas en todos los principales lenguajes) y te da ordenamiento amigable para B-tree sin necesidad de coordinación.

UUID versión 4 — continúa usando este para cualquier cosa que requiera aleatoriedad en seguridad: tokens de sesión, tokens de recuperación de contraseñas, claves API, parámetros de estado de OAuth, IDs de correlación en los registros. La impredecibilidad es una característica aquí, no un defecto.

Identificación única — úsalo si tu equipo ya lo está usando, especialmente en proyectos de JavaScript o Go. El formato más corto es realmente más agradable en URLs y registros. Si estás empezando desde cero, el UUID v7 es la apuesta más segura a largo plazo simplemente porque tiene respaldo del IETF.

UUID v1 — no. No hay escenario en el que el v1 sea la opción adecuada para el nuevo código.

Consideraciones de migración

Si estás ejecutando un sistema existente con claves primarias de UUID v4, no necesitas migrar inmediatamente — y no deberías hacerlo de forma casual. Las relaciones de claves foráneas, el código de la aplicación y posiblemente valores almacenados en caché hacen referencia a esas IDs. Una migración requiere planificación cuidadosa y casi seguramente una ventana de mantenimiento.

Para la mayoría de los equipos, el enfoque práctico es: usar UUID v7 (o ULID) para todas las nuevas tablas y servicios. Acepta que tus tablas legadas tengan v4 y gestiona la fragmentación mediante reinicios periódicos del índice si el impacto en el rendimiento es medible. No dejes que la perfección sea enemiga del bien.

Si estás en un proyecto nuevo — nueva aplicación, nueva base de datos, nuevas tablas — no hay razón para elegir v4 para claves primarias. La herramienta está disponible. Genera algunos ejemplos de UUID v7 y ve lo que estás manejando.

La Conclusión

El UUID v4 no está mal — simplemente se aplica frecuentemente de forma incorrecta. Su aleatoriedad es una propiedad de seguridad, y deberías preservarla donde la seguridad importa. Para claves primarias en bases de datos, esa aleatoriedad se convierte en una carga de rendimiento a gran escala.

El UUID v7 resuelve el problema de forma limpia: creciente, globalmente único, estandarizado y ya soportado en las bases de datos y ORMs que estás utilizando. Si estás escribiendo esquemas de base de datos hoy, haz que v7 sea tu predeterminado. El futuro-tu — y tu DBA — notarán la diferencia.

También te puede interesar