Versões de UUID Explicadas — Pare de usar a versão 4 para tudo

Algo no seu código possui uma linha que parece assim: id = uuid.v4(). Funciona. Seus testes passam. Seus usuários nunca reclamam. E seu DBA se irrita silenciosamente toda vez que olha para o plano da consulta.

O UUID v4 tornou-se o padrão porque é simples, universalmente disponível e resistente a colisões o suficiente para que você nunca realmente encontre um conflito. Mas "funciona" e "é a ferramenta certa" não são a mesma coisa — e para chaves primárias em bancos de dados, o v4 está ativamente tornando seu sistema mais lento à medida que escala.

O que o UUID v4 Faz Realmente no Seu Banco de Dados

Bancos de dados relacionais usam índices B-tree para chaves primárias. Um índice B-tree mantém os dados ordenados, permitindo que o banco de dados encontre linhas em tempo O(log n). Quando você insere uma nova linha, o banco de dados precisa colocá-la na posição correta ordenada no índice.

Com UUID v4, cada novo ID é aleatório. 550e8400-e29b-41d4-a716-446655440000 pode ser seguido por f47ac10b-58cc-4372-a567-0e02b2c3d479 — não há relação entre inserções consecutivas. O banco de dados precisa navegar até uma folha aleatória do B-tree cada vez que insere um novo registro.

Isso causa dois problemas em grande escala:

• Divisões de página: Quando uma página folha do B-tree está cheia, o banco de dados precisa dividir a página em duas e atualizar o pai. Com inserções aleatórias, as divisões ocorrem frequentemente em toda a estrutura do índice — não apenas no final.
• Falhas de cache: O pool de buffer do banco de dados mantém páginas recentemente usadas na memória. Inserções sequenciais atingem continuamente as mesmas "páginas quentes". Inserções aleatórias distribuem as leituras por toda a estrutura do índice, esvaziando o cache e forçando leituras do disco.

Em uma tabela com milhões de linhas e alto throughput de escrita, essa fragmentação do índice resulta em latência real. Se o EXPLAIN ANALYZE mostrar que as consultas de índice estão demorando mais do que deveriam, os UUIDs aleatórios podem ser parte da diagnóstico.

A Árvore de Famílias de UUID

UUID v1: Timestamps, Endereços MAC e Por Que Não Usamos

O UUID v1 foi o original "ordenável". Ele codifica um timestamp de 60 bits em intervalos de 100 nanosegundos desde 15 de outubro de 1582, combinado com uma sequência de relógio e o endereço MAC da sua máquina. O resultado é aproximadamente ordenável pelo tempo.

A parte do endereço MAC é o que matou o v1. Ele revela o identificador da interface de rede do seu servidor em cada ID gerado — em cada registro de usuário, cada pedido, cada evento. Pesquisadores de segurança demonstraram que UUIDs v1 gerados na mesma máquina são previsíveis uma vez que você tenha um exemplo. Organizações começaram a evitá-lo para qualquer coisa com interface para usuários, e a maioria das bibliotecas de UUID marca o v1 como descontinuado.

UUID v4: Aleatório, Seguro e Mal Apropriado para Chaves Primárias

O UUID v4 possui 122 bits de dados aleatórios criptográficos (os bits restantes codificam a versão). A probabilidade de colisão para bilhões de UUIDs é aproximadamente 1 em 10^18. Para fins práticos, é zero.

Essa aleatoriedade é exatamente o que você deseja para tokens de segurança, IDs de sessão, chaves de API e IDs de correlação — qualquer coisa onde você precise de um ID que não possa ser adivinhado ou enumerado. Para esses casos, continue usando o v4. O problema é que "não pode ser adivinhado" e "amigável para bancos de dados" são propriedades opostas.

Quer experimentar com a geração de UUIDs? O Gerador de UUID no IO Tools permite gerar v1, v4, v7 e outras variantes ao mesmo tempo para ver a diferença na estrutura.

UUID v7: O Novo Padrão que Você Deveria Usar

O UUID v7 foi padronizado pela IETF no RFC 9562 em maio de 2023. Ele coloca um timestamp do sistema Unix em milissegundos nos 48 bits mais significativos, seguido por um campo de versão de 4 bits, um contador de sequência de 12 bits e 62 bits de dados aleatórios.

O que isso significa na prática: os UUIDs gerados posteriormente são lexicograficamente maiores. Inserções consecutivas ocupam posições adjacentes no B-tree. Sem dispersão aleatória, sem divisões desnecessárias de página, sem sobrecarga do cache. Ele se comporta como um inteiro auto-incremento do banco de dados — enquanto ainda é globalmente único sem necessidade de coordenação.

O contador de sequência dentro do mesmo milissegundo garante uma ordem monotônica mesmo para geradores de alta frequência. Se você gerar 10.000 UUIDs em um milissegundo, eles ainda serão ordenados corretamente. O sufixo aleatório preserva uma quantidade suficiente de entropia para que as colisões entre sistemas distribuídos permaneçam extremamente improváveis.

Para qualquer novo sistema usando PostgreSQL, MySQL ou outro banco de dados relacional, o UUID v7 deve ser o padrão para chaves primárias.

ULID: A Alternativa que Veio Primeiro

O ULID (Universally Unique Lexicographically Sortable Identifier) estava resolvendo o mesmo problema antes do UUID v7 existir. Ele usa 48 bits para o timestamp do sistema Unix em milissegundos e 80 bits de dados aleatórios, codificados em Crockford's Base32.

O resultado é uma string de 26 caracteres que parece 01ARZ3NDEKTSV4RRFFQ69G5FAV em vez do formato padrão de 36 caracteres com hífen. É seguro para URLs sem codificação, ordena corretamente como string e é insensível a maiúsculas e minúsculas.

O ULID não possui um RFC da IETF — possui um especificação da comunidade no ulid.github.io. Isso é suficiente para a maioria das equipes, mas se você estiver em um ambiente regulado que exige identificadores formalmente padronizados, o UUID v7 é a escolha mais segura. O ULID possui forte suporte em bibliotecas no ecossistema JavaScript e Go, e se sua equipe já o estiver usando, não há motivo urgente para mudar.

Comparação lado a lado

Propriedade	UUID v1	UUID versão 4	UUID v7	ULID
Ordenável	Parcialmente	Não	Sim	Sim
Resistente a colisões	Sim	Sim	Sim	Sim
Amigável para bancos de dados	Parcialmente	Não	Sim	Sim
Seguro em termos de privacidade	Não (endereço MAC)	Sim	Sim	Sim
Corpo padronizado	RFC 4122 da IETF	RFC 4122 da IETF	RFC 9562 da IETF	Especificação da comunidade
Comprimento típico	36 caracteres	36 caracteres	36 caracteres	26 caracteres
Fonte de entropia	Endereço MAC + relógio	Aleatório	Timestamp + aleatório	Timestamp + aleatório

Quando Usar Cada Um

UUID v7 — use isso para chaves primárias em qualquer novo sistema. É um padrão da IETF, tem suporte crescente em bibliotecas (native em PostgreSQL 17, disponível via bibliotecas em todas as principais linguagens) e oferece ordenação amigável para B-tree sem necessidade de coordenação.

UUID versão 4 — continue usando isso para qualquer coisa com segurança sensível onde a aleatoriedade importa: tokens de sessão, tokens de redefinição de senha, chaves de API, parâmetros de estado do OAuth, IDs de correlação nos logs. A imprevisibilidade é uma característica aqui, não um defeito.

ULID — use-o se sua equipe já está usando, especialmente em projetos em JavaScript ou Go. O formato mais curto é realmente mais agradável em URLs e logs. Se você estiver começando do zero, o UUID v7 é a aposta mais segura a longo prazo simplesmente porque tem apoio da IETF.

UUID v1 — não. Não há cenário em que o v1 seja a escolha certa para código novo.

Considerações sobre a Migração

Se você está rodando um sistema existente com chaves primárias de UUID v4, você não precisa migrar imediatamente — e não deve fazer isso casualmente. As relações de chaves estrangeiras, o código da aplicação e valores potencialmente armazenados em cache referenciam esses IDs. Uma migração exige planejamento cuidadoso e, provavelmente, uma janela de manutenção.

Para a maioria das equipes, a abordagem pragmática é: use UUID v7 (ou ULID) para todas as tabelas e serviços novos. Aceite que suas tabelas antigas tenham v4 e gerencie a fragmentação com recriações periódicas do índice se o impacto de desempenho for mensurável. Não deixe o perfeito ser inimigo do bom.

Se você está em um projeto verdefield — novo projeto, novo banco de dados, novas tabelas — não há motivo para usar v4 para chaves primárias. As ferramentas estão disponíveis. Gerar alguns exemplos de UUID v7 e ver o que você está lidando.

A Mensagem Final

O UUID v4 não está errado — é apenas frequentemente mal aplicado. Sua aleatoriedade é uma propriedade de segurança, e deve ser preservada onde a segurança importa. Para chaves primárias em bancos de dados, essa aleatoriedade se torna uma carga de desempenho à medida que escala.

O UUID v7 resolve o problema de forma clara: aumenta monotonicamente, é globalmente único, padronizado e já é suportado pelos bancos de dados e ORMs que você está usando. Se você estiver escrevendo esquemas de banco de dados hoje, faça v7 o padrão. O futuro-você — e seu DBA — notarão a diferença.

Você também pode gostar