ULID Generator

Depende do caso de uso. O ULID tem uma grande vantagem sobre o UUID v4: ele é ordenável lexicograficamente. Como os primeiros 48 bits codificam o timestamp de criação, ULIDs gerados próximos um do outro se ordenam próximos em qualquer índice B-tree. Isso significa que cargas de trabalho com muitas inserções em bancos de dados como PostgreSQL ou MySQL apresentam menos fragmentação de índice e melhor desempenho em consultas de intervalo. Se ordem de classificação e decodificação de timestamp são importantes, ULID é a melhor escolha. Se você precisa apenas de unicidade global sem se preocupar com ordenação, UUID v4 é mais simples e mais universalmente suportado.

O sufixo aleatório de 80 bits é gerado com a Web Crypto API (crypto.getRandomValues), que fornece valores pseudo-aleatórios criptograficamente seguros. Isso torna computacionalmente inviável prever ou enumerar futuros ULIDs a partir de ULIDs observados. No entanto, ULIDs não são tokens secretos — o prefixo de timestamp é intencionalmente visível. Nunca use um ULID sozinho como token bearer secreto; combine-o com um mecanismo de autenticação separado.

Sim. Os primeiros 10 caracteres de um ULID codificam o timestamp Unix em milissegundos usando Crockford Base32. Para decodificar: trate cada caractere como seu valor Base32 (0–31), concatene os valores em um inteiro de 48 bits e converta para uma data. Este gerador exibe o timestamp decodificado ao lado de cada ULID gerado.

Sem o modo monotônico, ambos os ULIDs recebem sufixos aleatórios de 80 bits independentes. Há uma probabilidade minúscula (cerca de 1 em 2^80) de serem idênticos ou se ordenarem na ordem errada. Com o modo monotônico ativado, o gerador lembra a última parte aleatória e a incrementa em 1 para cada ID subsequente dentro do mesmo milissegundo. Isso garante ordem de classificação estrita mesmo em altas taxas de geração, ao custo de tornar o sufixo ligeiramente menos aleatório.

A probabilidade de colisão entre dois ULIDs gerados independentemente é astronomicamente pequena. A seção aleatória comporta 2^80 ≈ 1,2 × 10^24 valores possíveis. Mesmo gerando 1 milhão de ULIDs por segundo durante um ano inteiro, a probabilidade de colisão pelo paradoxo do aniversário ficaria abaixo de 1 em 10^12. Na prática, colisões de ULID não são uma preocupação para nenhuma carga de trabalho realista.

UUID v7 (RFC 9562, finalizado em 2024) e ULID resolvem o mesmo problema — IDs únicos ordenados por tempo — mas o UUID v7 agora é um padrão IETF com suporte nativo crescente em bancos de dados (PostgreSQL 17 entende UUID v7 nativamente). ULID existe há mais tempo e tem mais implementações de bibliotecas em mais linguagens atualmente. UUID v7 tem uma seção aleatória ligeiramente menor (74 bits vs 80 bits), usa hex hifenizado em vez de Crockford Base32, e armazena mais eficientemente em colunas de banco de dados tipadas como UUID. Se você está iniciando um novo projeto em 2024+, vale a pena avaliar UUID v7; se tem infraestrutura ULID existente ou precisa da seção aleatória de 80 bits, fique com ULID.