Gerador de UUID v7

Por anos, equipes de engenharia que queriam a resistência a colisões de um UUID mas a ordenação amigável a índices de um inteiro sequencial tiveram que construir seu próprio híbrido não padrão — comumente prefixando um UUID aleatório com um timestamp gerado manualmente, uma abordagem usada em várias formas por várias empresas de sistemas distribuídos conhecidas antes que existisse qualquer padrão oficial para isso. A RFC 9562 formalizou esse padrão em uma versão oficial de UUID especificamente para que implementações através de linguagens e bancos de dados diferentes pudessem produzir e reconhecer a mesma estrutura ordenada por tempo sem cada equipe reinventar independentemente uma variante ligeiramente diferente e incompatível da mesma ideia.

Os 48 bits iniciais de um UUID v7 codificam um timestamp Unix em milissegundos, que é o que dá ao valor sua ordem de classificação — comparar dois UUID v7 como strings simples reflete corretamente qual foi gerado primeiro, já que a porção de timestamp domina a comparação. Os bits restantes permanecem preenchidos com dados criptograficamente aleatórios, exatamente como no v4, então o valor é igualmente resistente a ser adivinhado quanto um UUID completamente aleatório seria; apenas seu comportamento de ordenação muda, não sua imprevisibilidade.

Além da velocidade de inserção bruta, uma chave primária ordenada por tempo tem um segundo benefício prático que importa no dia a dia: as linhas voltam naturalmente em ordem de criação de uma simples consulta `ORDER BY id`, sem precisar de uma coluna `created_at` separada e um índice adicional nela apenas para ordenar registros cronologicamente. Para uma tabela consultada frequentemente "mais recente primeiro" — um registro de atividade, uma fila, uma trilha de auditoria — uma chave primária v7 dá essa ordenação de graça como efeito colateral do próprio ID, em vez de como um custo separado a manter.