Gere UUIDs v4 aleatórios em lote. Copie um por um, em bloco ou exporte como CSV.
Clique em Gerar UUIDs para começar
UUID (Universally Unique Identifier) é um número de 128 bits usado para identificar informações em sistemas computacionais de forma globalmente única. Quando gerado de acordo com os métodos padrão, a probabilidade de duplicação é tão baixa que é considerada praticamente impossível, mesmo gerando bilhões de UUIDs por segundo.
O formato canônico é uma string hexadecimal de 36 caracteres: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx (ex: 550e8400-e29b-41d4-a716-446655440000). A versão mais comum é a v4 (aleatória).
Formato do UUID v4: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx
O dígito na posição 13 é sempre 4 (indica a versão). O dígito na posição 17 é 8, 9, A ou B (indica a variante RFC 4122).
| Versão | Método de Geração | Vantagens | Desvantagens |
|---|---|---|---|
| UUID v1 | Baseado em Timestamp + Endereço MAC da máquina. | Ordenável temporalmente (útil para índices de BD). | Vaza informação da máquina (MAC) e horário. Não recomendado para privacidade. |
| UUID v4 | Aleatório (122 bits aleatórios). | Seguro, não vaza informações, imprevisível. | Não é ordenável, pode fragmentar índices clustered (PK). |
| NIL UUID | 00000000-0000-0000-0000-000000000000 | Representa a ausência de UUID (similar a NULL). | Não deve ser usado como identificador real. |
Recomendação: Para aplicações web e APIs, use UUID v4. Se a ordenação por tempo de criação for crucial e você não quiser expor timestamp, considere usar ULID (Universally Unique Lexicographically Sortable Identifier), que é ordenável e seguro.
Usar UUID como Primary Key é uma prática comum em sistemas distribuídos (microsserviços), pois permite gerar IDs únicos sem depender de um contador centralizado (SEQUENCE/AUTO_INCREMENT).
| Banco de Dados | Tipo de Coluna Recomendado | Função Nativa |
|---|---|---|
| PostgreSQL | UUID | gen_random_uuid() |
| MySQL 8.0+ | BINARY(16) (mais performático que CHAR(36)) | UUID_TO_BIN(UUID()) |
| SQL Server | uniqueidentifier | NEWID() (v4) ou NEWSEQUENTIALID() |
| SQLite | TEXT ou BLOB | Não tem nativa (use extensão ou aplicação). |
Matematicamente desprezível. Um UUID v4 tem 122 bits de entropia (2^122 combinações possíveis, ~5.3×10^36).
ULID (Universally Unique Lexicographically Sortable Identifier) resolve o principal problema do UUID v4: a falta de ordenação.
| Característica | UUID v4 | ULID |
|---|---|---|
| Ordenável? | Não (aleatório). | Sim (Timestamp + Aleatório). |
| Tamanho | 36 caracteres (string). | 26 caracteres (Base32). |
| Legível | Hexadecimal com hífens. | Crockford's Base32 (sem caracteres ambíguos como I, L, O, U). |
| Performance em PK (MySQL) | Ruim (fragmentação). | Ótima (inserção sequencial). |
| Exemplo | 550e8400-e29b-41d4-a716-446655440000 | 01ARZ3NDEKTSV4RRFFQ69G5FAV |
Quando usar ULID? Se você está projetando um novo sistema e precisa de um identificador único, ordenável por tempo e que funcione bem como Primary Key em MySQL, ULID é superior ao UUID v4.
crypto.randomUUID().const id = crypto.randomUUID(); // "550e8400-e29b-41d4-a716-446655440000"CREATE EXTENSION IF NOT EXISTS "pgcrypto";INSERT INTO tabela (id) VALUES (gen_random_uuid());ALTER TABLE tabela ALTER COLUMN id SET DEFAULT gen_random_uuid();
00000000-0000-0000-0000-000000000000. É usado para representar a ausência de um UUID (equivalente a NULL, mas para sistemas que não aceitam NULL). Exemplo: um campo parent_id que referencia um registro raiz pode usar NIL UUID em vez de NULL.
uuid:import uuid
u = uuid.UUID('550e8400-e29b-41d4-a716-446655440000')
binario = u.bytes # 16 bytes
hex_sem_hifen = u.hex # '550e8400e29b41d4a716446655440000'
/perfil/550e8400-e29b-41d4-a716-446655440000), use sempre UUID v4.
/^[0-9a-f]{8}-[0-9a-f]{4}-[1-5][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/iuuid.UUID(string, version=4) lança exceção se inválido.
O UUID v7 foi oficialmente aprovado na RFC 9562 em 2024 e representa uma evolução significativa em relação ao UUID v4. Enquanto o v4 é completamente aleatório, o v7 é baseado em tempo Unix (milissegundos), o que o torna ordenado cronologicamente. Isso resolve um dos maiores problemas de performance com UUIDs em bancos de dados relacionais: a fragmentação de índices B-tree causada por valores aleatórios.
Com UUID v7, cada novo registro gerado tem um identificador lexicograficamente maior que o anterior, permitindo que o banco de dados insira registros de forma seqüencial no índice — exatamente como acontece com chaves inteiras auto-incrementais, mas mantendo a unicidade global garantida pelos UUIDs.
UUID v4 vs UUID v7: O v4 gera 122 bits aleatórios puros, causando fragmentação de índice em tabelas grandes. O v7 usa os primeiros 48 bits para o timestamp Unix em milissegundos, mais 74 bits aleatórios — mantendo unicidade global e adicionando ordenação temporal. Para novos projetos com PostgreSQL, MySQL 8+ ou SQL Server, prefira sempre o UUID v7.
| Versão | Base | Orderável | Uso Recomendado |
|---|---|---|---|
| v1 | Tempo MAC (100ns) + nó de rede | Sim (por criação) | Sistemas legados; exposto o MAC address |
| v4 | Aleatório (122 bits) | Não | Chaves de sessão, tokens, usos gerais sem DB intensivo |
| v5 | Hash SHA-1 de namespace + nome | Não | UUIDs determinísticos a partir de dados conhecidos |
| v7 | Timestamp Unix (ms) + aleatório | Sim (cronológico) | Chaves primárias em bancos de dados modernos (recomendado) |
Armazenar UUIDs como VARCHAR(36) é prática comum, porém ineficiente. Cada UUID ocupa 36 bytes no formato de texto (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx), enquanto a representação binária ocupa apenas 16 bytes. A diferença parece pequena, mas em tabelas de grande volume o impacto é substancial — tanto no espaço em disco quanto na velocidade de comparação e ordenação.
Em MySQL e MariaDB, use o tipo BINARY(16) combinado com as funções UUID_TO_BIN() e BIN_TO_UUID(). No PostgreSQL, use o tipo nativo UUID, que já armazena internamente em 16 bytes. No SQL Server, use UNIQUEIDENTIFIER e avalie a opção NEWSEQUENTIALID() para comportamento similar ao UUID v7.
Dica prática: Ao migrar de VARCHAR(36) para BINARY(16), lembre-se de atualizar todas as queries que comparam UUIDs diretamente. Use WHERE id = UUID_TO_BIN('seu-uuid-aqui') em MySQL, ou cast explícito no seu ORM. Frameworks como Laravel, Django e Spring Boot já oferecem suporte nativo a UUID binário com configurações mínimas.