A migration pede chave e o `MAX(id)+1` já doeu. Escolha v4, v7, ULID ou NanoID e copie. Gerador de senha é outra URL — UUID vaza em log.
A tabela cresceu com inteiro sequencial e o sharding chegou. Ou o fixture do teste precisa de cinco ids agora. O trabalho é sortear identificadores nesta aba. A vantagem do produto: UUID v4, UUID v7, ULID e NanoID — não só o v4 clássico.
Nada sobe. Os valores nascem no navegador. Não é senha. Não é slug de URL.
Qual formato colar na migration
- v4: imprevisível. Bom quando o id é público e a hora de criação não pode vazar. Ruim como PK de tabela quente: o índice espalha.
- v7: prefixo temporal (RFC 9562). Melhor candidato a chave nova em 2026 se o banco e a lib entenderem. Postgres 18 já tem
uuidv7()nativo — esta aba é para o fixture e o rascunho, não para substituir o servidor. - ULID: a mesma ideia de tempo + aleatório, string mais curta, amigável em URL. Não espere coluna
uuidem todo SGBD. - NanoID: curto, alfabeto configurável na lib original. Aqui você gera o id; não é RFC e não é ordenável como v7.
v4 e v7 cabem no mesmo tipo uuid de 16 bytes. Dá para deixar linhas velhas em v4 e nascer v7 sem backfill. ULID e NanoID são outro contrato de string.
O que não misturar
Não trate o id como token de sessão. Não mande a connection string no mesmo Slack. Hash de arquivo é SHA-256, não um UUID. Documento da Receita não sai daqui.
Copie, cole no SQL ou no JSON, siga. Colisão “impossível” é conversa de blog; unique no banco é o que vale.
Nada é enviado. Isto não emite nota fiscal.