RDS PostgreSQL Fundamentals: Performance e Otimização

1. Introdução

O Amazon RDS (Relational Database Service) para PostgreSQL é uma solução gerenciada que simplifica a administração de bancos de dados PostgreSQL na nuvem. Neste post, vamos explorar os principais conceitos e funcionalidades que você precisa conhecer para trabalhar com esta poderosa ferramenta.

1.1. Performance: o que realmente importa

O desempenho do seu RDS depende de dois pilares:

1. Classe da instância - CPU, memória e rede
2. Tipo de armazenamento - Throughput de I/O

1.2. Escalabilidade: os números

O RDS oferece escalabilidade independente para computação e armazenamento:

2. Escolhendo a classe de instância certa

A escolha da classe de instância é crucial para obter o melhor equilíbrio entre performance e custo. O RDS oferece diferentes famílias de instâncias, cada uma otimizada para cenários específicos.

• General Purpose: Workloads menores ou com padrões de uso variável
• CPU Optimized: Tarefas que demandam alto poder computacional
• Memory Optimized: Queries intensivas em memória e grandes conjuntos de dados em cache
• Graviton: Melhor escolha na maioria dos casos.

2.1. Como escolher?

A decisão depende das características da sua workload:

• Analise o gargalo atual: É CPU? Memória? I/O?
• Considere o padrão de uso: Constante ou variável?
• Avalie o custo-benefício: Graviton geralmente vence
• Teste em staging: Valide a performance antes de ir para produção

3. Tipos de armazenamento: EBS em ação

O RDS usa volumes EBS (Elastic Block Store) como storage. Pense no EBS como o HD/SSD do seu banco de dados na nuvem. Existem três opções principais, cada uma com características diferentes de velocidade e custo.

3.1. Antes de começar: o que é IOPS?

IOPS = Input/Output Operations Per Second (Operações de Entrada/Saída por Segundo)

Em português simples: quantas vezes por segundo seu banco consegue ler ou escrever dados no disco.

No banco de dados:

• Cada SELECT, INSERT, UPDATE = operações de I/O
• Mais IOPS = banco responde mais rápido
• Menos IOPS = queries ficam esperando na fila

Como saber quantos IOPS eu preciso?

• Monitore no CloudWatch - Métrica: ReadIOPS + WriteIOPS
• Se a soma está consistentemente acima de 80% do seu limite = hora de aumentar

3.2. GP2 (General Purpose SSD) - a opção legada

3.3. GP3 (General Purpose SSD) - escolha padrão

3.4. IO1 / IO2 Block Express - performance máxima

3.5. Comparação entre tipos de armazenamento

4. Auto storage scaling: deixe o RDS gerenciar

Uma das funcionalidades mais práticas do RDS é o auto-scaling de armazenamento. Configure uma vez e deixe o sistema expandir automaticamente quando necessário.

4.1. Quando o auto-scaling é acionado?

O RDS monitora seu banco 24/7 e dispara o auto-scaling quando detecta:

4.2. Proteção de cooldown (6 horas)

4.3. CloudWatch alarms essenciais

5. Otimização de custos

Performance é essencial, mas ninguém quer surpresas na fatura da AWS. A boa notícia? Você pode ter ambos - performance excelente E custos controlados.

• Estratégia 1: Escalonamento Dinâmico (Schedule-Based Scaling):
  • Opção 1: AWS Lambda + Scheduler
  • Opção 2: AWS Systems Manager (sem código)
  • Opção 3: Ferramentas de terceiros: AWS Instance Scheduler, CloudHealth ou Terraform com cron jobs
• Estratégia 2: Reserved Instances (RIs): Se você TEM CERTEZA que vai usar RDS por 1-3 anos, RIs são dinheiro grátis na mesa.
• Estratégia 3: Graviton: Migrar para Graviton é provavelmente a otimização mais fácil com maior ROI
• Estratégia 4: Storage - GP2 → GP3: Migração simples com economia imediata de ~20%.
• Estratégia 5: Revise Read Replicas: Read replicas são ótimas para performance, mas cada uma duplica seus custos de computação.

6. Configuração do RDS: Parameter Groups e conexões

Se você já trabalhou com PostgreSQL “tradicional” (instalado em um servidor), sabe que configurar o banco envolve editar arquivos de texto. No RDS, a AWS simplificou (e em alguns casos complicou um pouco) esse processo.

6.1. PostgreSQL tradicional vs RDS

max_connections = 100
shared_buffers = 256MB
work_mem = 4MB
maintenance_work_mem = 64MB

# Quem pode conectar de onde e como
host    all    all    192.168.1.0/24    md5
host    all    all    10.0.0.0/8        trust

# 1. Edita o arquivo
sudo nano /var/lib/postgresql/data/postgresql.conf

# 2. Recarrega configuração
sudo systemctl reload postgresql

# ou se precisar reiniciar
sudo systemctl restart postgresql

6.2. Parameter Groups

Pense em Parameter Group como um perfil de configuração para seu banco de dados.

┌─────────────────────┐
│  Parameter Group    │ ← Conjunto de configurações
│  "prod-default"     │
│                     │
│  max_connections=200│
│  shared_buffers=8GB │
│  work_mem=16MB      │
└──────────┬──────────┘
           │
           │ aplicado em ↓
           │
    ┌──────┴──────┐
    │ RDS Instance│
    │  meu-db-prod│
    └─────────────┘

6.2.1. Tipos de Parameter Groups

6.2.2. Tipos de parâmetros

Nem todos os parâmetros funcionam da mesma forma. Alguns podem ser alterados “na hora”, outros exigem reinicialização.

shared_buffers: 
  - O que é: Memória cache do PostgreSQL
  - Típico: 25% da RAM da instância
  - Exemplo: Em instância de 32 GB RAM → shared_buffers = 8 GB
  - Por que reboot: Memória é alocada na inicialização
  
max_connections:
  - O que é: Número máximo de conexões simultâneas
  - Típico: 100-500 (depende do workload)
  - Por que reboot: Estruturas de memória são pré-alocadas
  
wal_buffers:
  - O que é: Buffers para Write-Ahead Logging
  - Típico: -1 (auto, baseado em shared_buffers)
  - Por que reboot: Buffer é pré-alocado

work_mem:
  - O que é: Memória para operações de sorting/hash
  - Típico: 4-16 MB (cuidado: por operação!)
  - Pode ser: Alterado por sessão
  - Impacto: Imediato
  
maintenance_work_mem:
  - O que é: Memória para VACUUM, CREATE INDEX, etc
  - Típico: 256 MB - 2 GB
  - Pode ser: Alterado sem reboot
  - Impacto: Imediato
  
log_min_duration_statement:
  - O que é: Loga queries acima de X ms
  - Típico: 1000 (loga queries >1s)
  - Pode ser: Alterado por sessão
  - Impacto: Imediato

random_page_cost:
  - O que é: Custo estimado de leitura aleatória (SSD = 1.1)
  - Típico: 1.1 para SSD, 4.0 para HDD
  - Pode ser: Alterado imediatamente
  - Impacto: Afeta query planner

6.3. Conexões ao RDS

Security Groups fazem o trabalho de “quem pode conectar de onde”:

┌─────────────────────────┐
│   Security Group        │ ← Controla IPs/networks
│   "rds-prod-sg"         │
│                         │
│   Inbound Rules:        │
│   ✅ 10.0.1.0/24:5432   │ (rede de apps)
│   ✅ 203.0.113.5/32:5432│ (IP fixo admin)
│   ❌ 0.0.0.0/0          │ (resto bloqueado)
└────────┬────────────────┘
         │
         │ protege ↓
         │
  ┌──────┴────────┐
  │  RDS Instance │
  │  meu-db       │
  └───────────────┘

6.3.1. Métodos de autenticação no RDS

7. TLDR

Escolha de Instância

• Default: M6g (Graviton) - melhor custo-benefício
• CPU-heavy: M6g com classe maior
• Memory-heavy: R6g
• Dev/test: T4g (burstable)

Storage

• Use GP3 (não GP2!) para 90% dos casos
• Baseline grátis: 3.000 IOPS
• IO2 Block Express: Só se precisar >16k IOPS consistente

Auto-Scaling

• Sempre habilite
• Defina limite máximo (3-5x atual)
• Configure CloudWatch alarms (70%, 90%)

Otimização de Custos

• GP2 → GP3 (30 min, 20-50% economia storage)
• x86 → Graviton (1 semana teste, 20-40% economia)
• Reserved Instances (30 min, 30-54% economia baseline)
• Remover réplicas desnecessárias (economia variável)
• Downsize sobredimensionados (analise CPU <30%)

Parameter Groups

• 🚫 Nunca use default em produção
• Crie custom group
• Parâmetros essenciais:
  • shared_buffers = 25% RAM (static)
  • random_page_cost = 1.1 (dynamic)
  • work_mem = 16MB (dynamic)
  • log_min_duration_statement = 1000 (dynamic)

Conexões

• Security Groups controlam acesso de rede
• IAM Authentication recomendado (sem senhas hardcoded)
• Nunca exponha RDS publicamente (sempre em VPC privada)