Por que usar Math.random() para gerar UUID é uma prática ruim, mesmo produzindo o formato correto?

Porque Math.random() não é uma fonte de aleatoriedade criptograficamente segura — é gerada por um algoritmo determinístico e previsível sob certas condições. A garantia matemática de baixíssima probabilidade de colisão de um UUID v4 depende dos 122 bits serem verdadeiramente imprevisíveis, o que só crypto.randomUUID() (baseado em CSPRNG do sistema) garante.

Quantos UUIDs v4 seriam necessários para ter risco real de colisão?

Cerca de 2,71 quintilhões (2,71 × 10^18) para atingir 50% de probabilidade de uma única colisão, considerando o paradoxo do aniversário aplicado a um espaço de 2^122 valores possíveis — um volume que nenhum sistema prático se aproxima de gerar.

UUID aleatório (v4) é sempre a melhor escolha de chave primária de banco de dados?

Não necessariamente. Por ser totalmente aleatório, UUID v4 insere em posições dispersas de um índice B-tree, causando mais fragmentação do que uma chave sequencial. Para sistemas que precisam de geração distribuída sem coordenação central mas também de boa performance de indexação, variantes como UUID v7 (com componente de timestamp ordenável) costumam ser preferíveis.

Gerador de UUID/GUID Online

Gerador de UUID/GUID

Gere identificadores únicos universais (UUID v4), usando a fonte de aleatoriedade segura do seu navegador.

Quantidade (lote)

Formato

Sem hífens

UUID v4 (aleatório), gerado com crypto.randomUUID() — a mesma fonte segura usada por navegadores modernos, sem enviar nada ao servidor.

Documentação técnica

Gerador de UUID: 122 bits de aleatoriedade e a matemática da colisão

Um UUID v4 (a versão gerada por este site, e a mais comum em sistemas modernos) é definido pela RFC 4122: 128 bits total, dos quais 6 bits são fixos por especificação (4 bits identificam a versão, 2 bits identificam a variante), sobrando exatamente 122 bits de aleatoriedade real. É essa quantidade de entropia — não o formato com hífens em si — que torna colisão (dois UUIDs v4 gerados independentemente sendo iguais) praticamente impossível: seriam necessários cerca de 2,71 quintilhões de UUIDs gerados para atingir 50% de probabilidade de uma única colisão (o "paradoxo do aniversário" aplicado a um espaço de 2^122 valores possíveis).

Por que crypto.randomUUID() importa especificamente aqui

Este gerador usa crypto.randomUUID(), a API nativa do navegador introduzida especificamente para isso — não uma implementação manual que monta 128 bits a partir de Math.random(). Essa distinção importa porque Math.random() não é uma fonte de aleatoriedade criptograficamente segura (é determinística e previsível o suficiente para ser reconstruída em certos cenários), o que compromete a garantia matemática de baixa colisão que só se sustenta se os 122 bits forem, de fato, imprevisíveis. crypto.randomUUID() usa a mesma fonte CSPRNG do sistema operacional que protege geração de chaves criptográficas — a garantia de aleatoriedade é real, não aproximada.

Uso como chave primária: vantagem e trade-off real

UUID como chave primária de banco de dados resolve um problema real de sistemas distribuídos: gerar IDs únicos em múltiplos servidores/serviços sem coordenação central (diferente de um AUTO_INCREMENT, que exige uma única fonte de verdade sequencial). O trade-off é indexação: UUIDs v4 são aleatórios por construção, o que significa inserção em posições dispersas de um índice B-tree, gerando mais fragmentação de página do que uma chave sequencial — é por isso que existem variantes como UUID v7 (com componente de timestamp ordenável), pensadas especificamente para mitigar esse custo de indexação mantendo geração distribuída.