O que é este benchmark e por que importa

Escolher o tipo certo de instância EC2 para rodar o PostgreSQL e uma das decisões de infra que mais impacta tanto a performance quanto o custo de um produto. A diferença entre uma instância mal escolhida e a ideal pode ser de 3x a 5x no preço mensal, com performance equivalente ou até superior.

Um projeto chamado saneengineer.com realizou testes metódicos do PostgreSQL em 23 tipos diferentes de instâncias EC2, medindo transações por segundo, latência de leitura e escrita, e custo por operação. O resultado e um dos benchmarks mais práticos recentemente no Hacker News, com discussão acalorada sobre qual e a melhor escolha para diferentes cenários.

Para times brasileiros que hospedam seus bancos na AWS, esse tipo de dado e ouro: ele reduz o chute na hora de escolher a instância e da base para justificar investimentos de infra para stakeholders.

Como o benchmark foi feito

A metodologia usou o pgbench, ferramenta oficial de benchmark do PostgreSQL, com diferentes perfis de carga: leitura pura, escrita pura, e misto (o cenário mais comum em aplicações reais). Os testes rodaram na região us-east-1 da AWS, com o mesmo volume de dados e configurações de PostgreSQL padrão para tornar a comparação justa.

As instâncias testadas cobrem as famílias principais: t3, t4g, m6i, m6g, m7i, m7g, c6i, c6g, r6i, r6g e variantes. Isso inclui tanto instâncias x86-64 quanto ARM (Graviton), especialmente relevante dado o crescimento das instâncias Graviton na AWS.

O método de medição de custo por operação e simples mas poderoso: TPS dividido pelo preço horário da instância. Isso da um número comparável que responde diretamente a pergunta: quanto custa cada operação no banco?

💡
Dica

Ao comparar instâncias, sempre calcule custo por operação, não só custo horário. Uma instância 2x mais cara pode processar 4x mais queries, saindo mais barata no final.

Principais descobertas do benchmark

As famílias de instâncias Graviton (ARM64) da AWS, especialmente m7g e r7g, entregaram consistentemente o melhor custo por operação nos testes. Em alguns cenários, a economia em relação as equivalentes x86 foi de 30% a 40% mantendo a mesma performance.

Para cargas com muita leitura e pouca escrita (comum em dashboards e relatórios), instâncias da família r6g e r7g (otimizadas para memoria) mostraram vantagem clara. O PostgreSQL se beneficia muito de RAM extra para manter o working set em cache, reduzindo operações de disco.

Para OLTP puro (alta taxa de escrita, transações curtas), as instâncias da família c6g e c7g (otimizadas para CPU) entregaram melhor TPS. O custo por TPS ficou competitivo mesmo sendo instâncias com menos RAM.

⚠
Atenção

Instâncias t3 e t4g tem créditos de CPU que afetam os resultados em testes curtos. Para produção com carga constante, prefira famílias m, c ou r sem burst.

Como começar: rodando o benchmark na AWS

Você pode reproduzir esse tipo de teste no seu próprio ambiente AWS antes de migrar o banco de produção. O processo leva cerca de 1 a 2 horas para testar algumas instâncias candidatas.

Passo 1: Inicialize o banco de testes com pgbench em uma instância candidata:

apt-get install PostgreSQL PostgreSQL-contrib
pgbench -i -s 100 postgres

Passo 2: Rode o benchmark com diferentes perfis de carga:

pgbench -c 4 -j 2 -T 60 postgres
pgbench -c 4 -j 2 -T 60 -S postgres
pgbench -c 4 -j 2 -T 60 -N postgres

Passo 3: Divida o TPS pelo preço horário da instância para calcular custo por operação. Compare com outra instância candidata e escolha com dados reais do seu workload específico.

Exemplo prático: migrando de m5 para m7g

Um cenário comum e times que ainda usam instâncias m5 (geração anterior, x86) e consideram migrar para m7g (Graviton 3, ARM64). Veja como seria o processo de validação:

pgbench -c 4 -j 2 -T 120 postgres
# m5.large: latência media 2.3ms, TPS 1742
# m7g.large: latência media 1.9ms, TPS 2108
# Resultado: 21% mais rápido, 20% mais barato

O processo completo de validação leva entre 2 e 4 horas. A economia mensal justifica amplamente esse investimento de tempo.

🚀
Pro tip

Use o AWS Cost Explorer para estimar o impacto financeiro antes de migrar. Compare o preço On-Demand com Reserved Instances de 1 ano: a economia adicional costuma ser de 30% a 40%.

Comparação entre famílias de instâncias

t4g (Graviton 2, burstavel): ideal para desenvolvimento e bancos com carga irregular. Preço baixo, mas não adequado para produção com carga constante.

m7g (Graviton 3, propósito geral): melhor custo-beneficio para a maioria das aplicações OLTP. Equilíbrio entre CPU, memoria e preço. Recomendado como ponto de partida.

r7g (Graviton 3, memory-optimized): quando o working set do banco e maior que a RAM das instâncias m. Indicado para bancos acima de 50GB com alta taxa de leitura.

Pontos positivos e limitações

O ponto mais forte desse benchmark e a metodologia reproduzível: qualquer time pode rodar os mesmos comandos no próprio ambiente e validar os resultados. Isso e muito mais útil que benchmarks teóricos de fabricante.

A limitação principal e que pgbench com workload TPC-B não representa todos os tipos de aplicação. Bancos com muitos JOINs complexos, full-text search, ou JSON/JSONB intensivo podem ter resultados diferentes.

Outra limitação e a ausência de testes com disco otimizado (io2 Block Express vs gp3). A escolha do volume EBS impacta tanto quanto a instância em workloads de escrita intensa.

Casos de uso reais

Startups em crescimento: começar com m7g.large e escalar verticalmente até m7g.2xlarge antes de considerar read replicas. Essa trajetória e mais simples e económica do que sharding prematuro.

Produtos SaaS B2B: bancos com muitos tenants tendem a ter workloads mistos. r7g.xlarge costuma ser a escolha certa quando o banco passa de 30GB e a taxa de cache miss começa a subir.

Times de dados e BI: queries analíticas longas se beneficiam de c7g com muitos vCPUs. O paralelismo do PostgreSQL escala bem com mais cores em queries de agregação.

Aplicações com picos sazonais: considerar Reserved Instances base mais On-Demand para picos. A economia das Reserved no tipo certo de instância paga o custo extra dos picos On-Demand.

Dicas e boas práticas

💡
Dica

Antes de escolher a instância, rode EXPLAIN ANALYZE nas 10 queries mais lentas. Elas revelam se o gargalo e CPU, memoria ou I/O, o que direciona a escolha da família certa.

💡
Dica

Configure shared_buffers para 25% da RAM da instância e effective_cache_size para 75%. Esses dois parâmetros tem o maior impacto na performance sem precisar mudar hardware.

🚀
Pro tip

Use pg_stat_statements para identificar as queries que mais consomem CPU e I/O em produção. Otimizar essas queries vale mais do que qualquer upgrade de instância.

⚠
Atenção

Sempre teste a compatibilidade da sua aplicação com ARM64 antes de migrar para instâncias Graviton. A maioria das dependências modernas já suporta, mas extensões nativas precisam ser verificadas.

Vale a pena?

Para quem sim: qualquer time que paga por instâncias EC2 rodando PostgreSQL sem ter feito benchmarks próprios. A economia potencial de 20% a 40% no custo de banco de dados com a mesma performance justifica o investimento de tempo.

Para quem não (ainda): times com bancos de dados pequenos onde o custo de EC2 e irrelevante no orçamento total. Nesses casos, priorize simplicidade operacional sobre otimização de custo.

O benchmark original esta disponível em postgres.saneengineer.com para consulta interativa. Se você ainda usa instâncias m5 ou c5 e tem PostgreSQL na AWS, comece um teste agora. A barreira técnica e baixa e o retorno financeiro costuma ser imediato.