Ao modelar a estrutura de dados de uma aplicação, a escolha da chave primária parece simples, mas as opções tradicionais trazem gargalos graves em arquiteturas modernas.
Durante décadas, o padrão foi utilizar chaves inteiras auto-incrementais (BIGINT AUTO_INCREMENT). Porém, em microsserviços e sistemas distribuídos com alta concorrência, essa abordagem desmorona. Dois servidores distintos não conseguem gerar um ID simultaneamente sem consultar um banco centralizado, criando gargalos de latência. Além disso, expor IDs sequenciais como /pedidos/1004 expõe métricas de negócio, permitindo que concorrentes estimem o volume de vendas ou a quantidade de cadastros.
Para resolver a centralização, muitos desenvolvedores passaram a adotar o UUID v4. Embora resolva a geração descentralizada, por ser inteiramente aleatório ele causa a destruição da performance de escrita em índices B-Tree, forçando o banco de dados a reordenar e dividir páginas físicas de disco a cada nova inserção.
A Solução: UUID v7
O UUID v7 entrega o melhor dos dois mundos ao combinar unicidade universal de 128 bits com ordenação temporal nativa (Time-Ordered), sendo amplamente suportado por bancos de dados modernos.
Ele codifica a data e hora atual em seus primeiros 48 bits, seguidos por bits de versão e variante, e 74 bits de entropia aleatória. Na prática, IDs gerados cronologicamente mantêm-se sempre em ordem sequencial lexicográfica.
Timestamp (48 bits)
Armazena o tempo decorrido desde o Unix Epoch em milissegundos. Garante a ordenabilidade temporal nativa dos IDs.
Versão (4 bits)
O caractere fixo 7 identifica formalmente o UUID de versão 7 (bits 0111).
Variante (2 bits)
Indica a especificação de layout do UUID. Bits iniciais em 10 mapeiam para os caracteres 8, 9, a, b.
Aleatoriedade (74 bits)
Entropia gerada via Web Crypto API. Garante unicidade absoluta e impede colisões, mesmo gerando IDs no mesmo milissegundo.
Performance no Banco: B-Tree
A ordenação temporal é decisiva para o banco de dados porque a maioria das engines relacionais (PostgreSQL, MySQL, SQL Server) estrutura suas chaves primárias em árvores B-Tree.
Ao inserir registros com UUID v4 (totalmente aleatório), o banco tenta gravar em locais randômicos do índice. Quando uma página de disco já está cheia, ocorre o Page Split (divisão física da página), gerando I/O pesado de disco, fragmentação e degradação drástica de performance com o crescimento da tabela.
Já com o UUID v7, como os primeiros bits progridem linearmente no tempo, cada nova chave inserida é naturalmente maior que a anterior. O banco grava novos registros no final do índice de forma ordenada e contínua, com zero divisão de páginas.
Contras e o Risco de Privacidade
Nenhuma escolha de arquitetura vem sem contrapartidas. O UUID v7 ocupa 16 bytes, o dobro de um BIGINT (8 bytes). Em tabelas com bilhões de linhas, esse tamanho propaga-se por todas as chaves estrangeiras e índices secundários, exigindo mais memória RAM para manter o cache aquecido. Além disso, para depuração em logs ou testes locais, UUIDs de 36 caracteres são menos práticos que números inteiros simples.
O ponto mais crítico é o vazamento de privacidade temporal. Como os primeiros 48 bits registram o timestamp exato, qualquer pessoa com acesso ao ID público consegue determinar o milissegundo em que aquele recurso foi criado.
Qual Chave Escolher?
Em sistemas distribuídos, microsserviços e aplicações web modernas, o UUID v7 é a escolha ideal e deve ser adotado como padrão.
Reserve chaves inteiras auto-incrementais apenas para tabelas puramente internas onde o espaço de armazenamento é crítico. Evite UUID v4 para chaves primárias, a menos que ocultar 100% da data de criação da chave seja um requisito absoluto de segurança.