UUID vs NanoID

Anatomia: o que existe dentro de cada ID

Os UUIDs codificam seus próprios metadados. Os bits 48–51 guardam a versão — 1 para tempo mais MAC, 4 para aleatório, 7 para aleatório ordenado por tempo — e dois bits adicionais fixam a variante. Um v4 sempre parece aleatório; um v7 começa com um timestamp legível, porque seus primeiros 48 bits são milissegundos desde a época Unix, e UUIDs cunhados no mesmo dia compartilham um prefixo.

Os NanoIDs não carregam metadados. Cada caractere é um sorteio independente do alfabeto, escolhido com mascaramento e amostragem por rejeição sobre o crypto.getRandomValues, para que cada símbolo permaneça igualmente provável. Essa pureza é o motivo de o formato ser flexível — mude o alfabeto ou o comprimento, mantenha o algoritmo — e de um NanoID não revelar nada sobre quando foi criado.

A matemática das colisões: por que nenhum dos dois colide

O limite do aniversário diz que um identificador aleatório de n bits atinge uma probabilidade de colisão de 50% perto de 2^(n/2) sorteios. Para o UUID v4, isso é aproximadamente 2^61 — cerca de 2.3 quintilhões de IDs — antes de as chances de um único duplicado chegarem à metade; os 126 bits do NanoID empurram o patamar um pouco além. Na prática, os dois são sistemas de nunca-acontece — qualquer duplicado que você encontrar é um bug de código, não um evento de entropia.

Essa equivalência é o motivo de o debate sobre tamanho importar menos do que se assume: 21 caracteres de NanoID não são mais seguros que um UUID v4 — a mesma garantia em menos bytes. Os motivos honestos para escolher são encaixe operacional — armazenamento, URLs, ferramentas — não risco de colisão.

Bancos de dados: o problema da localidade de índice

Insira uma chave aleatória em um índice B-tree e a linha pode cair em qualquer página; preencha páginas pela metade em ordem aleatória e cada inserção arrisca um page split, escritas extras e um cache mais frio. Esse é o imposto de fragmentação que tanto o UUID v4 quanto o NanoID pagam — NanoID incluído, porque é igualmente aleatório. Em uma chave primária indexada em escala de escrita intensa, nenhum dos dois é amigável ao índice por padrão.

O UUID v7 é a correção que já vem dentro do padrão: seus 48 bits iniciais são um timestamp em milissegundos, então as chaves novas quase sempre se ordenam na borda direita do índice. O NanoID não pode oferecer isso: sem componente de tempo, nada pelo qual ordenar. Em uma coluna indexada, a escolha real é v7 contra todo o resto.

• v4 e NanoID espalham inserções pela árvore — page splits e cache misses em escala.
• O tipo uuid do Postgres armazena 16 bytes brutos; uma chave de texto de 36 caracteres armazena 37 ou mais.
• A vantagem textual do NanoID — 21 caracteres contra 36 — vale apenas enquanto o alfabeto permanece documentado.

URLs, alfabetos e o seletor de comprimento

O alfabeto do NanoID é seguro para URL por construção: A-Za-z0-9_- não precisam de percent-encoding em nenhum ponto de uma URL, então um ID pode ser um segmento de caminho, valor de query ou slug sem nenhum escape. UUIDs são tecnicamente seguros para URL também — dígitos hexadecimais e hifens nunca precisam de codificação — mas 36 caracteres é muita string visível para um link.

O alfabeto personalizado é o recurso mais prático do NanoID: códigos só com números, links curtos em minúsculas — troque os 64 símbolos, mantenha o algoritmo. Respeite a regra de que a entropia é o comprimento vezes o log2 do tamanho do alfabeto: um NanoID minúsculo de 8 caracteres tem cerca de 38 bits, ok para um código de uma hora, imprudente como chave primária. UUIDs não oferecem esse seletor; o formato é fixo em 128 bits.

Quando escolher cada um

Escolha UUIDs quando o ID vive na infraestrutura: chaves primárias de banco de dados (v7), intercâmbio entre equipes e fornecedores, qualquer coisa que um terceiro precise validar, qualquer lugar em que um recurso embutido vença uma dependência. O padrão é o produto — toda linguagem, ORM e banco de dados já o fala.

Escolha NanoID quando o ID é visível para o usuário: URLs curtas, links de convite, nomes de arquivo, valores de cookie, IDs de requisição em logs. A orientação se inverte com clareza — se você vive brigando com a largura de um UUID dentro de uma URL, esse link quer NanoID; se você se pega reimplementando NanoID em um backend cujo banco de dados poderia servir chaves nativamente, essa coluna quer um UUID v7.