T
uuid ulid nanoid database distributed-systems backend

Guía de Selección de Identificadores Únicos (ID) Modernos: Más allá de UUID v4

Un análisis exhaustivo de UUID v1-v8, ULID, NanoID, CUID2 y Snowflake IDs. Aprenda a elegir el identificador adecuado para su base de datos, sistemas distribuidos y seguridad de URL.

2026-04-11 Usar esta herramienta

Elegir el identificador único (ID) adecuado es una de las decisiones más críticas en la arquitectura de un sistema. Un ID mal elegido puede provocar cuellos de botella en el rendimiento de la base de datos, vulnerabilidades de seguridad o problemas de sincronización en sistemas distribuidos. Durante mucho tiempo, UUID v4 fue la opción "por defecto" para los desarrolladores. Sin embargo, a medida que los sistemas distribuidos y las bases de datos a gran escala evolucionaron, las limitaciones de UUID v4 (como la falta de capacidad de ordenación y la fragmentación de índices B-Tree) se hicieron más evidentes.

En esta guía, profundizaremos en la evolución de los UUID, exploraremos alternativas modernas como ULID y NanoID, y proporcionaremos un marco para seleccionar el mejor ID para su caso de uso específico.

1. La Evolución de UUID (de RFC 4122 a RFC 9562)

El Identificador Único Universal (UUID) ha sido el estándar de la industria durante décadas. Recientemente, el IETF actualizó el estándar con el RFC 9562, introduciendo nuevas versiones diseñadas específicamente para las necesidades de las bases de datos modernas y los sistemas distribuidos.

UUID v1: Basado en tiempo

UUID v1 combina la marca de tiempo actual, una secuencia de reloj y la dirección MAC del generador.

  • Pros: Unicidad garantizada en el espacio y el tiempo (si las direcciones MAC son únicas).
  • Contras: Preocupaciones de privacidad (expone la dirección MAC) y no es monótonamente creciente si se genera en diferentes máquinas, lo que puede perjudicar el rendimiento de los índices B-Tree.

UUID v3 y v5: Basados en nombre (MD5/SHA-1)

Estos son deterministas. Si proporciona el mismo espacio de nombres y nombre, obtendrá el mismo UUID.

  • UUID v3: Utiliza MD5.
  • UUID v5: Utiliza SHA-1 (preferido sobre v3).
  • Caso de uso: Cuando necesita IDs reproducibles basados en entradas únicas (por ejemplo, generar un ID a partir de una URL).

UUID v4: Aleatorio

La versión más común, compuesta por 122 bits aleatorios.

  • Pros: Probabilidad de colisión extremadamente baja, no se expone información sensible.
  • Contras: Completamente no ordenable. Cuando se utiliza como clave primaria en un índice B-Tree (como InnoDB de MySQL), causa una "fragmentación de índice" masiva y "divisiones de página", lo que lleva a una degradación severa del rendimiento a medida que la tabla crece.

La Nueva Generación: UUID v6, v7 y v8

El RFC 9562 introdujo estas versiones para solucionar el problema de ordenación de v4 manteniendo el formato UUID.

UUID v7: El Nuevo Estándar de Oro

UUID v7 está ordenado por tiempo. Utiliza una marca de tiempo Unix de 48 bits (precisión de milisegundos) seguida de bits aleatorios.

  • Por qué es excelente: Es lexicográficamente ordenable. Cuando se usa como clave primaria de base de datos, los nuevos registros se añaden al final del B-Tree, minimizando las divisiones de página y manteniendo un alto rendimiento.
  • Recomendación: Para casi todos los proyectos nuevos, UUID v7 debería reemplazar a UUID v4 como el ID predeterminado.

UUID v6

Es esencialmente un UUID v1 reordenado para que sea ordenable. Úselo solo si tiene una dependencia heredada de la estructura UUID v1 pero necesita capacidad de ordenación.

UUID v8

Permite una implementación personalizada manteniendo la estructura UUID. Útil para sistemas propietarios que necesitan incrustar metadatos específicos dentro del ID de 128 bits.

2. Profundización en Alternativas Modernas

Aunque los UUID son estándar, varias alternativas han ganado popularidad debido a ventajas específicas en legibilidad, longitud o generación distribuida.

ULID (Universally Unique Lexicographically Sortable Identifier)

ULID es un fuerte competidor de UUID v7.

  • Estructura: Marca de tiempo de 48 bits + 80 bits de aleatoriedad.
  • Codificación: Utiliza Base32 de Crockford, lo que lo hace de solo 26 caracteres (frente a los 36 de una cadena UUID estándar).
  • Pros: Seguro para URL, insensible a mayúsculas y minúsculas, ordenable y visualmente más corto que el UUID.
  • Contras: No es un formato UUID estándar (algunos tipos de bases de datos antiguos podrían no manejarlo tan eficientemente como un tipo nativo de 128 bits).

NanoID: La Alternativa Pequeña y Rápida

NanoID se utiliza a menudo en aplicaciones web y front-end.

  • Pros: Mucho más pequeño que UUID, alfabeto altamente personalizable y más rápido que UUID v4.
  • Seguridad: Utiliza generadores aleatorios criptográficamente fuertes.
  • Caso de uso: Perfecto para acortadores de URL, IDs de registros orientados al público donde se requieren cadenas cortas y no adivinables.

CUID2: La Próxima Generación de IDs Seguros

CUID2 está diseñado para ser seguro y amigable con el escalado horizontal.

  • Características: Altamente resistente a colisiones, no secuencial (evita ataques de enumeración) y portátil entre diferentes lenguajes de programación.
  • Caso de uso: Cuando la seguridad y la escalabilidad horizontal son más importantes que la ordenación estricta por tiempo.

Snowflake ID: El Peso Pesado Distribuido

Originalmente desarrollado por Twitter, los Snowflake IDs son enteros de 64 bits.

  • Estructura: Marca de tiempo + ID del trabajador + Número de secuencia.
  • Pros: Extremadamente rápido de generar, encaja en un BIGINT estándar (64 bits) y ordenado por tiempo.
  • Contras: Requiere una asignación de "ID de trabajador" centralizada o coordinada para evitar colisiones en un clúster.

3. Tabla Comparativa

Característica UUID v4 UUID v7 ULID NanoID Snowflake CUID2
Longitud 128 bits 128 bits 128 bits Variable 64 bits Variable
Ordenable No Sí (Tiempo) Sí (Tiempo) No Sí (Tiempo) No
Formato Hex Hex Base32 Alfanumérico Entero Alfanumérico
Riesgo Colisión Despreciable Despreciable Extremadamente bajo Configurable Cero (coordinado) Extremadamente bajo
Legibilidad Mala Mala Buena Excelente Buena Buena
Tipo Nativo DB Sí Sí No (Binario/Str) No (String) Sí (BIGINT) No (String)

4. Mejores Prácticas para Elegir un ID

Para Claves Primarias de Base de Datos

  • Use UUID v7 si su base de datos admite UUID de 128 bits (PostgreSQL, MySQL moderno, SQL Server). Proporciona el mejor equilibrio entre unicidad y rendimiento B-Tree.
  • Use Snowflake ID si está construyendo un sistema distribuido masivo y desea ahorrar espacio con enteros de 64 bits.
  • Evite UUID v4 para tablas grandes; las inserciones aleatorias destruirán su rendimiento de escritura.

Para URLs Públicas

  • Use NanoID o SQID. Son cortos, seguros para URL y visualmente agradables.
  • Short UUIDs (UUIDs codificados en Base58 o Base62) también son una gran opción para mantener la unicidad subyacente proporcionando una URL más limpia.

Para Sistemas Distribuidos (Microservicios)

  • ULID o KSUID son excelentes porque no requieren un coordinador central (a diferencia de Snowflake) pero aún proporcionan ordenación basada en el tiempo, lo cual es útil para depuración y registros.

5. Ejemplos de Código

Generar UUID v7 en Node.js

Con el paquete uuid:

const { v7: uuidv7 } = require('uuid');
console.log(uuidv7()); // ej., '018c3b7a-6b5d-7e8c-9a1b-2c3d4e5f6g7h'

Generar ULID en Python

Usando la librería python-ulid:

from ulid import ULID
ulid = ULID()
print(ulid) # ej., '01H6P7XG6WJ9S5H8K4M6N7B2P1'

6. Sección de Preguntas Frecuentes (FAQ)

P: ¿Puedo convertir mi UUID v4 existente a UUID v7? R: No, los bits están estructurados de manera diferente. Sin embargo, puede comenzar a usar UUID v7 para nuevos registros. La mayoría de las bases de datos pueden almacenar ambos en la misma columna UUID.

P: ¿Es NanoID tan seguro como UUID? R: Sí, si se eligen correctamente la longitud y el alfabeto. Un NanoID de 21 caracteres tiene una probabilidad de colisión similar a UUID v4.

P: ¿Por qué no usar simplemente enteros autoincrementales? R: Los autoincrementos son geniales para bases de datos pequeñas de un solo nodo. Sin embargo, exponen su volumen de datos a los competidores (ej., user/5000 le dice a alguien que tiene 5,000 usuarios) y son difíciles de gestionar en sistemas distribuidos.

7. Conclusión

En 2026, rara vez hay una razón para seguir con UUID v4 para las claves primarias de las bases de datos. El auge de UUID v7 ha proporcionado una solución estandarizada y ordenada por tiempo que resuelve los problemas de rendimiento manteniendo la compatibilidad. Para necesidades especializadas, ULID ofrece mejor legibilidad y los Snowflake IDs ofrecen la máxima eficiencia en arquitecturas distribuidas a gran escala.

Evalúe sus necesidades de capacidad de ordenación, legibilidad y rendimiento antes de comprometerse con un esquema de ID. Su yo del futuro (y su base de datos) se lo agradecerán.

Volver al blog Generador de UUID →