> uuidv7 generator <

R: UUIDv7 é um identificador de 128 bits definido na RFC 9562 (maio de 2024) que combina um timestamp Unix de 48 bits em milissegundos com 74 bits de aleatoriedade e os bits padrão de versão + variante. O resultado é um ID globalmente único que também se ordena cronologicamente por hora de criação — o melhor dos dois mundos. Foi projetado especificamente para corrigir a dor dos índices de banco de dados causada por chaves primárias UUIDv4 aleatórias, onde cada inserção cai em uma página B-tree diferente e causa enorme amplificação de escrita.

R: UUIDv4 é totalmente aleatório (122 bits aleatórios) e não tem estrutura além dos campos de versão + variante. Dois v4 gerados com um microssegundo de diferença se ordenam em posições muito diferentes, o que é ótimo para imprevisibilidade, mas terrível para índices B-tree. UUIDv7 coloca um timestamp Unix de 48 bits em milissegundos no início, então v7 gerados próximos no tempo também se ordenam próximos no armazenamento. Compromisso: v7 revela a hora de criação e tem apenas 74 bits aleatórios em vez de 122 — ainda resistente a colisões, mas inadequado como token secreto.

R: Para chaves primárias de banco de dados internas em tabelas com muitas escritas — sim, quase sempre. A fragmentação de índice que o v4 causa pode superar o custo das próprias consultas, especialmente no PostgreSQL ou MySQL com índices clusterizados InnoDB. Para tokens expostos aos usuários, incorporados em URLs ou tratados como capabilities («se você conhece o UUID pode acessar o recurso»), mantenha v4 ou use um token aleatório separado — v7 revela a hora de criação. Um padrão comum são chaves primárias v7 para joins internos mais um slug aleatório separado para a URL pública.

R: Conceitualmente semelhantes — todos os quatro são IDs ordenados por tempo — mas os layouts de bits e codificações diferem. ULID usa Crockford base32 e um layout de milissegundos diferente. KSUID codifica um timestamp de 32 bits + payload de 128 bits como 27 caracteres base62. Snowflake é um ID de 64 bits específico do Twitter com IDs de worker. UUIDv7 é o equivalente padrão da IETF, codificado na forma hexadecimal canônica 8-4-4-4-12, de modo que toda biblioteca UUID, tipo UUID de banco de dados e driver JDBC/ODBC já o entende. Se você está começando do zero em 2025+, prefira v7 — é o padrão.

R: Dentro de um único milissegundo, apenas os 74 bits aleatórios (12 em rand_a + 62 em rand_b) garantem a unicidade. Pelo limite de colisão de aniversário, você pode gerar cerca de 2^37 ≈ 137 bilhões de v7 no mesmo ms antes de uma chance de colisão de 50% — efetivamente ilimitado para qualquer sistema realista. Entre milissegundos, o próprio timestamp desambigua, então o risco de colisão global ao longo da vida de um sistema é desprezível. Com o botão Monotônico ativado, as colisões intra-milissegundo são zero por construção (a parte aleatória é incrementada).

R: Sim — o timestamp são os primeiros 48 bits, que são os primeiros 12 caracteres hexadecimais com os hifens removidos. Concatene os três primeiros grupos de hifens (8 + 4 = 12 hex digits), interprete como inteiro hexadecimal e você terá o timestamp Unix em milissegundos. Use o decodificador acima para fazer isso interativamente, ou no código: parseInt(uuid.replace(/-/g,'').slice(0,12), 16). O resultado é o instante em milissegundos em que o UUID foi gerado, preciso conforme o relógio do sistema naquele momento.

R: O terceiro grupo delimitado por hifens sempre começa com o dígito 7. Por exemplo: 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55. O quarto grupo sempre começa com 8, 9, a ou b — esses são os quatro valores possíveis com os dois bits altos sendo 10 (a variante RFC 4122). Se o dígito de versão não for 7, o UUID é de outra versão (comumente 4 para aleatório ou 1 para v1 baseado em tempo) e não se ordena cronologicamente.

R: PostgreSQL 18 (lançado em setembro de 2025) inclui uuidv7() como função integrada. Versões anteriores precisam da extensão pg_uuidv7 ou da geração no lado do cliente. MySQL 8.x não tem v7 nativo; use o auxiliar UUID_TO_BIN(uuid, 1) (que troca os bytes do timestamp para a ordem de classificação) apenas para v1 — para v7 gere no lado do cliente. SQL Server, Oracle e SQLite esperam todos a geração de v7 no lado do cliente. A maioria dos ORMs (Hibernate, Entity Framework, Sequelize, Prisma, SQLAlchemy) agora suporta v7 nativamente ou via plugin.

R: Sim. A RFC 9562 §6.2 descreve explicitamente três métodos para garantir a ordenação intra-milissegundo: (1) preenchimento aleatório, (2) aleatório monotônico — incrementar um contador quando o timestamp não avança, (3) precisão de timestamp sub-milissegundo. A caixa de seleção Monotônico nesta ferramenta implementa o método 2: quando dois UUIDs compartilham o mesmo timestamp de 48 bits, a parte aleatória do segundo é definida como previous_random + 1 em vez de ser sorteada de novo. Isso garante ordenação rigorosa para geração em lote, permanecendo totalmente em conformidade com a especificação.

R: Não. Toda a geração, decodificação, ordenação, cópia e download de UUIDv7 acontecem inteiramente no seu navegador como JavaScript puro. A página nunca faz uma requisição de rede quando você clica em GERAR, DECODIFICAR, COPIAR ou BAIXAR — você pode verificar com a aba Rede das ferramentas de desenvolvedor do seu navegador. Não registramos timestamps, seeds personalizadas, UUIDs gerados ou saídas decodificadas. A página em si é HTML estático servido por uma CDN, então nenhuma entrada chega à nossa infraestrutura. Isso torna a ferramenta segura para IDs de banco de dados de produção, logs internos ou qualquer outro dado que você prefira não passar por um servidor de terceiros.

R: Sim. Java tem com.fasterxml.uuid:java-uuid-generator 5.0+ e o JDK 21 o tem via auxiliares de biblioteca. .NET 9 inclui Guid.CreateVersion7() na BCL. Rust usa Uuid::now_v7() do crate uuid atrás do feature flag v7. A maioria dos outros ecossistemas (Elixir, Ruby, PHP, Swift, Kotlin) também tem pacotes bem mantidos — pesquise «uuidv7» ou «uuid v7» no registro de pacotes da linguagem. O formato wire é idêntico em todos eles, então um v7 gerado em Go pode ser interpretado e ter o timestamp extraído por JavaScript sem qualquer transformação.

R: Sim — a partir do Node.js v26.1.0 (lançado em 07-05-2026) a biblioteca padrão expõe crypto.randomUUIDv7([options]). Importe-o como import { randomUUIDv7 } from 'node:crypto' e chame-o sem argumentos para obter uma string UUID v7 RFC 9562. A única opção suportada é disableEntropyCache (booleano, padrão false); por padrão o Node armazena em cache dados aleatórios suficientes com antecedência para gerar os próximos ~128 UUIDs, a mesma otimização usada por crypto.randomUUID(). Ressalva importante da documentação oficial: «o timestamp incorporado depende de um relógio não monotônico e não há garantia de que seja estritamente crescente». Em outras palavras, dois UUIDs gerados no mesmo milissegundo, ou quaisquer UUIDs criados ao longo de um passo NTP / desvio para trás do relógio da VM, podem não se ordenar por hora de criação. Se você precisa de monotonicidade rigorosa dentro de um milissegundo, use uma implementação userland que siga a RFC 9562 §6.2 Método 2 (o pacote npm uuidv7, ou esta ferramenta com o botão Monotônico ativado).

R: Armazene-o como um tipo binário de 16 bytes em vez de uma string de 36 caracteres — você economiza 20 bytes por linha, reduz pela metade o tamanho do índice e ganha um caminho de comparação mais rápido. Use o tipo uuid do PostgreSQL, MySQL BINARY(16), SQL Server uniqueidentifier ou SQLite BLOB. Adicione uma restrição CHECK de que o nibble de versão seja igual a 7 se quiser imposição. Com v7, as linhas se agrupam naturalmente por hora de criação, então um índice de cobertura em (uuid_pk) geralmente é suficiente — você não precisa de um índice (created_at) separado para consultas cronológicas.