Primary keys para sistemas distribuídos quando você não quer fazer round-trip ao banco só para pegar um ID. Idempotency keys para requisições de API (Stripe, processadores de pagamento, mensagens de fila). Identificadores de upload de arquivo, session tokens, correlation IDs em logs. Em qualquer lugar onde você expõe um ID auto-incrementado e acaba vazando quantos registros tem. Dados de teste — semeie cem registros com identificadores realistas com um clique.

UUIDs não são segredos. v4 tem 122 bits de entropia e é impossível de adivinhar, mas o formato em si não autoriza nada. Não use um UUID como session token ou token de reset de senha a menos que esteja tratando como segredo (HTTPS-only, com tempo limitado, single-use). v7 vaza tempo de criação. Os primeiros 48 bits codificam o milissegundo em que foi gerado. Tudo bem para IDs internos; ruim se você não quer que usuários descubram quando os registros foram criados. Use v4 nesse caso. Tamanho do índice importa. Um UUID tem 16 bytes vs 8 de um bigint — seus índices B-tree ficam maiores. Vale a pena para distribuído/sem coordenação, geralmente não vale para apps de servidor único com ID sequencial. v4 fragmenta índices de banco. IDs aleatórios espalham writes pelo índice, prejudicando a taxa de hit do cache de páginas e a vazão de escrita. Esse é o argumento original a favor do v7. Não use v1. A variante antiga de tempo-e-MAC vaza o endereço MAC da máquina geradora. v7 é o substituto moderno. Use aleatoriedade crypto-segura. Esta ferramenta usa crypto.getRandomValues ; nunca implemente sua própria solução com Math.random — não é aleatório o suficiente e os IDs ficam previsíveis.

Gerador de UUID

Gere UUIDs RFC 4122 (v4 aleatório ou v7 ordenado por tempo). Em lote de até 100. Criptograficamente seguro.

Version

Quantidade (1-100)

Saída

Para que serve?

Um UUID (ou GUID) é um identificador de 128 bits — escrito como 32 dígitos hex em 5 grupos, tipo 550e8400-e29b-41d4-a716-446655440000. Eles são livres de colisão entre sistemas sem precisar de coordenação: qualquer processo em qualquer lugar pode gerar um e a chance de dois colidirem é praticamente zero. Útil quando você precisa de um ID antes de falar com o banco, quando quer evitar vazar contagem de linhas, ou quando o ID tem que ser gerado no cliente e sincronizado depois. Esta ferramenta gera UUIDs em conformidade com RFC 4122 / RFC 9562 na forma v4 (aleatória) ou v7 (ordenada por tempo), com aleatoriedade criptograficamente segura no seu navegador.

Quando usar

Primary keys para sistemas distribuídos quando você não quer fazer round-trip ao banco só para pegar um ID.
Idempotency keys para requisições de API (Stripe, processadores de pagamento, mensagens de fila).
Identificadores de upload de arquivo, session tokens, correlation IDs em logs.
Em qualquer lugar onde você expõe um ID auto-incrementado e acaba vazando quantos registros tem.
Dados de teste — semeie cem registros com identificadores realistas com um clique.

v4 vs v7 — qual usar?

v4 (aleatório) — 122 bits de aleatoriedade, sem timestamp embutido. Use quando quiser zero correlação entre IDs e ordem de criação, ou quando o ID vai viver em um hash map / índice não-clusterizado onde ordenação não importa.
v7 (ordenado por tempo) — prefixo de timestamp Unix-ms de 48 bits + cauda aleatória. Use por padrão para novas primary keys de banco. O prefixo de timestamp dá localidade aos índices B-tree (inserts recentes vão para as mesmas páginas, comportamento de cache muito melhor que v4), e os IDs ordenam aproximadamente em ordem cronológica. Definido na RFC 9562 (maio de 2024) — substitui ULID e v1/v6 na maioria dos casos.

Cuidados comuns

UUIDs não são segredos. v4 tem 122 bits de entropia e é impossível de adivinhar, mas o formato em si não autoriza nada. Não use um UUID como session token ou token de reset de senha a menos que esteja tratando como segredo (HTTPS-only, com tempo limitado, single-use).
v7 vaza tempo de criação. Os primeiros 48 bits codificam o milissegundo em que foi gerado. Tudo bem para IDs internos; ruim se você não quer que usuários descubram quando os registros foram criados. Use v4 nesse caso.
Tamanho do índice importa. Um UUID tem 16 bytes vs 8 de um bigint — seus índices B-tree ficam maiores. Vale a pena para distribuído/sem coordenação, geralmente não vale para apps de servidor único com ID sequencial.
v4 fragmenta índices de banco. IDs aleatórios espalham writes pelo índice, prejudicando a taxa de hit do cache de páginas e a vazão de escrita. Esse é o argumento original a favor do v7.
Não use v1. A variante antiga de tempo-e-MAC vaza o endereço MAC da máquina geradora. v7 é o substituto moderno.
Use aleatoriedade crypto-segura. Esta ferramenta usa crypto.getRandomValues; nunca implemente sua própria solução com Math.random — não é aleatório o suficiente e os IDs ficam previsíveis.