UUID v4 vs v7: qual usar como chave primária

Comparação direta

Por que o v4 pesa no banco

Índices de banco costumam ser árvores B, otimizadas para inserção ordenada. Uma chave sequencial sempre entra na última página, que já está em memória.

Um UUID v4 cai em qualquer ponto do índice. Cada inserção pode tocar uma página diferente, o que aumenta a leitura de disco, provoca divisão de páginas e faz o índice crescer mais do que precisaria. Em tabelas pequenas isso é irrelevante; em milhões de linhas, aparece.

O UUID v7 resolve começando por um timestamp: identificadores gerados em sequência ficam próximos, e a inserção volta a ser no fim do índice.

Como escolher

• Chave primária de tabela que vai crescer muito: v7
• Identificador público em que o momento da criação não deve vazar: v4
• Token, nome de arquivo, identificador de correlação: v4 resolve bem
• Registros criados offline que precisam ser ordenados depois: v7
• Ambiente que ainda não suporta v7: v4, ou ULID, que tem a mesma ideia com outra codificação

Gerando nas principais linguagens

// v4 nativo, no navegador e no Node moderno
const id = crypto.randomUUID();

// v7 exige biblioteca, por enquanto
import { uuidv7 } from "uuidv7";
const ordenavel = uuidv7();

-- PostgreSQL 18 tem uuidv7 nativo
SELECT uuidv7();

-- Em versões anteriores, gen_random_uuid() devolve v4
SELECT gen_random_uuid();