FMFelipe MiillerNotes on software & systems
HomeBlogAbout
GitHub

Keep building.

Felipe Miiller · © 2026

MailGitHubGitHubLinkedinGitHub
View source on GitHub
Back to blog

UUIDv7 Ordem e Performance

27/05/2025
2 min de leitura
534 palavras
SQLDataBasePerformance
  • 🔢 O que é UUIDv7?
  • ⚡ Performance: PostgreSQL vs MySQL
  • ✅ PostgreSQL: onde UUIDv7 brilha
  • ⚠️ MySQL (InnoDB): melhora, mas não é milagre
  • 📊 Comparação
  • 🧠 Quando usar UUIDv7?
  • 🧪 Dica bônus: testando no seu projeto
  • 📌 Conclusão

Se você já trabalhou com bancos de dados e precisou de identificadores únicos, provavelmente conhece os UUIDs (Universally Unique Identifiers). Eles são ótimos para evitar colisões, especialmente em sistemas distribuídos, mas a versão tradicional (UUIDv4) traz sérios problemas de performance em bancos relacionais.

Com a chegada do UUIDv7, esse cenário começa a mudar — principalmente no PostgreSQL, mas não tanto no MySQL.


🔢 O que é UUIDv7?

O UUIDv7 é uma nova variante do UUID padronizada pela IETF e projetada para ser:

  • Baseada em timestamp: os bits iniciais representam o tempo, como um relógio.
  • Ordenável: os UUIDs são gerados em ordem crescente.
  • Globalmente únicos: mantêm as vantagens dos UUIDs tradicionais.

Exemplo de UUIDv7:

018f89b5-b64f-7b84-bf0a-9d4db6b33b18

Essa estrutura permite que bancos de dados mantenham os dados fisicamente ordenados por chave primária sem os problemas causados por UUIDv4, que são totalmente aleatórios.


⚡ Performance: PostgreSQL vs MySQL

✅ PostgreSQL: onde UUIDv7 brilha

O PostgreSQL usa índices do tipo B-tree por padrão para chaves primárias. Isso significa que:

  • Quando usamos UUIDv7 como chave primária (PRIMARY KEY), os dados inseridos seguem uma ordem crescente.
  • O PostgreSQL consegue manter o índice balanceado com mais eficiência.
  • A escrita é mais rápida, há menos fragmentação, e o uso de cache de páginas é otimizado.

Resultado: melhor performance em inserções e consultas do que UUIDv4.

⚠️ MySQL (InnoDB): melhora, mas não é milagre

O MySQL com InnoDB organiza os dados na ordem da chave primária (clustered index). Isso pode ser bom com chaves numéricas, mas com UUIDs:

  • Mesmo com UUIDv7, há alguma fragmentação de páginas.
  • O tamanho do UUID (16 bytes) ainda é maior que um BIGINT (8 bytes), o que impacta o tamanho dos índices e a velocidade de leitura.
  • Os benefícios são menores que no PostgreSQL.

📊 Comparação

CenárioPostgreSQLMySQL (InnoDB)
UUIDv4 como PRIMARY KEYRuim (desordenado)Ruim (fragmentação alta)
UUIDv7 como PRIMARY KEYÓtimo (ordenado)Razoável
BIGINT AUTO_INCREMENTÓtimo (sequencial)Ótimo (nativo)

🧠 Quando usar UUIDv7?

Use UUIDv7 quando você precisa de:

  • Identificadores únicos em sistemas distribuídos.
  • Ordenação natural por tempo.
  • Uma alternativa mais performática ao UUIDv4.

Recomendado:

  • ✅ PostgreSQL com UUIDv7 para chave primária.
  • ✅ MySQL com UUIDv7 apenas se realmente precisar de UUIDs (ex: replicação entre sistemas).
  • ⚠️ Prefira BIGINT auto-incremental se você puder abrir mão da aleatoriedade/distribuição.

🧪 Dica bônus: testando no seu projeto

Se quiser experimentar UUIDv7, há bibliotecas para diversas linguagens:

  • Node.js: uuidv7
  • Python: uuid6 (inclui v6/v7)
  • Go: github.com/jlourenc/uuid

No PostgreSQL, você pode armazenar UUIDs em colunas do tipo UUID, ou como CHAR(36) se preferir manter a versão textual.


📌 Conclusão

O UUIDv7 resolve um dos principais problemas dos UUIDs em bancos relacionais: a falta de ordenação. Com ele, você pode ter identificadores únicos e ordenados, melhorando consideravelmente a performance em sistemas como o PostgreSQL.

No MySQL, o ganho existe, mas ainda fica atrás do tradicional AUTO_INCREMENT. Avalie bem as necessidades do seu projeto para escolher o identificador mais adequado.