M9g com Graviton5 no RDS PostgreSQL rende 20% mais consultas por dólar que o M8g

Em números

• 92% mais queries por dólar: ganho de price-performance do M9g (Graviton5) sobre o M6g (Graviton2) no benchmark Sysbench publicado pelo AWS Database Blog.
• 121% mais QPS: o M9g chegou a 61.495 queries por segundo contra 27.816 do M6g no mesmo teste OLTP read/write.
• 55% menos latência p95: de 89,16 ms no M6g para 40,37 ms no M9g, medidos do lado do cliente Sysbench.
• 20% mais queries por dólar do M9g sobre o M8g (Graviton4), a geração anterior, o salto que importa pra quem já migrou recentemente.

A decisão

Toda vez que a AWS libera uma geração nova de Graviton para o Amazon RDS, quem opera banco em produção enfrenta a mesma pergunta: vale trocar a instância agora ou esperar o próximo ciclo? O AWS Database Blog tentou responder isso de forma objetiva: comparou as quatro gerações disponíveis para Amazon RDS for PostgreSQL (db.m6g.xlarge/Graviton2, db.m7g.xlarge/Graviton3, db.m8g.xlarge/Graviton4 e db.m9g.xlarge/Graviton5) sob a mesma carga Sysbench, no mesmo tamanho de instância e no mesmo volume de dados.

A pergunta que interessa ao arquiteto não é "qual Graviton é mais rápido" (é sempre o mais novo), e sim quanto esse ganho custa em dinheiro e em esforço de migração, e se o M9g sequer está disponível na região onde a carga roda hoje. Essa segunda parte muda o veredito para quem opera em sa-east-1.

Lado a lado

O teste usou Sysbench com workload oltp_read_write.lua, 2 tabelas de 2 milhões de linhas cada, 100 threads e 30 minutos de execução (mediana de 5 rodadas), contra instâncias xlarge (4 vCPUs, 16 GiB) rodando PostgreSQL 17.10 em Single-AZ, com armazenamento Amazon EBS io2 fixo (10.000 IOPS provisionadas, 200 GiB) para isolar o efeito do processador.

Dois pontos chamam atenção na tabela. O salto de QPS entre db.m7g.xlarge e db.m8g.xlarge (+45%) foi maior do que entre db.m8g.xlarge e db.m9g.xlarge (+30%), o que sugere que o Graviton4 já tinha sido um upgrade incomum. E o custo por hora cresce bem menos que o ganho de throughput: o M9g custa cerca de 15% mais que o M6g por hora, mas entrega mais que o dobro de QPS.

Quando escolher cada um

• Fique no db.m6g.xlarge ou db.m7g.xlarge se a carga já está estabilizada, o SLA está sendo cumprido e não há migração planejada para este trimestre; o ganho de price-performance não paga sozinho o risco de uma janela de manutenção fora de hora.
• Migre para db.m8g.xlarge se você ainda está em Graviton2/3 e a carga é CPU bound, como no teste do blog, com o dataset inteiro em memória; foi o maior salto entre gerações consecutivas medido no benchmark (+45% de QPS sobre o M7g).
• Vá direto para db.m9g.xlarge se está provisionando um ambiente novo, já tem um reboot ou failover planejado, e a carga roda em US East (N. Virginia), US East (Ohio), US West (Oregon) ou Europe (Frankfurt), as únicas regiões com M9g disponível até a publicação do benchmark.
• Não troque nada ainda se sua carga é limitada por I/O ou rede, não por CPU: o teste isola o efeito do processador mantendo o dataset em memória e saturando CPU, o que não reflete toda carga de produção, principalmente workloads com storage mais lento que o EBS io2 usado no benchmark.

Custo

A AWS publicou o benchmark com preços On-Demand de us-east-1, não de sa-east-1 (São Paulo). Isso importa duas vezes para quem opera no Brasil: além de pagar normalmente mais caro em São Paulo, o db.m9g.xlarge simplesmente não está disponível na região até a publicação do post, então a comparação de custo por consulta do M9g não tem como ser replicada ainda em produção local.

Os números de custo cobrem só a instância de computação. O armazenamento Amazon EBS io2 usado no teste (10.000 IOPS provisionadas, 200 GiB) é cobrado à parte e não entra na conta de queries por dólar: num ambiente real, a fatura de armazenamento costuma crescer junto com o volume de dados, não com a geração do processador, então o ganho percentual de price-performance tende a ser menor na fatura total do que nos 92% reportados para a instância isolada.

Para quem já está em db.m8g.xlarge, o cálculo prático é: o custo por hora sobe de $0,336 para $0,366 (cerca de 9% a mais), mas o volume de queries por dólar sobe 20%. Em uma carga que já satura CPU, isso normalmente significa poder reduzir o número de réplicas de leitura ou o tamanho da instância para manter a mesma capacidade, o que compensa o aumento de preço por hora.

Veredito

Se sua carga é OLTP, CPU bound, e roda em uma das quatro regiões com db.m9g.xlarge disponível, migrar para Graviton5 entrega o melhor custo por consulta hoje, com 92% mais queries por dólar que o Graviton2 e 20% a mais que o Graviton4. O caminho de migração é trocar a classe da instância via ModifyDBInstance: em Multi-AZ, a AWS promete downtime mínimo via failover automático; em Single-AZ, como no benchmark, é preciso reboot.

Se você opera em sa-east-1, o veredito muda: fique em db.m8g.xlarge por enquanto, porque ainda entrega 61% mais queries por dólar que o Graviton2 e está disponível na região. Monitore o anúncio de expansão de regiões do M9g antes de replanejar a migração.

Se sua carga é I/O bound ou a maior parte do tempo de resposta vem de rede, não de CPU, o ganho reportado pode não se repetir: o benchmark isola deliberadamente o efeito do processador. Antes de mudar a classe de instância em produção, vale rodar o próprio workload no template de CloudFormation que a AWS publicou no GitHub, que automatiza a criação do ambiente de teste e o Sysbench, inclusive para MySQL e MariaDB.

Fonte: AWS Database Blog