UUIDs são a primeira ferramenta à qual a maioria dos desenvolvedores backend recorre quando precisa de um identificador único que não dependa de uma sequência de banco. Vêm embutidos na maioria das linguagens, ficam bem numa URL e funcionam sem coordenação entre serviços. Mas a especificação define várias versões com compromissos diferentes, e escolher a certa importa em sistemas grandes.

O que é um UUID

Um UUID (Universally Unique Identifier, também chamado GUID no Windows) é um valor de 128 bits, normalmente escrito como 32 dígitos hex em grupos 8-4-4-4-12. Os quatro caracteres hex nas posições 13–16 codificam a versão (1 a 7); o primeiro caractere do grupo 17–20 codifica a variante. O resto é dado cujo significado depende da versão.

Versão 1: tempo e MAC

v1 codifica o timestamp atual (intervalos de 100 ns desde 15 de outubro de 1582) mais o MAC do host mais uma sequência de relógio. Único garantido sem coordenação — mas vaza quando e onde cada ID foi gerado, geralmente indesejável. Muitos bancos corporativos ainda produzem por hábito.

Versão 4: puramente aleatório

v4 preenche 122 dos 128 bits com dados de um RNG criptográfico. Os outros 6 bits ficam fixos para identificá-lo como v4. É o padrão em sistemas modernos porque não revela nada, é simples de gerar (uma linha se crypto.randomUUID estiver disponível) e tem probabilidade de colisão pequena o bastante para não importar na prática.

Versão 7: ordenada pelo tempo

v7 é mais recente (RFC 9562, publicada em 2024). Começa com um timestamp em milissegundos e preenche o resto com aleatoriedade. O resultado é monotonamente ordenável — útil como chave primária de banco porque v4 fragmenta muito o índice, enquanto v7 mantém inserts agrupados. Se sua biblioteca suporta, prefira v7 a v4 para chaves primárias; use v4 só quando precisa esconder a hora de criação.

Probabilidade de colisão

Para v4, o espaço é 2^122 — cerca de 5 × 10^36. Gerar um bilhão de UUIDs por segundo por 85 anos ainda dá probabilidade desprezível de colisão. Na prática, colisões em v4 vêm de RNGs ruins, não do esgotamento do espaço. Use sempre crypto.randomUUID ou crypto.getRandomValues, nunca Math.random.

UUID vs auto-increment

IDs auto-increment são menores (8 bytes vs 16), naturalmente ordenados e rápidos de indexar — mas vazam dados de negócio ("quantos pedidos essa empresa processa por dia"), exigem coordenação em sistemas distribuídos e tornam merges entre bancos dolorosos. UUIDs são o oposto: opacos, sem coordenação, grandes. Use auto-increment para tabelas internas onde nenhum ID sai do banco. Use UUIDs para qualquer coisa visível ao usuário ou trocada entre serviços.

Notas de armazenamento

Sempre armazene UUIDs como tipo binário nativo se o banco suportar (UUID no Postgres, BINARY(16) no MySQL). Armazenar como VARCHAR(36) dobra o espaço e deixa cada lookup de índice 2–3x mais lento. A forma hex com hífens é só para exibir.