UUID v4 vs UUID v7 vs ULID: Qual ID Único Você Deve Usar?

Os números inteiros de incremento automático foram a chave primária padrão durante décadas. São compactas e rápidas, mas exigem uma base de dados central para distribuir números, vazamento de quantos registos você tem, e fazer a fusão de dados de múltiplos sistemas doloroso. Identificadores globalmente únicos resolvem esses problemas: qualquer servidor, aplicativo móvel ou cliente offline pode criar uma ID que nunca colidirá. A questão é de que tipo. Este guia compara as três opções mais populares em 2026: UUID versão 4, UUID versão 7 e ULID.

Uma rápida atualização sobre UUIDs

Um UUID (Universally Unique Identifier) é um valor de 128 bits, geralmente escrito como 32 dígitos hexadecimais em cinco grupos:

550e8400-e29b-41d4-a716-446655440000

O padrão atual, RFC 9562 (publicado em 2024, substituindo o RFC 4122), define várias versões. Alguns bits codificam a versão e variante; o resto depende da versão. O terceiro grupo começa sempre com o número de versão, para que se possa distinguir um v4 de um v7 num olhar.

UUID v4: puramente aleatório

Um UUID de versão 4 contém 122 bits aleatórios mais 6 bits fixos para versão e variante.

** Forças **

• Trivial para gerar: cada linguagem e banco de dados tem uma função embutida, como crypto.randomUUID() no JavaScript ou gen_random_uuid() no PostgreSQL.
• Não revela nada, nem marca de tempo, nem identificador da máquina, nem sequência.
• A probabilidade de colisão é insignificante. Você precisaria gerar cerca de 2,7 × 10^18 IDs para uma chance de 50% de um duplicado único.

** Fraquezas **

• A ordem aleatória prejudica os índices da base de dados. Os índices de árvore B, usados pelo PostgreSQL, MySQL e SQL Server, funcionam melhor quando novas chaves chegam em ordem crescente. As teclas aleatórias caem por todo o índice, causando divisões de páginas, localização de cache pobre e amplificação de gravação. Em tabelas grandes, o rendimento de inserção pode cair significativamente e os índices crescerem mais do que o necessário.
• Não é classificável por tempo de criação, então você precisa de uma coluna created_at separada para consultas cronológicas.

UUID v7: em ordem de tempo

A versão 7 coloca um carimbo de tempo de 48 bits Unix em milissegundos na frente, seguido por 74 bits de aleatoriedade (algumas implementações usam parte dele como um contador para ordenar dentro do mesmo milissegundo).

01928c3e-5b7a-7c4d-9f3e-2a1b4c5d6e7f
└─timestamp─┘ └version 7

** Forças **

• As novas IDs estão a aumentar, por isso as inserções são adicionadas ao final do índice como teclas de aumento automático. Isso mantém os índices compactos e escreve rápido.
• Ordenamento por tipos de ID por tempo de criação, o que torna a paginação baseada no cursor simples: WHERE id > :last_id ORDER BY id LIMIT 50.
• Ainda é um UUID padrão: ele se encaixa em colunas nativas uuid, ORM e APIs que já aceitam UUIDs.
• Você pode extrair o tempo de criação do ID para depuração.

** Fraquezas **

• O tempo de criação é visível para quem vê a identificação. Para a maioria dos registros, isso é inofensivo; para alguns, como contas de usuário em um produto sensível à privacidade, pode revelar quando alguém se inscreveu.
• Requer um relógio razoavelmente preciso. Grandes saltos de relógio para trás podem produzir IDs que classificam mais cedo do que os existentes; boas bibliotecas lidam com isso com contadores monótonos.
• As funções de geração nativa são mais recentes. PostgreSQL 18 adicionou uuidv7(); em versões mais antigas, gerar em código de aplicativo.

ULID: texto ordenável e compacto

O ULID (Universally Unique Lexicographically Sortable Identifier) antecede o UUID v7 e usa a mesma ideia: um carimbo de tempo de 48 bits de milissegundos seguido por 80 bits aleatórios. A diferença é a forma de texto: 26 caracteres de Crockford Base32.

01J9Z3K8M2Q7X4V5B6N8P0R2T4

** Forças **

• Mais curto que a cadeia UUID de 36 caracteres e URL-safe.
• Não é sensível às maiúsculas e exclui letras ambíguas (I, L, O, U), por isso é mais fácil de ler em voz alta ou digitar.
• A classificação de cadeias lexicográficas é igual à classificação cronológica, que ajuda em sistemas que armazenam IDs como texto, como lojas de valores-chave ou nomes de arquivos de log.

** Fraquezas **

• Não é um UUID, por isso não se encaixa em tipos de coluna UUID nativos sem conversão (embora seus 128 bits possam ser armazenados em um).
• Uma especificação comunitária em vez de um padrão IETF, com um comportamento ligeiramente diferente entre bibliotecas.
• Tal como o V7, expõe o tempo da criação.

Comparação lado a lado

Imóveis	UUID v4	UUID v7	ULID
Tamanho	128 bits	128 bits	128 bits
Comprimento do texto	36	36	26
Ordenados por tempo	- Não, não.	- Sim , sim .	- Sim , sim .
Fugas de tempo de criação	- Não, não.	Sim (ms)	Sim (ms)
Padrão	RFC 9562 (em inglês)	RFC 9562 (em inglês)	Especificações comunitárias
Tipo DB nativo	uuid	uuid	Normalmente texto ou binário
Introduções favoráveis ao índice	Pobre .	Muito bem.	Muito bem.

Dicas de armazenamento

O que quer que escolhas, armazena os IDs como 16 bytes, não como texto. Uma cadeia de 36 caracteres ocupa mais do que o dobro do espaço, e cada índice e chave estrangeira referenciando multiplica o custo. O PostgreSQL tem um tipo nativo uuid; usuários do MySQL podem usar BINARY(16) com UUID_TO_BIN(uuid, 1), onde o segundo argumento reordena os carimbos de tempo v1 para v7 usam a ordem padrão, já que já está ordenada por tempo.

Expor IDs em APIs na sua forma de texto canônico. Os clientes devem tratá-los como cordas opacas e nunca analisar o significado deles.

Considerações de segurança

Nenhuma dessas identidades é segredo. Não os use como símbolos de redefinição de senha ou identificadores de sessão só porque são difíceis de adivinhar. Um UUID v4 tem aleatoriedade suficiente para não ser testável, mas v7 e ULID têm prefixos de timestamp previsíveis que reduzem a entropia efetiva. Para segredos, gere pelo menos 128 bits aleatórios com um gerador criptográfico e trate-os como senhas, idealmente armazenando apenas um hash veja MD5 vs SHA-256 para qual hash usar.

Considere também a enumeração. Os números inteiros sequenciais permitem que qualquer um adivinhe /orders/1001, /orders/1002. Os identificadores aleatórios ou ordenados por tempo tornam isso impraticável, mas não substituem os controlos de autorização em cada pedido.

O que você escolheria?

• ** Chaves primárias de banco de dados num novo sistema:** UUID v7. Você obtém geração distribuída e bom desempenho de índice com total compatibilidade UUID.
• Identificadores públicos em que o tempo de criação deve permanecer privado: UUID v4, ou uma chave interna v7 combinada com um ID público aleatório separado.
• Lojas baseadas em texto, nomes de ficheiros ou IDs as pessoas podem digitar: ULID, para a sua forma mais curta, insensible a maiúsculas e minúsculas
• ** Sistema existente em v4 com problemas de desempenho:** considere v7 para novas tabelas; misturar versões em uma coluna é tecnicamente bom porque ambos são UUIDs válidos.

Geração de identificadores

Para tarefas rápidas dados iniciais, dispositivos de teste, inserções manuais um gerador de UUID baseado em navegador pode produzir até 1.000 valores v4, v7 ou ULID de uma só vez usando crypto.getRandomValues. No código do aplicativo, use a biblioteca padrão do seu idioma ou um pacote bem mantido e gere IDs o mais próximo possível da criação de registros.

Resumo

UUID v4 é aleatório e privado mas dispersa índices de banco de dados. UUID v7 adiciona um prefixo de carimbo de tempo que mantém inserções rápidas e IDs classificáveis enquanto permanece um UUID padrão. O ULID oferece a mesma ordem com um formato de texto mais curto e amigável. Para a maioria dos novos aplicativos, o UUID v7 é o melhor padrão; alcance para v4 quando o tempo deve permanecer oculto e ULID quando humanos ou sistemas baseados em texto lidam com os IDs.