PlanetScale Metal usa NVMe local para cortar latência de disco e custo frente ao EBS

A tese do texto da PlanetScale, publicado em 3 de novembro de 2026, é que existe uma latência de rede dentro do próprio cluster do banco. Num setup comum de nuvem, você compra uma instância EC2 para compute e anexa um volume EBS. Em instâncias de geração atual, um cartão Nitro dedicado transforma cada leitura e escrita em requisição de rede. Um simples cache miss numa query de leitura já paga esse salto.

O PlanetScale Metal troca isso por NVMe local, fisicamente conectado ao host, sem hop de rede. O risco é conhecido: disco local vive e morre com o compute, tem tamanho rígido e não replica sozinho. A solução descrita é que todo cluster Metal tem um primário e pelo menos duas réplicas, cada uma em sua VM, com NVMe próprio, em zonas de disponibilidade distintas. O commit só é confirmado ao cliente depois de ser reconhecido por ao menos uma réplica. Há um hop por commit, mas as leituras não cruzam a rede. No failover, a réplica é promovida e as queries ficam em buffer (no Vitess direto, no Postgres via PgBouncer).

Sobre custo e IOPS: o EBS tem padrão de 3.000 IOPS. Nos benchmarks de Postgres 17 vs 18, um r7i com volume io2 de 700 GB provisionado para 16.000 IOPS custou US$ 1.513,82 por mês sob demanda. Um i7i com NVMe local de 1,8 TB, capaz de cerca de 300.000 IOPS, custou US$ 551,15. O texto também admite que você pode não precisar do Metal se a maior parte das leituras cabe em RAM e o volume de escrita é baixo. Sinais de que precisa: cache misses frequentes, limite de IOPS do EBS estourado, ou CPU baixa com latência alta (em alguns casos a CPU foi de 20-25% para 80% ou mais após a migração). O Insights mostra a taxa de cache hit.

A cobertura anterior sobre o mesmo texto, "A latência escondida dentro do seu banco de dados: o peso do armazenamento em rede", de 4 de novembro de 2026, já tratava a tese do NVMe local e a necessidade de replicação e failover bem planejados. Esta matéria acrescenta os números do benchmark e o recorte de custo e IOPS contra o EBS.

Para quem opera banco em nuvem, a leitura é que o gargalo pode estar no disco de rede, não na CPU. Se o seu monitoramento mostra CPU baixa e latência alta, vale checar cache hit ratio e uso de IOPS antes de aumentar a instância. A comparação de custo vem do benchmark do próprio fornecedor, então convém validar com a sua carga.