“Qual banco da AWS é mais rápido?” é a pergunta errada para começar. A pergunta útil é qual modelo operacional atende recuperação, compatibilidade, controle e custo com a menor complexidade evitável. RDS, Aurora e EC2 sustentam cargas PostgreSQL sérias, mas transferem responsabilidades muito diferentes para a AWS.
Árvore de decisão: elimine primeiro os modelos incompatíveis
Vence a opção menos complexa que passa compatibilidade, SLO, recuperação e custo com carga representativa.
Comece pelas restrições, não pelo produto
Documente versão, extensões, necessidade de superuser ou SO, pico de conexões, working set, taxa de escrita, crescimento, réplicas, recuperação entre Regions, RPO/RTO, janelas e capacidade da equipe. Uma dependência indispensável de extensão ou filesystem pode eliminar um serviço gerenciado antes do benchmark.
| Dimensão | RDS PostgreSQL | Aurora PostgreSQL | PostgreSQL no EC2 |
|---|---|---|---|
| Operação | Backup, patch e failover gerenciados | Cluster e storage distribuído gerenciados | Cliente opera toda a pilha |
| Compatibilidade | Próximo do PostgreSQL comunitário, dentro dos limites do RDS | Compatível; valide comportamento e extensões | Distribuição e extensões sob seu controle |
| Controle | Sem SO ou superuser real | Sem SO ou superuser real | Controle completo do SO e banco |
| HA | Opções Multi-AZ de instância ou cluster | Storage do cluster entre AZs, writer e readers | Você projeta replicação, fencing e failover |
Separe data plane de control plane
O data plane executa SQL, mantém buffers e persiste WAL/dados. O control plane provisiona, aplica patches, faz backup, substitui e promove. Serviços gerenciados transferem boa parte do control plane à AWS, mas sua equipe continua dona de schema, SQL, índices, conexões, parâmetros, acesso e aceite da recuperação. “Gerenciado” remove mecânica indiferenciada; não remove engenharia de banco.
RDS: gerenciado e previsível
O RDS costuma ser o destino de menor atrito para cargas comunitárias que usam extensões suportadas. Trate Multi-AZ como disponibilidade, não escala de leitura; use read replicas quando a aplicação tolera lag e diferenças de read-after-write. Parameter groups, manutenção, backup, deletion protection e política de minor versions precisam ser decisões explícitas.
Identifique exatamente o deployment comparado. O standby de uma instância Multi-AZ tradicional serve à disponibilidade e não é endpoint de leitura da aplicação. Read replicas são componentes assíncronos, com lag observável. Multi-AZ DB clusters expõem outros comportamentos de writer/readers. O desenho deve nomear opção, endpoints e consistência, não apenas escrever “Multi-AZ”.
Aurora: teste a carga completa
A arquitetura do Aurora pode ser atraente para failover, gestão do storage e múltiplos readers. Teste comportamento com escrita intensa, estabilidade de planos, tempestade de conexões, recuperação do driver após failover, lag, paridade de extensões e economia de I/O. Um benchmark de uma única query não representa a mistura da produção.
Aurora separa instâncias de compute de um volume distribuído compartilhado pelo cluster. Isso muda falha e replicação, mas os limites vistos pelo PostgreSQL continuam relevantes: um writer por vez em clusters provisionados comuns, visibilidade nos readers depois da escrita, aquecimento de buffer, planos e seleção do endpoint. Modele workloads sensíveis a I/O com a configuração de preço aplicável e teste failover com tráfego.
EC2: controle também gera uma conta operacional
EC2 se justifica por requisitos de controle, não apenas para evitar o preço visível do RDS. Inclua horas da equipe para AMIs, patch, backup, PITR, replicação, monitoramento, automação do failover, prevenção de split brain e simulações. Use instâncias EBS-optimized, separe capacidade de latência e valide qualquer hipótese de burst.
Um desenho EC2 confiável nomeia o gerenciador de replicação, consenso/fencing, catálogo de backup, arquivo de WAL, automação de restore e patches. Duas instâncias transmitindo WAL não formam HA até a promoção ser exclusiva, clientes acharem o novo primary, o antigo não aceitar escrita e o nó falho poder voltar com segurança.
Conexões, memória e planos decidem a performance real
Cada backend PostgreSQL consome memória e escalonamento. Pools dimensionados separadamente podem esmagar o banco após autoscaling. Trate conexões como orçamento global: reserve sessões administrativas, limite cada serviço, use transaction pooling quando compatível e aplique timeouts de conexão/query/transação. RDS Proxy ou PgBouncer reduzem churn, mas não corrigem transação lenta ou retry inseguro.
Mudar família altera vCPU, memória, rede e, às vezes, arquitetura. Isso muda cache, paralelismo e relações de custo do otimizador. Compare distribuição por query e estabilidade dos planos, não apenas TPS total.
Projete a falha e observe a recuperação
Mantenha o banco privado entre Availability Zones, criptografe com KMS, exija TLS e controle entrada por referência de security group. Dimensione pools como um orçamento para toda a frota. Alerte CPU, memória, storage, fila e conexões, mas também acompanhe latência por query, locks, WAL, vacuum, bloat e replicação. Teste reboot, failover, rotação de segredo, restore e reconexão da aplicação trimestralmente.
Arquitetura não é checkbox: Multi-AZ não prova que a aplicação reconecta, snapshot não prova tempo de restore e read replica não prova consistência. Só o exercício valida o sistema.
Use um scorecard no benchmark
| Gate | Teste | Evidência |
|---|---|---|
| Compatibilidade | Restaurar schema/dados, extensões, jobs e grants | Zero bloqueio sem solução e workarounds documentados |
| Performance | Mix de pico, distribuição real e pools | p95/p99 por fingerprint crítico e folga de saturação |
| Recuperação | Falhar writer, simular AZ e restaurar PITR | RTO/RPO medidos e timeline de erro/retry da aplicação |
| Economia | Cenários normal, pico e crescimento por 12–36 meses | Compute, storage, I/O, backup, rede, licença e trabalho |
Sequência de decisão
- Escolha EC2 se um requisito essencial exige SO, superuser ou recurso não suportado.
- Caso contrário, avalie RDS como baseline operacional.
- Teste Aurora quando seu modelo de disponibilidade, storage ou leitura trouxer valor mensurável.
- Compare finalistas com dados, concorrência, failover e custo mensal completo de produção.
Como o PG Monitoring ajuda a escolher e operar a arquitetura
O PG Monitoring aplica o mesmo modelo de workload PostgreSQL a RDS, ambientes compatíveis com Aurora e self-managed. Na prova de conceito ele compara fingerprints, percentis, planos, waits, locks, cache, temporários, vacuum, replicação e capacidade, em vez de reduzir a escolha a CPU e TPS. Em produção, os mesmos baselines detectam regressões após mudanças de instância, mostram pressão no orçamento de conexões e confirmam que réplicas e manutenção cumprem metas.
Resultado prático: escolha a plataforma com evidência comparável do banco e preserve essa evidência depois do go-live. Agende uma revisão de arquitetura e workload PostgreSQL na AWS antes de uma decisão virar restrição de longa duração.