Versões de UUID

Anatomia: 128 bits em 36 caracteres

Um UUID tem 128 bits, escritos canonicamente como 32 dígitos hexadecimais minúsculos em cinco grupos separados por hífens no padrão 8-4-4-4-12 — 36 caracteres com os hífens, 32 sem. O layout não é decoração: faixas de bits específicas carregam significado. O campo de versão de quatro bits ocupa o nibble superior do terceiro grupo, e a variante de dois bits — que distingue UUIDs no estilo RFC de layouts mais antigos da Microsoft e legados — ocupa os bits superiores do quarto grupo, sempre lendo 8, 9, a ou b em hexadecimal.

v1  614e4000-26bc-11ef-b17d-0242ac120002
v4  f7b17bde-5a0c-4174-8c95-407558615543
v6  1ec9414c-232a-6b00-b3c8-9e6bdeced846
v7  019b76da-a800-7c3e-8f2a-5b6c7d8e9f0a

3rd group, 1st hex digit = version (1, 4, 6, 7 here)
4th group, 1st hex digit = variant (b, 8, b, 8 here)

v1 e v6: um relógio e um endereço MAC

O v1 constrói o identificador a partir de um timestamp de 60 bits que conta intervalos de 100 nanossegundos desde 15 de outubro de 1582 — o início do calendário gregoriano — mais um contador de sequência de relógio e o endereço MAC de 48 bits da máquina. O timestamp é dividido de forma nada óbvia em time_low, time_mid, time_high, uma ordem de campos escolhida por uma conveniência de empacotamento de bits dos anos 1990 e depois lamentada. O endereço MAC é a mina terrestre da privacidade: todo UUID v1 revela qual hardware o criou, e é por isso que a RFC 4122 já permitia substituí-lo por um nó multicast aleatório.

O v6 é o v1 com a ordem dos campos corrigida: os bits de timestamp mais significativos vão para a frente, de modo que UUIDs v6 se ordenem cronologicamente quando ordenados como strings. Mesmo relógio, mesmo campo de nó, mesmas ressalvas de privacidade — mas um comportamento de banco de dados muito melhor, que é exatamente o objetivo da reordenação.

v1:  614e4000-26bc-11ef-b17d-0242ac120002
v6:  1ec9414c-232a-6b00-b3c8-9e6bdeced846

v6 — o campo timeHigh vem primeiro, então a ordem
lexicográfica é a ordem cronológica. v1 começa pelos
bits menos significativos e se dispersa.

v3 e v5: identidade a partir de um nome

O v3 e o v5 derivam o identificador de um UUID de namespace e de um nome, com hash MD5 (v3) ou SHA-1 (v5). Mesmo namespace, mesmo nome, mesmo UUID — em qualquer máquina, para sempre. Esse determinismo é a funcionalidade: derive identificadores estáveis de URLs, nomes de usuário ou nomes de domínio sem armazenar uma tabela de mapeamento, e regenere-os quando quiser, em qualquer sistema.

O custo é o outro lado do determinismo: o identificador vaza informação sobre o nome. Um v5 de um nome de baixa entropia pode ser confirmado por simples adivinhação, e nomes idênticos produzem identificadores idênticos de propósito. O v5 substitui o v3 — SHA-1 em vez de MD5 — e, embora a RFC 9562 não nomeie nenhuma versão nova baseada em nome, novos designs que querem determinismo e ordenação temporal ao mesmo tempo costumam migrar para o v7, armazenando o nome ao lado.

namespace: DNS   6ba7b810-9dad-11d1-80b4-00c04fd430c8
name:      python.org

v3  6fa459ea-ee8a-3ca4-894e-db77e160355e
v5  886313e1-3b8a-5372-9b90-0c9aee199e5d

hash(namespace bytes || "python.org") com a versão
(3 ou 5) e a variante (binário 10) gravadas em posições
de bits fixas — o mesmo cálculo, bit a bit.

v4: 122 bits aleatórios e o que isso compra

O v4 define 122 bits a partir de um gerador aleatório criptograficamente seguro; só os nibbles de versão e variante são fixos. As chances de colisão seguem o limite do aniversário: após gerar n valores, a probabilidade de qualquer duplicata é de aproximadamente n²/2¹²³. Você precisaria de cerca de 2^61 UUIDs — uns 2,3 quintilhões — para haver uma chance de cara ou coroa de uma única colisão. Quando duplicatas aparecem na prática, a causa é quase sempre aleatoriedade quebrada — uma semente fraca, estado de PRNG reutilizado, uma falha de hardware — jamais as próprias probabilidades.

A aleatoriedade também é a fraqueza do v4 como chave de banco de dados: valores completamente fora de ordem caem em páginas aleatórias da B-tree, fragmentando índices e esgotando caches de escrita em escala. Essa reclamação é precisamente o que o v6 e o v7 foram padronizados para resolver, e o motivo pelo qual muitos ORMs e bancos de dados distribuídos hoje direcionam tabelas novas para o v7.

v7: milissegundos Unix mais aleatoriedade

O v7 é o candidato a padrão moderno: 48 bits de timestamp Unix em milissegundos e, depois, 12 mais 62 bits de carga aleatória. O timestamp na frente torna os UUIDs v7 ordenáveis como strings — amigáveis a índices justamente nos bancos de dados que os armazenam — enquanto os 74 bits aleatórios mantêm as chances de colisão efetivamente no nível do v4. Ele não precisa de endereço MAC, de época 1582 nem de conversões de calendário.

Dentro do mesmo milissegundo, a RFC 9562 descreve um contador monótono no campo rand_a, para que identificadores criados em rápida sucessão continuem aumentando — uma propriedade com a qual chaves primárias se importam ainda mais do que com unicidade bruta. O timestamp também é legível: ele se lê como 2026, não como uma contagem de tiques de 100 nanossegundos desde 1582, o que torna o v7 agradável de bater o olho em logs e resultados de consulta.

2026-01-01T00:00:00Z  019b76da-a800-7c3e-8f2a-5b6c7d8e9f0a
2026-01-01T00:00:01Z  019b76da-abe8-9d41-8c2f-4a5b6c7d8e9f

019b76da-a800-… < 019b76da-abe8-…

a ordem lexicográfica acompanha a cronologia,
e os 48 bits superiores são um timestamp Unix em ms.

Escolhendo uma versão, com honestidade

Para trabalhos novos: v7 quando os identificadores devem se ordenar por tempo ou viver em um índice de banco de dados; v4 nos demais casos — ambos não precisam de coordenação e não vazam nada sobre sua origem. O v5 justifica sua existência quando o identificador precisa ser reproduzível a partir de um nome. O v1 e o v6 continuam suportados, mas vazam identidade de hardware a menos que o gerador randomize o campo de nó; e o v3 é o legado MD5 levado adiante por compatibilidade. Nenhuma versão é secreta, e nenhuma anonimiza dados: um UUID é um nome, não uma credencial.