"UUID vs ULID vs CUID: qual formato de ID único usar em 2026?"

Por que IDs únicos são mais complexos do que parecem

Você precisa de um identificador único para uma linha de banco de dados, um recurso de API, um token de sessão. Simples, certo? Só usar um número.

O problema com inteiros sequenciais: são previsíveis (/users/1, /users/2) — qualquer um pode enumerar seus recursos. Requerem uma autoridade central (apenas um servidor pode decidir o "próximo" número). E revelam informações de negócio (seu 1000º pedido tem ID 1000).

Então o mundo inventou IDs melhores. E continuou inventando. Aqui está o que cada um faz de verdade.

UUID (v4) — A opção segura padrão

Formato: 550e8400-e29b-41d4-a716-446655440000 Comprimento: 36 caracteres (32 hex + 4 traços) Aleatoriedade: 122 bits

UUID v4 são 122 bits aleatórios formatados de forma padrão. A probabilidade de colisão é tão astronomicamente baixa (você precisaria gerar 1 bilhão de UUIDs por segundo durante 85 anos para ter 50% de chance de colisão) que é efetivamente impossível.

O que UUID faz bem:

• Padrão universal — toda linguagem, banco de dados e framework tem suporte nativo
• Sem coordenação necessária — qualquer servidor ou cliente pode gerar um independentemente
• Não sequencial — sem ataques de enumeração

O que UUID faz mal:

• Não ordenável — UUIDs são aleatórios, não se ordenam por tempo de criação. Em um índice B-tree (como a maioria dos bancos de dados funciona), inserções aleatórias causam "page splits" — o banco reorganiza constantemente seu índice. Em escala, isso é caro.
• Grande: 36 chars como string, 16 bytes em binário
• Não é URL-friendly (contém traços)

Use UUID v4 quando: precisa de um ID padrão e amplamente suportado sem se preocupar com ordem de classificação.

UUID v7 — UUID corrigido

Formato: 018e2c4c-3d12-7f3a-91f8-3e4a5b6c7d8e Comprimento: 36 caracteres Aleatoriedade: 74 bits (com prefixo timestamp de 48 bits em milissegundos)

UUID v7 (ratificado em 2023) é UUID com um prefixo de timestamp. Os primeiros 48 bits são um timestamp Unix em milissegundos, tornando UUIDs ordenáveis por tempo de criação.

Por que importa: IDs ordenáveis = inserções sequenciais no B-tree = performance de índice de banco de dados muito melhor em escala.

Use UUID v7 quando: quer compatibilidade UUID mas precisa de IDs ordenados por tempo para performance do banco de dados.

ULID — Alternativa UUID ordenável e URL-safe

Formato: 01ARZ3NDEKTSV4RRFFQ69G5FAV Comprimento: 26 caracteres Aleatoriedade: 80 bits (com prefixo timestamp de 48 bits em milissegundos)

ULID (Universally Unique Lexicographically Sortable Identifier) resolve o problema de ordenação do UUID com um formato mais limpo. Codifica 48 bits de timestamp + 80 bits de aleatoriedade em Crockford Base32 (sem traços, sem caracteres ambíguos).

O que ULID faz bem:

• Ordenável lexicograficamente (ordena corretamente como string)
• URL-safe (sem traços ou caracteres especiais)
• 26 chars vs 36 do UUID — mais compacto
• Timestamp de precisão de milissegundo embutido

O que ULID faz mal:

• Menos universal que UUID — requer biblioteca na maioria das linguagens
• Monotonicidade: múltiplos ULIDs gerados no mesmo milissegundo podem não ordenar corretamente sem a variante monotônica

Use ULID quando: quer IDs ordenáveis que sejam compactos e URL-safe, sem precisar de compatibilidade UUID.

CUID2 — URL-safe, resistente a colisões, sem timestamp

Formato: clyg4v5l20000356ok1f5t6nb Comprimento: 24 caracteres (padrão) Aleatoriedade: alta (fingerprinting SHA-3, sem estrutura previsível)

CUID2 é projetado para contextos sensíveis à segurança. Ao contrário do ULID, deliberadamente não tem prefixo de timestamp — você não pode inferir quando um recurso foi criado pelo seu ID.

O que CUID2 faz bem:

• Mais seguro que UUID/ULID para IDs públicos (sem informação de timing)
• URL-safe
• Comprimento configurável (tradeoff entre comprimento e resistência a colisões)

O que CUID2 faz mal:

• Não ordenável (por design)
• Menos amplamente suportado que UUID
• Depende de uma biblioteca específica

Use CUID2 quando: IDs são públicos e você não quer vazar timestamps de criação (IDs de usuário, chaves de API, links curtos).

NanoID — Pequeno, rápido, personalizável

Formato: V1StGXR8_Z5jdHi6B-myT Comprimento: 21 caracteres (padrão, configurável) Alfabeto: personalizável (padrão: Base64 URL-safe)

NanoID é uma alternativa moderna e pequena ao UUID. Mesma probabilidade de colisão que UUID v4 em 21 chars, mas menor e com alfabeto personalizável.

O que NanoID faz bem:

• O mais compacto (21 chars vs 36 do UUID)
• Alfabeto personalizável — pode gerar IDs usando apenas minúsculas, apenas números, etc.
• Disponível em 20+ linguagens
• Rápido

O que NanoID faz mal:

• Não ordenável
• Não é um padrão (sem RFC)

Use NanoID quando: tamanho importa (URLs, tokens curtos) ou precisa de um alfabeto personalizado.

Tabela de decisão

A resposta simples

• Escolha padrão: UUID v7 — ordenável, padrão, ótima performance no DB
• Precisa URL-safe + ordenável: ULID
• IDs públicos (não vazar timing): CUID2
• Tokens curtos, alfabeto personalizado: NanoID
• Sistema legado / máxima compatibilidade: UUID v4

Gere IDs agora

Gerador UUID gera UUID v4 e v7 — geração em massa, copiar com um clique. Sem conta necessária.