A latência escondida dentro do seu banco de dados: o peso do armazenamento em rede

O texto de Simeon Griggs, da PlanetScale, parte de um ponto que passa batido: mesmo com a aplicação colada no banco, existe latência de rede dentro do cluster. Na maioria dos bancos em nuvem, o disco é um network-attached storage (no caso da AWS, o EBS), e no hardware atual uma placa Nitro dedicada transforma cada leitura e escrita em requisição de rede.

A alternativa são os discos NVMe locais de certos tipos de instância EC2, sem salto de rede. O custo é que o armazenamento morre junto com o computador, tem tamanho rígido e não replica sozinho. No PlanetScale Metal, cada cluster tem um primário e ao menos duas réplicas, cada uma em sua VM e zona de disponibilidade, e o commit só é confirmado ao cliente depois de reconhecido em pelo menos uma réplica. Há um salto de rede por commit, mas leituras não cruzam a rede. Em falha, a réplica é promovida: no Vitess as queries ficam em buffer, no Postgres isso acontece via PgBouncer.

Sobre números, o autor compara, nos benchmarks de Postgres 17 vs 18, um r7i com volume io2 de 700 GB a 16.000 IOPS (US$ 1.513,82 por mês sob demanda) com um i7i de 1,8 TB de NVMe local, na casa de 300.000 IOPS (US$ 551,15). O limite padrão de IOPS no EBS é 3.000. Também afirma que, em alguns casos, o uso de CPU saiu de 20-25% para 80% ou mais após a migração para Metal.

Para quem opera banco em produção, a leitura prática é diagnóstica: olhe o cache hit ratio, os limites de IOPS e a relação entre CPU baixa e latência alta antes de decidir. Se o working set cabe na RAM e a escrita é baixa, o ganho do NVMe local tende a ser pequeno, como o próprio texto admite. É conteúdo de um fornecedor, então vale validar com o seu workload.