Genera ULIDs ordenables cronológicamente — como UUID pero con timestamp embebido
También podrías necesitar
ULID (Universally Unique Lexicographically Sortable Identifier) es un estándar de identificador único diseñado para superar las limitaciones de UUID v4 en sistemas distribuidos con bases de datos. Un ULID tiene 26 caracteres en Crockford Base32 y se compone de dos partes: los primeros 10 caracteres codifican el timestamp Unix en milisegundos (con precisión de 1ms), y los 16 caracteres restantes son aleatoriamente generados. Esto le da tres ventajas clave sobre UUID: 1) Ordenabilidad: los ULIDs generados en el mismo milisegundo o en milisegundos consecutivos se ordenan correctamente de forma lexicográfica, lo que los hace ideales como primary keys en bases de datos que usan índices B-tree (PostgreSQL, MySQL, SQLite), evitando la fragmentación de índices que causa UUID v4. 2) Compacidad: 26 caracteres vs 36 de UUID (incluyendo guiones). 3) Legibilidad: el timestamp es decodificable a partir de los primeros caracteres. Esta herramienta genera ULIDs usando la API nativa de criptografía del navegador para la parte aleatoria.
¿Cuál es la ventaja de ULID sobre UUID v4 en bases de datos?
UUID v4 es completamente aleatorio, lo que causa un problema en bases de datos con índices B-tree (PostgreSQL, MySQL): cada nuevo UUID se inserta en una posición aleatoria del índice, causando fragmentación y degradación del rendimiento a medida que crece la tabla. ULID, al tener el timestamp como prefijo, es monotónicamente creciente (o casi): las nuevas filas se insertan casi siempre al final del índice, manteniendo el índice compacto y las operaciones de escritura rápidas. Esto puede ser una diferencia del 30-50% en rendimiento de escritura en tablas grandes.
¿Cuál es el formato de un ULID?
Un ULID tiene 26 caracteres en Crockford Base32 (0-9 y A-Z excluyendo I, L, O, U para evitar confusiones visuales): los primeros 10 caracteres son el timestamp en milisegundos (puede representar fechas hasta el año 10889), y los 16 caracteres siguientes son 80 bits de entropía aleatoria. Ejemplo: 01JXYZ0ABC1234DEFGHJKMNPQR. Son case-insensitive y no contienen guiones, lo que los hace más compactos que UUID.
¿Dos ULIDs generados en el mismo milisegundo son únicos?
Sí. Los 16 caracteres aleatorios (80 bits de entropía) garantizan que incluso múltiples ULIDs generados exactamente en el mismo milisegundo sean únicos con una probabilidad astronómicamente alta: 1 en 2^80 (≈ 1.2 × 10²⁴) de colisión por par. Para monotonicity estricta dentro del mismo milisegundo, algunas implementaciones incrementan la parte aleatoria del ULID anterior, pero esta herramienta usa entropía pura — suficiente para la inmensa mayoría de casos.
¿Los ULIDs son adecuados para uso público en URLs?
Sí. Son case-insensitive, no contienen caracteres especiales, son URL-safe sin encoding adicional y son opacos (no revelan información de negocio). Sin embargo, a diferencia de un UUID completamente aleatorio, el timestamp embebido en los primeros caracteres revela cuándo fue creado el registro — considera si esto es un problema de privacidad para tu caso.
¿ULID reemplaza completamente a UUID?
Depende del caso. ULID es superior para primary keys en bases de datos relacionales por su ordenabilidad. UUID v4 es preferible cuando necesitas máxima aleatoriedad sin información de tiempo (por privacidad), cuando las especificaciones del sistema requieren explícitamente UUID (OAuth, algunos estándares REST), o cuando usas herramientas que esperan formato UUID con guiones. Muchos sistemas modernos como Supabase y algunos ORMs están adoptando ULID o UUID v7 (que tiene timestamp similar a ULID).