Anúncios incomodam? Ir Sem anúncios Hoje 

UUID versus ULID versus CUID Qual ID Único Você Deveria Usar?

Publicado em Abr 19, 2026

UUID versus ULID versus CUID: Qual ID único você deve usar? 1

Cada linha do banco de dados, cada recurso da API, cada evento distribuído precisa de um ID. O problema não é gerar um ID — é escolher o formato que não te puxe no sexto mês quando seus índices do Postgres estiverem fragmentados e seus URLs parecerem ruído.

Aqui está o completo comparação do gerador de UUID: UUID v4, UUID v7, ULID, CUID2 e Snowflake — o que são, onde falham e qual é realmente o que você deve usar.

UUID v4: O padrão seguro (com um grande problema)

UUID v4 tem 128 bits de aleatoriedade, formatado como 550e8400-e29b-41d4-a716-446655440000. É amplamente compreendido, suportado em todas as linguagens, todos os bancos de dados e todas as ORM do planeta.

A probabilidade de colisão é praticamente zero — você precisaria gerar um bilhão de UUIDs por segundo durante 85 anos para atingir uma chance de 50% de uma única colisão. Isso não é uma preocupação na prática.

O problema é a ordem. O UUID v4 é completamente aleatório, o que significa que ao inserir linhas em uma tabela indexada por UUID, os escritos são espalhados ao longo da árvore B. Em escala, isso causa divisões de páginas, fragmentação de índices e desempenho reduzido em inserções. Se você estiver inserindo milhares de linhas por segundo em uma tabela do MySQL ou Postgres com chave primária UUID, sentirá isso.

O UUID v4 também tem 36 caracteres como string — não é seguro para URLs sem codificação e é mais pesado em comparação com alternativas.

UUID v7: O irmão melhor do UUID v4

O UUID v7 corrige o problema de ordem. É um UUID ordenado pelo tempo, onde os bits mais significativos codificam um timestamp em milissegundos e o restante é aleatório. O resultado: 01875f3a-7b2d-7f8e-a3d1-4b2e6c1a0f93.

As linhas inseridas em ordem temporal permanecem aproximadamente sequenciais no índice. Isso é um grande ganho para cargas de escrita. O UUID v7 é compatível com toda a infraestrutura existente de UUIDs — mesmo formato, mesmo comprimento de campo, mesmas expectativas de suporte de bibliotecas — enquanto adiciona ordenabilidade.

O RFC foi finalizado em 2022 e o suporte das bibliotecas está se tornando rápido. Se você já está usando UUIDs e não pode mudar o esquema, migrar do v4 para o v7 é de baixo risco e alto retorno.

ULID: A opção mais amigável para desenvolvedores

O ULID (Universally Unique Lexicographically Sortable Identifier) codifica um timestamp de 48 bits e 80 bits de aleatoriedade em 26 caracteres base32: 01ARZ3NDEKTSV4RRFFQ69G5FAV.

O que o diferencia:

é ordenável por padrão — a ordenação lexicográfica é a ordenação cronológica
é seguro para URLs — sem hífens, sem caracteres especiais
Não diferencia maiúsculas de minúsculas — evita a 0/O e 1/I ambiguidade ao excluir esses caracteres do alfabeto
Compacto — 26 caracteres em vez de 36 para uma string de UUID

O ULID é a escolha mais prática para novos projetos que não têm restrições legadas. É ordenável o suficiente para a maioria dos casos, curto o suficiente para URLs e legível o suficiente para que um humano possa copiar e colar sem erros de transcrição.

Uma advertência: se você gerar múltiplos ULIDs no mesmo milissegundo, a ordem monotônica é garantida dentro do processo, mas não entre nós distribuídos. Para a maioria dos aplicativos, isso está bem.

CUID2: Feito para sistemas distribuídos

O CUID2 é o sucessor do CUID, redimensionado do zero para segurança e resistência a colisões em ambientes distribuídos. Um CUID2 parece assim: clh3uj5ln0000qzrmn831mbhe.

Ele usa um hash SHA-3 de uma combinação de timestamp, contador, impressão (ID do processo + nome da máquina) e bytes aleatórios. A impressão é a diferença principal — foi projetada especificamente para prevenir colisões quando você está executando muitos geradores de IDs simultaneamente em muitas máquinas.

O CUID2 é não ordenável. Ele prioriza resistência a colisões e imprevisibilidade em vez de ordenação temporal. Se você estiver construindo um sistema onde os IDs são gerados por clientes não confiáveis ou em um grande número de nós independentes e segurança é uma preocupação, o CUID2 vale a pena o custo.

Para a maioria dos APIs de backend, é excessivo.

IDs Snowflake: Alta taxa de throughput, mas você está sozinho

Os IDs Snowflake foram inventados no Twitter para gerar IDs únicos em milhões por segundo em um cluster distribuído. Um ID Snowflake é um inteiro de 64 bits: timestamp (41 bits) + ID do datacenter (5 bits) + ID da máquina (5 bits) + sequência (12 bits).

Eles são ordenáveis, compactos (ficam em um BIGINT) e extremamente rápidos. Discord, Instagram e muitos sistemas de alto volume os usam.

A questão: você precisa gerenciar os IDs da máquina. Isso significa um serviço de coordenação (ZooKeeper, etcd, uma tabela de banco de dados) para atribuir IDs únicos a cada gerador de IDs. Se dois nós compartilharem um ID da máquina, você terá colisões. Configurar isso corretamente é complexo e manter isso é uma sobrecarga operacional.

A menos que você esteja gerando centenas de milhares de IDs por segundo, a complexidade não vale a pena.

A comparação

	UUID versão 4	UUID v7	ULID	CUID2	Snowflake
Ordenável	Não	Sim	Sim	Não	Sim
é seguro para URLs	Não (hífens)	Não (hífens)	Sim	Sim	Sim (inteiro)
Resistência à colisão	Muito alto	Muito alto	Alto	Muito alto	Alto (com coordenação)
Complexidade	Nenhum	Nenhum	Nenhum	Baixo	Alto
Caso típico de uso	Sistemas legados, uso geral	Chaves primárias do banco de dados	APIs, URLs, projetos novos	Clientes ou nós distribuídos não confiáveis	Sistemas de alta taxa de throughput

Gerar cada um em Node.js

// 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'

Você pode testar a geração de UUID diretamente com o IO Tools UUID Generator — ele suporta UUID v1 até v7 e geração em massa sem precisar instalar nada.

Qual deles você deve usar?

Aqui está a recomendação real, não a "depende" copiada:

Projeto novo, sem restrições legadas: Use o ULID. Ordenável, seguro para URLs, compacto. É a melhor escolha padrão.
Já está usando UUIDs, precisa de melhor desempenho no banco de dados: Migrar para UUID v7. Atualização de inserção, grande ganho no índice.
IDs gerados por clientes ou em nós distribuídos não confiáveis: Use o CUID2. A impressão garante resistência a colisões mesmo em condições adversas.
Plataforma de alta taxa de throughput (100k+ IDs/s), disposto a gerenciar IDs da máquina: Use o Snowflake. Caso contrário, não se preocupe.
UUID v4: Apenas se você estiver mantendo código legado e não puder mudar o formato. Pare de usá-lo em tabelas novas.

A era de defaultar para UUID v4 para tudo está acabada. O ULID é a nova escolha padrão para a maioria dos casos, e o UUID v7 é a rota correta de atualização se você já estiver no mundo dos UUIDs. Escolha um e continue.