¿Odias los anuncios? Ir Sin publicidad Hoy 

UUID vs ULID vs CUID ¿Qué ID Único Deberías Usar?

Publicado el Abr 19, 2026

Cada fila de la base de datos, cada recurso de la API, cada evento distribuido necesita un ID. El problema no es generar uno: el problema es elegir el formato que no te pase factura seis meses después cuando tus índices de Postgres estén fragmentados y tus URLs se vean como ruido.

Aquí tienes el completo comparación de generador de UUID: UUID v4, UUID v7, ULID, CUID2 y Snowflake — qué son, dónde fallan y cuál deberías usar realmente.

UUID v4: El default seguro (con un gran problema)

UUID v4 tiene 128 bits de aleatoriedad, formateados como 550e8400-e29b-41d4-a716-446655440000. Es universalmente comprendido, soportado en todos los lenguajes, todas las bases de datos y todos los ORM del planeta.

La probabilidad de colisión es prácticamente cero — necesitarías generar un millón de UUIDs por segundo durante 85 años antes de tener una probabilidad de 50% de que ocurra una colisión. Eso no es un problema en la práctica.

El problema es el orden. UUID v4 es completamente aleatorio, lo que significa que al insertar filas en una tabla indexada por UUID, los escritos se dispersan por el árbol B. A gran escala, esto provoca divisiones de páginas, fragmentación de índices y degradación del rendimiento de inserción. Si estás insertando miles de filas por segundo en una tabla de MySQL o Postgres con clave primaria UUID, lo sentirás.

UUID v4 también tiene 36 caracteres como cadena — no es seguro para URLs sin codificación y es más pesado que las alternativas.

UUID v7: El hermano mejorado del UUID v4

UUID v7 soluciona el problema del orden. Es un UUID ordenado por tiempo, donde los bits más significativos codifican un timestamp en milisegundos, y el resto es aleatorio. El resultado: 01875f3a-7b2d-7f8e-a3d1-4b2e6c1a0f93.

Las filas insertadas en orden temporal permanecen aproximadamente secuenciales en el índice. Eso es una gran ventaja para cargas de escritura intensas. UUID v7 es compatible con toda la infraestructura existente de UUIDs — mismo formato, misma longitud del campo, mismas expectativas de soporte de bibliotecas — mientras añade ordenabilidad.

El RFC fue finalizado en 2022 y el soporte de bibliotecas está llegando rápidamente. Si ya estás usando UUIDs y no puedes cambiar tu esquema, pasar de v4 a v7 es de bajo riesgo y alto retorno.

ULID: La opción más amigable para los desarrolladores

ULID (Identificador Universalmente Único y Lexicográficamente Ordenable) codifica un timestamp de 48 bits y 80 bits de aleatoriedad en 26 caracteres en base32: 01ARZ3NDEKTSV4RRFFQ69G5FAV.

Lo que lo hace destacar:

Ordenable por defecto — el orden lexicográfico es el orden cronológico
Seguro para URLs — sin guiones, sin caracteres especiales
No distingue entre mayúsculas y minúsculas — evita la ambigüedad eliminando esos caracteres del alfabeto 0/O y 1/I — 26 caracteres en lugar de 36 para una cadena de UUID
Compacto ULID es la opción más práctica para nuevos proyectos que no tienen restricciones legadas. Es ordenable suficiente para la mayoría de casos, corta para URLs y legible suficiente para que un humano pueda copiar y pegar sin errores de transcripción.

Una advertencia: si generas varios ULID dentro del mismo milisegundo, el orden monótono se garantiza dentro del proceso, pero no entre nodos distribuidos. Para la mayoría de aplicaciones, eso está bien.

CUID2: Diseñado para sistemas distribuidos

CUID2 es el sucesor de CUID, rediseñado desde cero para seguridad y resistencia a colisiones en entornos distribuidos. Un CUID2 se ve así:

Utiliza un hash SHA-3 de una combinación de timestamp, contador, fingerprint (ID de proceso + nombre de host) y bytes aleatorios. El fingerprint es la diferencia clave — está diseñado específicamente para prevenir colisiones cuando ejecutas múltiples generadores de ID simultáneamente en muchos servidores. clh3uj5ln0000qzrmn831mbhe.

CUID2 es

no ordenable . Prioriza resistencia a colisiones e impredecibilidad sobre el orden temporal. Si estás construyendo un sistema donde los IDs se generan por clientes no confiables o en muchos nodos independientes y la seguridad es un problema, CUID2 vale la pena.Para la mayoría de APIs backend, es excesivo.

IDs de Snowflake: Alta capacidad, pero tú lo manejas tú

Los IDs de Snowflake fueron inventados en Twitter para generar IDs únicos a millones por segundo en un clúster distribuido. Un ID de Snowflake es un entero de 64 bits: timestamp (41 bits) + ID de datacenter (5 bits) + ID de máquina (5 bits) + secuencia (12 bits).

Son ordenables, compactos (fit en un

) y extremadamente rápidos. Discord, Instagram y muchos sistemas de alto volumen los usan. BIGINTEl problema: necesitas gestionar los IDs de máquina. Eso significa un servicio de coordinación (ZooKeeper, etcd, una tabla de base de datos) para asignar IDs de máquina únicos a cada generador de IDs. Si dos nodos comparten el mismo ID de máquina, obtienes colisiones. Configurar eso correctamente no es trivial, y mantenerlo implica sobrecarga operativa.

A menos que estés generando cientos de miles de IDs por segundo, la complejidad no vale la pena.

La comparación

UUID v7

	UUID versión 4	CUID2	Identificación única	Snowflake	Ordenable
No (guiones)	No	Sí	Sí	No	Sí
Seguro para URLs	Sí (entero)	Sí (entero)	Sí	Sí	Muy alta
Resistencia a colisiones	Alta (con coordinación)	Alta (con coordinación)	Alto	Alta (con coordinación)	Caso típico de uso
Complejidad	Ninguno	Ninguno	Ninguno	Bajo	Alto
Sistemas legados, uso general	Claves primarias en bases de datos	APIs, URLs, nuevos proyectos	Sistemas distribuidos o con clientes no confiables	Sistemas de alta capacidad	Generación de cada ID en Node.js

Puedes probar la generación de UUID directamente con el

// UUID v4
import { v4 as uuidv4 } from 'uuid';
console.log(uuidv4()); // '9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d'

// UUID v7
import { v7 as uuidv7 } from 'uuid';
console.log(uuidv7()); // '01875f3a-7b2d-7000-8000-4b2e6c1a0f93'

// ULID
import { ulid } from 'ulid';
console.log(ulid()); // '01ARZ3NDEKTSV4RRFFQ69G5FAV'

// CUID2
import { createId } from '@paralleldrive/cuid2';
console.log(createId()); // 'clh3uj5ln0000qzrmn831mbhe'

// Snowflake (using @socialgouv/nextid for simplicity)
import Snowflake from '@socialgouv/nextid';
const snowflake = new Snowflake(1n); // machine ID = 1
console.log(snowflake.nextId().toString()); // '1641024000000000001'

IO Tools Generador de UUID — soporta UUID v1 hasta v7 y generación en masa sin necesidad de instalar nada. ¿Cuál deberías usar?

Aquí está la recomendación real, no la evasiva "depende":

Nuevo proyecto, sin restricciones legadas:

. Ordenable, seguro para URLs, compacto. Es el mejor default. Usa Identificación únicaYa usas UUIDs y necesitas mejor rendimiento en la base de datos:
Migra a . Actualización directa, gran ventaja en índices. CUID2IDs generados por clientes o en nodos distribuidos no confiables:
. El uso de fingerprints hace que la resistencia a colisiones sea robusta incluso en condiciones adversas. Usa SnowflakePlataforma de alta capacidad (más de 100k IDs/seg), dispuesta a gestionar IDs de máquina:
. De lo contrario, no vale la pena. Usa OrdenableUUID v4:
Solo si estás manteniendo código legado y no puedes cambiar el formato. Deja de usarlo en nuevas tablas. La era de usar UUID v4 por defecto para todo ha terminado. ULID es el nuevo default para la mayoría de casos, y UUID v7 es el camino correcto para actualizar si ya estás en el mundo de los UUIDs. Elige uno y avanza.