Gerador de UUID v7

Gere valores UUID v7 online: UUIDs ordenáveis por tempo com carimbo de data/hora de 48 bits em milissegundos e 74 bits aleatórios.

Formato
IDs gerados
Pronto. Gere valores UUID v7 diretamente no seu navegador.

Como este ID é estruturado

Estrutura
Carimbo de data/hora Unix de 48 bits em milissegundos, bits de versão 7, bits de variante RFC e preenchimento aleatório.
Entropia
74 bits aleatórios nesta implementação; não há contador monotônico.
Tempo
Sim. Os primeiros 48 bits codificam o momento de criação, permitindo ordenar os IDs cronologicamente entre milissegundos diferentes.
Risco de colisão
Dentro do mesmo milissegundo, a prevenção de colisões depende de 74 bits aleatórios; volumes extremamente altos no mesmo milissegundo devem usar um serviço de IDs coordenado.
Exemplo
01a044bc-5f66-765b-bd41-3ce022c9646a

Seus IDs são gerados localmente com alta aleatoriedade no navegador. Nada é enviado para o BroBroGo.

Perguntas frequentes

Por que escolher o UUID v7 em vez do UUID v4?

O UUID v7 mantém o formato clássico do UUID, mas permite ordenação temporal, ajudando a manter logs, índices de banco de dados e fluxos de eventos em ordem cronológica aproximada.

O UUID v7 oculta a data de criação?

Não. O carimbo de data/hora faz parte da estrutura do ID. Use o UUID v4 ou o NanoID se precisar de um identificador opaco sem informações de tempo.

O que é o UUID v7 e por que ele foi criado

O UUID v7 é um identificador universal de 128 bits representado como uma string de 36 caracteres no formato xxxxxxxx-xxxx-7xxx-yxxx-xxxxxxxxxxxx, onde os primeiros 48 bits correspondem a um timestamp Unix em milissegundos, seguidos por bits aleatórios. Essa estrutura resolve um dos problemas mais incômodos do UUID v4: a falta de ordenação temporal. Enquanto o UUID v4 é completamente aleatório — o que fragmenta índices de banco de dados baseados em B-tree —, o UUID v7 coloca a data de criação no início do identificador. Com isso, registros criados sequencialmente tendem a aparecer próximos no índice, melhorando a performance de inserção e consulta em bancos relacionais e NoSQL.

Historicamente, a IETF padronizou os UUIDs na RFC 4122 (2005), que definiu as versões 1 a 5. O v7 é uma proposta mais recente (atualmente um draft, mas já amplamente adotada) que combina a vantagem temporal do UUID v1 — que usava timestamp + endereço MAC — com a imprevisibilidade do v4. O formato v7 não expõe informações do hardware nem da máquina, pois a parte aleatória substitui o endereço MAC, mantendo a privacidade do gerador. A timestamp é contada a partir de 1º de janeiro de 1970 (Unix epoch), em milissegundos, o que dá cerca de 9.000 anos de margem antes de ocorrer overflow.

Como o gerador de UUID v7 do BroBroGo funciona

A página oferece um formulário minimalista: um campo para definir a quantidade de UUIDs (entre 1 e 100, inclusive), dois interruptores (maiúsculas/minúsculas e hífens) e um botão de ação implícita — qualquer alteração em qualquer opção regenera imediatamente toda a lista. O usuário nunca precisa clicar em "Gerar"; a resposta é instantânea. Os UUIDs são exibidos em uma lista vertical, cada um clicável individualmente para copiar apenas aquele identificador para a área de transferência. Há também um botão "Copiar todos" que copia todos os UUIDs da lista para a área de transferência de uma só vez.

A geração ocorre inteiramente no navegador, utilizando a API crypto.getRandomValues() do JavaScript, que fornece números aleatórios criptograficamente fortes. Nenhum dado — nem a quantidade, nem os UUIDs gerados — é enviado para o servidor do BroBroGo. Após a primeira geração, uma mensagem de status indica "Pronto." ou "Gerado.", e após a cópia em massa aparece "Copiado tudo!". As opções disponíveis são:

Opção Valores possíveis Efeito na saída
Formato UUID v7 (fixo) Gera UUIDs exatamente no formato da versão 7 (timestamp + aleatoriedade).
Quantidade (Count) Inteiro entre 1 e 100 Controla quantos UUIDs são exibidos na lista.
Maiúsculas Ligado/Desligado Quando ligado, as letras hexadecimais (a-f) são exibidas em maiúsculas.
Hífens Ligado/Desligado Quando desligado, os hífens são removidos, resultando em uma string de 32 caracteres contínua.

A mudança de qualquer opção descarta a lista anterior e gera um novo conjunto completo de UUIDs. Isso significa que se o usuário estiver com 50 IDs e reduzir o count para 10, os 10 novos UUIDs serão completamente diferentes dos anteriores — não uma sublista. Esse comportamento evita confusão sobre quais IDs correspondem a qual configuração.

A estrutura do UUID v7: timestamp e aleatoriedade

Cada UUID v7 é composto de 128 bits no total. Os 48 bits mais significativos são o timestamp Unix em milissegundos. Os 80 bits restantes são divididos em campos de versão (4 bits, valor fixo 0111 = 7), variante (2 bits, valor 10) e 74 bits de aleatoriedade pura. Na representação textual de 36 caracteres, os primeiros 12 caracteres (após ignorar hífens) correspondem ao timestamp. Por exemplo, no UUID 018f9a3e-7b1c-7a00-8000-123456789abc, os primeiros oito caracteres (018f9a3e) e o nono ao décimo segundo (7b1c) juntos formam a representação hexadecimal do timestamp.

A inclusão de hífens é opcional na ferramenta. O padrão RFC exige hífens nas posições 8-4-4-4-12, mas muitos sistemas armazenam UUIDs como strings de 32 caracteres sem hífens para economizar espaço ou facilitar a indexação. A opção de maiúsculas/minúsculas também não altera o valor do UUID; a letra a minúscula e A maiúscula representam o mesmo nibble. Contudo, alguns bancos de dados (como PostgreSQL) tratam UUIDs como binários e não se importam com case, enquanto outras aplicações podem comparar strings de forma sensível a caixa. A ferramenta permite que o usuário escolha o formato que melhor se adapta ao seu pipeline.

Vale notar que, como a timestamp tem resolução de apenas 1 ms, dois UUIDs gerados dentro do mesmo milissegundo podem aparecer em qualquer ordem na saída. A parte aleatória não é monotônica — ou seja, não há garantia de que o segundo UUID gerado terá um valor aleatório maior que o primeiro. Se a ordenação estrita dentro do mesmo milissegundo for crítica (por exemplo, em sistemas de log de eventos com alta concorrência), o UUID v7 não oferece essa garantia. Outros formatos, como o ULID, têm mecanismos opcionais para monotonicidade, mas a implementação padrão também sofre da mesma limitação.

UUID v7 vs UUID v4 vs ULID: quando usar cada um

A escolha entre esses identificadores depende principalmente do equilíbrio entre ordenação temporal, imprevisibilidade e compatibilidade. A tabela abaixo compara as principais características:

Característica UUID v4 UUID v7 ULID
Tamanho da string 36 caracteres (com hífens) 36 caracteres (com hífens) 26 caracteres (Crockford base32)
Bits totais 128 128 128
Bits de timestamp 0 48 (ms desde Unix epoch) 48 (ms desde Unix epoch)
Bits aleatórios 122 74 80 (inclui parte de timestamp?)
Ordenação temporal Nenhuma Por timestamp (não estrito no mesmo ms) Por timestamp (não estrito no mesmo ms)
Resistência a colisão Muito alta (122 bits aleatórios) Alta (74 bits aleatórios) Alta (80 bits aleatórios)
Fragmentação de índice Alta Baixa (devido ao prefixo temporal) Baixa (prefixo temporal)
Padrão formal RFC 4122 (2005) Draft IETF (proposto) Especificação aberta (não IETF)

O UUID v4 continua sendo o mais difundido e é apropriado quando não há necessidade de ordenação por criação (ex.: identificadores de sessão temporários). O UUID v7 é superior para chaves primárias em bancos de dados onde a inserção de novos registros deve evitar a reorganização constante do índice B-tree — o chamado page split. O ULID tem a vantagem de ser mais curto (26 caracteres) e legível em URLs, mas não é nativamente suportado por todas as linguagens e frameworks.

Outra diferença prática: o UUID v7, por ter menos bits aleatórios (74 contra 122 do v4), tem uma probabilidade de colisão ligeiramente maior. Mas, na prática, 2^74 combinações (cerca de 1,9 × 10^22) ainda são astronomicamente altas para a maioria dos sistemas. Se o volume de IDs ultrapassar bilhões por milissegundo, aí sim seria necessário considerar uma fonte de monotonicidade adicional.

Casos de uso e aplicações práticas

O UUID v7 é ideal para sistemas distribuídos onde cada nó gera seus próprios identificadores sem depender de um coordenador central. Bancos de dados como CockroachDB e algumas configurações do MySQL usam variantes de UUID temporal para melhorar a performance de gravação. Ao substituir chaves primárias baseadas em UUID v4 por v7, administradores de banco de dados relatam redução significativa na fragmentação de índices e no número de páginas lidas durante inserções em lote.

Outras aplicações comuns:

  • Sistemas de mensageria: cada mensagem recebe um UUID v7 que permite ordenar por chegada (dentro da precisão do milissegundo).
  • Auditoria e logs: o timestamp embutido elimina a necessidade de separar o carimbo de data/hora do identificador.
  • Event sourcing: eventos ordenados por UUID v7 facilitam a reconstrução do estado sem depender de relógios de sistema externos.
  • Microsserviços: cada serviço gera IDs localmente; como a timestamp é compartilhada, a ordenação aproximada se mantém entre serviços (desde que os relógios estejam sincronizados via NTP).

A geração local no navegador, como a implementada na ferramenta, é particularmente útil para prototipação e testes. O desenvolvedor pode gerar rapidamente dezenas de UUIDs v7 com diferentes configurações (com/sem hífens, maiúsculas/minúsculas) e copiar os que se encaixam no formato exigido pelo seu sistema de destino. Como nada é enviado ao servidor, não há risco de vazamento de dados durante a fase de desenvolvimento.

Perguntas frequentes (FAQ)

Posso gerar mais de 100 UUIDs v7 de uma vez?
A ferramenta está limitada a 100 IDs por clique. Para gerar mais, é necessário executar múltiplas gerações. Essa restrição existe para evitar sobrecarga do navegador e garantir resposta instantânea.

Por que os UUIDs v7 não são estritamente ordenados quando gerados no mesmo milissegundo?
O UUID v7 não define um mecanismo monotônico para a parte aleatória. Dois IDs criados no mesmo milissegundo terão timestamps idênticos; a ordem na saída é determinada pela aleatoriedade, que não é garantida como crescente. Se a ordenação exata for necessária, o desenvolvedor deve adicionar um contador incremental ou usar um formato como o Snowflake.

O UUID v7 é seguro para uso criptográfico?
Não. Embora a parte aleatória seja gerada com crypto.getRandomValues() (criptograficamente forte), o UUID v7 como um todo não é projetado para ser imprevisível o suficiente para tokens de autenticação ou chaves de sessão. Um atacante que conheça o timestamp pode reduzir o espaço de busca. Para fins criptográficos, prefira funções de hash ou geradores específicos.

A ferramenta envia meus UUIDs para o servidor do BroBroGo?
Não. Toda a geração ocorre localmente no seu navegador, usando a API de criptografia disponível no JavaScript. Nenhum dado é transmitido para nenhum servidor.

Para que serve a opção "maiúsculas"?
Controla apenas a apresentação visual. UUIDs em maiúsculas ou minúsculas representam o mesmo valor binário. Alguns sistemas (ex.: Amazon DynamoDB) tratam UUIDs como strings e podem exigir um formato específico. A opção permite adequar a saída ao padrão do seu projeto.

Quantos bits de aleatoriedade o UUID v7 realmente tem?
Dos 128 bits, 48 são timestamp, 4 são da versão, 2 da variante e os 74 restantes são aleatórios. Isso resulta em cerca de 2^74 ≈ 1,9 × 10^22 combinações possíveis para o componente aleatório, o que é suficiente para praticamente todos os cenários de uso.