"UUID vs ULID vs CUID: ¿qué formato de ID único usar en 2026?"

Por qué los IDs únicos son más complejos de lo que parecen

Necesitas un identificador único para una fila de base de datos, un recurso API, un token de sesión. Fácil, ¿verdad? Usa un número.

El problema con los enteros secuenciales: son predecibles (/users/1, /users/2) — cualquiera puede enumerar tus recursos. Requieren una autoridad central (solo un servidor puede decidir el "siguiente" número). Y revelan información de negocio (tu pedido número 1000 tiene ID 1000).

Así que el mundo inventó mejores IDs. Y siguió inventando más. Aquí está lo que cada uno hace realmente.

UUID (v4) — La opción segura por defecto

Formato: 550e8400-e29b-41d4-a716-446655440000 Longitud: 36 caracteres (32 hex + 4 guiones) Aleatoriedad: 122 bits

UUID v4 son 122 bits aleatorios con un formato estándar. La probabilidad de colisión es tan astronómicamente baja (habría que generar 1.000 millones de UUIDs por segundo durante 85 años para tener un 50% de probabilidad de colisión) que es prácticamente imposible.

Lo que UUID hace bien:

• Estándar universal — todos los lenguajes, bases de datos y frameworks tienen soporte nativo
• No se necesita coordinación — cualquier servidor o cliente puede generar uno independientemente
• No secuencial — sin ataques de enumeración

Lo que UUID hace mal:

• No ordenable — los UUIDs son aleatorios, no se ordenan por tiempo de creación. En un índice B-tree (cómo funcionan la mayoría de bases de datos), las inserciones aleatorias causan "page splits" — la base de datos reorganiza constantemente su índice. A escala, esto es costoso.
• Grande: 36 chars como string, 16 bytes en binario
• No es URL-friendly (contiene guiones)

Usa UUID v4 cuando: necesitas un ID estándar y ampliamente soportado sin preocuparte por el orden de clasificación.

UUID v7 — UUID corregido

Formato: 018e2c4c-3d12-7f3a-91f8-3e4a5b6c7d8e Longitud: 36 caracteres Aleatoriedad: 74 bits (con prefijo timestamp de 48 bits en milisegundos)

UUID v7 (ratificado en 2023) es UUID con un prefijo de timestamp. Los primeros 48 bits son un timestamp Unix en milisegundos, lo que hace los UUIDs ordenables por tiempo de creación.

Por qué importa: IDs ordenables = inserciones secuenciales en el B-tree = mucho mejor rendimiento del índice de base de datos a escala.

Usa UUID v7 cuando: quieres compatibilidad UUID pero necesitas IDs ordenados en el tiempo para el rendimiento de la base de datos.

ULID — Alternativa UUID ordenable y URL-safe

Formato: 01ARZ3NDEKTSV4RRFFQ69G5FAV Longitud: 26 caracteres Aleatoriedad: 80 bits (con prefijo timestamp de 48 bits en milisegundos)

ULID (Universally Unique Lexicographically Sortable Identifier) resuelve el problema de ordenación de UUID con un formato más limpio. Codifica 48 bits de timestamp + 80 bits de aleatoriedad en Crockford Base32 (sin guiones, sin caracteres ambiguos).

Lo que ULID hace bien:

• Ordenable lexicográficamente (se ordena correctamente como string)
• URL-safe (sin guiones ni caracteres especiales)
• 26 chars vs 36 de UUID — más compacto
• Timestamp de precisión milisegundo incorporado

Lo que ULID hace mal:

• Menos universal que UUID — requiere biblioteca en la mayoría de lenguajes
• Monotonicidad: múltiples ULIDs generados en el mismo milisegundo pueden no ordenarse correctamente sin la variante monotónica

Usa ULID cuando: quieres IDs ordenables que también sean compactos y URL-safe, sin necesitar compatibilidad UUID.

CUID2 — URL-safe, resistente a colisiones, sin timestamp

Formato: clyg4v5l20000356ok1f5t6nb Longitud: 24 caracteres (por defecto) Aleatoriedad: alta (fingerprinting SHA-3, sin estructura predecible)

CUID2 está diseñado para contextos sensibles a la seguridad. A diferencia de ULID, deliberadamente no tiene prefijo de timestamp — no puedes inferir cuándo se creó un recurso a partir de su ID.

Lo que CUID2 hace bien:

• Más seguro que UUID/ULID para IDs públicos (sin información de timing)
• URL-safe
• Longitud configurable (equilibrio entre longitud y resistencia a colisiones)

Lo que CUID2 hace mal:

• No ordenable (por diseño)
• Menos ampliamente soportado que UUID
• Depende de una biblioteca específica

Usa CUID2 cuando: los IDs son públicos y no quieres revelar timestamps de creación (IDs de usuario, claves API, enlaces cortos).

NanoID — Pequeño, rápido, personalizable

Formato: V1StGXR8_Z5jdHi6B-myT Longitud: 21 caracteres (por defecto, configurable) Alfabeto: personalizable (por defecto: Base64 URL-safe)

NanoID es una alternativa moderna y pequeña a UUID. Misma probabilidad de colisión que UUID v4 en 21 chars, pero más pequeño y con alfabeto personalizable.

Lo que NanoID hace bien:

• El más compacto (21 chars vs 36 de UUID)
• Alfabeto personalizable — puede generar IDs usando solo minúsculas, solo números, etc.
• Disponible en 20+ lenguajes
• Rápido

Lo que NanoID hace mal:

• No ordenable
• No es un estándar (sin RFC)

Usa NanoID cuando: el tamaño importa (URLs, tokens cortos) o necesitas un alfabeto personalizado.

Tabla de decisión

La respuesta simple

• Elección por defecto: UUID v7 — ordenable, estándar, gran rendimiento DB
• Necesitas URL-safe + ordenable: ULID
• IDs públicos (no revelar timing): CUID2
• Tokens cortos, alfabeto personalizado: NanoID
• Sistema legacy / máxima compatibilidad: UUID v4

Genera IDs ahora

Generador UUID genera UUID v4 y v7 — generación masiva, copiar en un clic. Sin cuenta requerida.