Gerador de UUID v7, v4 e v1

Auto-FixTempo Real

Gere UUID v7 (Postgres 18, sortable), v4 random e v1 timestamp. Bulk até 1000, validador integrado, 100% no navegador.

Opções de Geração

Quantidade

Case

Formato

OpçõesAuto-copy

Nenhum UUID gerado ainda

Configure as opções acima e clique em "Gerar UUIDs"

UUID v7: o padrão 2026 para chaves primárias

Aprovado em mai/2024 pela RFC 9562, o UUID v7 embute timestamp Unix (48 bits) nos primeiros bytes seguidos de 74 bits aleatórios. Resultado: continua único, mas é ordenável cronologicamente. Em databases com índice B-tree (Postgres, MySQL), INSERT fica 2-10x mais rápido que v4 porque novos registros vão sempre pro fim do índice — sem fragmentação, sem page splits.

Postgres 18 (out/2025) lançou com função nativa uuidv7(). MySQL 8.4 tem helper similar. Se você está modelando schema novo em 2026, comece com v7 — só use v4 se precisar evitar vazamento do horário de criação (raro).

Como gerar UUID em JavaScript, Python e SQL

JavaScript (Node 14.17+ e browser): crypto.randomUUID() gera v4. Pra v7, use lib uuid (versão 10+) ou implementação manual com crypto.getRandomValues. Python 3.13+: uuid.uuid4() pra v4, uuid.uuid7() (PEP 8 proposal) ou lib uuid-utils pra v7.

PostgreSQL: gen_random_uuid() pra v4 (built-in desde PG 13). Pra v7, use uuidv7() no Postgres 18 — antes disso, instale extensão pg_uuidv7. MySQL: UUID() retorna v1; pra v4/v7 use função custom com UUID_TO_BIN(...,1) pra rearrumar bytes e indexar melhor.

UUID como primary key: vantagens, armadilhas e quando NÃO usar

Pros: gerar sem coordenação central (microservices, eventual consistency), não expor sequência adivinhável (BOPE: bookmark/owner/privacy/enumeration), distribuir writes em sharding. Contras: 16 bytes vs 4-8 de INT, JOIN um pouco mais lento, leitura humana mais difícil.

Armadilha real do v4: alta entropia fragmenta B-tree e gera page splits — pode até dobrar I/O em tabelas grandes. Solução: usar v7 (timestamp-ordered) ou v4 + coluna timestamp separada pra ordenação. Quando NÃO usar UUID? Tabelas de lookup pequenas (states, currencies) onde INT é suficiente e mais legível.

Perguntas Frequentes

0/5

✓O que é UUID e para que serve?

UUID (Universally Unique Identifier) é um identificador único de 128 bits padronizado pela RFC 9562. Tem 8 versões (v1 a v8), cada uma com geração diferente. Usado em databases, APIs, microservices, logs e qualquer caso que precise de ID único sem coordenação central.

✓Qual a diferença entre UUID v4 e v7?

v4 é 122 bits totalmente aleatórios — máxima entropia, sem padrão. v7 embute timestamp Unix nos primeiros 48 bits + 74 bits aleatórios — continua único mas é ordenável cronologicamente. Em databases, v7 tem INSERT 2-10x mais rápido que v4 porque não fragmenta o índice B-tree. Use v7 como padrão em 2026, v4 só se precisar esconder o horário de criação.

✓UUIDs são realmente únicos?

A probabilidade de colisão em UUID v4 é astronomicamente baixa (1 em 2^122). Você precisaria gerar 1 bilhão de UUIDs por segundo durante 85 anos pra ter 50% de chance de 1 colisão. Em v7, o timestamp reduz ainda mais a chance de colisão dentro do mesmo ms.

✓Posso usar UUID como primary key?

Sim, especialmente v7 — Postgres 18 já tem uuidv7() nativo e MySQL 8.4 tem helper. v4 também funciona mas fragmenta o índice B-tree (pode dobrar I/O em tabelas grandes). UUID ocupa 16 bytes vs 4-8 de INT, então só use quando a vantagem de gerar sem coordenação central compensar.

✓UUID e GUID são a mesma coisa?

Sim. GUID (Globally Unique Identifier) é o nome que a Microsoft usa em .NET, SQL Server e COM/OLE. UUID é o nome da RFC 9562 (padrão IETF). Mesmo formato de 128 bits, mesmas versões — só nomenclatura diferente.