Por que o UUID v7 está substituindo o UUID v4 nos Bancos de Dados

Escolher a chave primária (PK) ideal é uma das decisões arquiteturais mais críticas no início de qualquer projeto de software. Historicamente, desenvolvedores utilizavam IDs inteiros sequenciais auto-incrementados. Contudo, com o advento de microsserviços, arquiteturas distribuídas e a necessidade de evitar problemas de segurança como enumeração de recursos (vulnerabilidades de IDOR), o UUID v4 tornou-se a escolha padrão da indústria.

Mas o UUID v4 tem um calcanhar de Aquiles silencioso que só grita em produção: sua natureza puramente aleatória destrói a performance de escrita e indexação em bancos de dados relacionais gigantes.

Para sanar essa dor de vez, a IETF aprovou novas especificações de UUIDs, trazendo o UUID v7 como o novo queridinho da engenharia de software. Neste artigo, vamos mergulhar na matemática dos índices B-Tree para entender por que o UUID v7 está substituindo o v4 em novos projetos.

1. A Fraqueza Oculta do UUID v4: A Fragmentação dos Índices B-Tree

Para entender o problema do UUID v4, precisamos dar um passo atrás e entender como bancos relacionais clássicos (como PostgreSQL e o motor InnoDB do MySQL) armazenam dados fisicamente em disco.

Esses bancos organizam as tabelas e índices usando estruturas chamadas Árvores B (B-Trees). Os registros são guardados de forma ordenada em páginas de tamanho fixo (normalmente 8KB ou 16KB). Quando você usa uma chave primária sequencial (como um inteiro auto-incrementado), as inserções ocorrem sempre de forma ordenada no fim do índice. As páginas em disco são preenchidas de forma sequencial até o fim.

Por outro lado, o UUID v4 é 100% aleatório. Ao inserir um registro com UUID v4, o banco de dados precisa colocá-lo em uma posição completamente imprevisível no meio de alguma página de índice existente:

• Se a página de destino em disco estiver cheia, o banco é forçado a realizar uma Divisão de Página (Page Split). Ele divide a página de dados ao meio, move parte dos registros para uma nova página e insere o novo registro.
• Essas divisões geram uma quantidade massiva de operações de I/O em disco (leitura e gravação física).
• Os dados tornam-se altamente fragmentados, espalhados fisicamente de forma desorganizada, destruindo a localidade de cache da memória RAM e degradando drasticamente o desempenho de inserções conforme o banco cresce.

2. O que é o UUID v7?

O UUID v7 foi projetado especificamente para solucionar o problema de ordenamento físico sem perder os benefícios de unicidade distribuída do UUID tradicional.

A estrutura de 128 bits do UUID v7 é dividida logicamente em duas grandes seções:

Como os primeiros 48 bits representam o tempo, qualquer UUID v7 gerado depois será matematicamente **maior** do que os UUIDs gerados anteriormente. Eles são ordenáveis cronologicamente no tempo (*time-ordered*).

3. Vantagens Reais de Adotar o UUID v7

Ao substituir o UUID v4 pelo v7 na sua chave primária, seu sistema ganha benefícios imediatos de arquitetura e infraestrutura:

A. Inserções Sequenciais (Zero Page Splits)

Como as chaves são sequenciais no tempo, novas linhas são sempre inseridas na "borda direita" das páginas de índice B-Tree, exatamente igual a um inteiro auto-incremento. Divisões de páginas são drasticamente reduzidas, mantendo o índice limpo, compacto e com excelente localidade de dados no disco.

B. Paginação de Alta Performance (Keyset Pagination)

Fazer paginação com OFFSET em tabelas grandes é lento, pois força o banco a ler todas as linhas anteriores. A alternativa eficiente é a Paginação Baseada em Cursor (Keyset Pagination). Como o UUID v7 é cronológico, você pode utilizá-lo diretamente como o cursor da busca, sem a necessidade de criar índices compostos adicionais com a coluna created_at.

-- Paginação eficiente e à prova de lentidão:
SELECT id, nome 
FROM usuarios 
WHERE id > '0190a6e2-7b3a-7f1c-8b5d-1c2d3e4f5a6b' -- último UUID v7 da página anterior
ORDER BY id 
LIMIT 20;

C. Geração Descentralizada sem Colisão

Os 74 bits de aleatoriedade pura garantem que você possa gerar UUIDs v7 paralelamente em centenas de microsserviços ou diretamente nos clientes no navegador, sem nenhum risco de colisão de chaves e sem a necessidade de coordenação de um servidor central.

4. Como Gerar e Usar UUID v7

Com a aprovação da nova especificação, diversas linguagens e bancos de dados estão adicionando suporte nativo ao UUID v7.

No PostgreSQL (Versão 17+)

O PostgreSQL 17 introduziu suporte nativo ao padrão de forma direta:

-- Gerar UUID v7 nativamente:
SELECT uuidv7();

-- Usando em tabelas como valor padrão:
CREATE TABLE logs_sistema (
    id UUID PRIMARY KEY DEFAULT uuidv7(),
    mensagem TEXT NOT NULL
);

Em Bibliotecas Backend (Node.js)

A biblioteca padrão uuid em JavaScript já suporta a geração do v7:

import { v7 as uuidv7 } from 'uuid';

const novoId = uuidv7();
console.log(novoId); // Ex: "0190a6e2-7b3a-7f1c-8b5d-1c2d3e4f5a6b"

Conclusão

O UUID v7 é a evolução definitiva das chaves primárias. Ele combina perfeitamente a **segurança** e a **descentralização** do UUID v4 com a **performance de escrita** e a **ordenação natural** dos inteiros sequenciais.

Se você está iniciando um novo banco de dados no PostgreSQL ou MySQL, ou desenhando a arquitetura de uma tabela que receberá milhões de linhas, adote o UUID v7 desde o dia zero para economizar recursos de disco e evitar dores de cabeça futuras com lentidão de índices.

Precisa gerar chaves para seus testes locais? O DevThru oferece utilitários rápidos para o seu fluxo de desenvolvimento:

• Gere chaves v1, v4 e v7 instantaneamente com o Gerador de UUID do DevThru.
• Gere timestamps e faça conversões no Conversor de Timestamp.
• Formate e valide suas tabelas de migração de forma limpa no SQL Formatter.