FRENTE 05 — OTIMIZAÇÃO DE BASE DE DADOS
O banco de dados é onde o sistema fica lento primeiro.
Antes de comprar um servidor maior ou reescrever a aplicação, vale olhar o banco. Na maioria dos sistemas que analisamos, o ganho de performance mais barato está em consultas mal escritas, índices ausentes e configurações padrão que nunca foram revisadas. Trabalho de especialista em PostgreSQL, com experiência em outros bancos relacionais.
DIAGNÓSTICO
Diagnóstico de performance
Antes de mexer em qualquer coisa, medir. O resultado é um relatório com os gargalos ranqueados por impacto e por esforço de correção.
- Análise das consultas mais custosas com pg_stat_statements e planos de execução (EXPLAIN ANALYZE) reais
- Investigação de bloqueios, esperas, conexões ociosas e contenção de recursos — CPU, memória, disco e rede
- Correlação entre lentidão percebida pelo usuário e o que o banco está fazendo naquele momento
- Relatório com o que atacar primeiro, o ganho esperado e o risco de cada mudança
ÍNDICES
Índices e consultas
A maioria dos ganhos grandes vem daqui. Cada mudança é medida antes e depois, em ambiente de teste, antes de ir para produção.
- Índices compostos, parciais e de cobertura desenhados para as consultas reais; GIN e GiST para texto, JSON e geolocalização
- Remoção de índices duplicados ou nunca usados, que só custam escrita e espaço
- Reescrita de consultas críticas e correção de padrões que ORMs geram sem avisar, como o N+1 e o SELECT *
- Paginação eficiente, agregações pré-calculadas e consultas que usam o plano certo
MODELAGEM
Modelagem e crescimento
Para sistemas que cresceram mais do que o banco foi desenhado para aguentar.
- Particionamento de tabelas grandes por data ou por cliente, com rotação e arquivamento de dados históricos
- Revisão do modelo de dados: normalização onde falta, desnormalização controlada onde ajuda
- Réplicas de leitura, views materializadas e cache para separar carga analítica da transacional
- Estratégia para tabelas de eventos, logs e séries temporais que crescem sem parar
OPERAÇÃO
Configuração e manutenção
Configuração padrão serve para começar, não para produção. O banco precisa ser ajustado ao hardware e à carga reais.
- Parâmetros de memória, paralelismo e I/O ajustados ao servidor e ao perfil de uso
- Autovacuum, estatísticas e controle de bloat para o desempenho não degradar com o tempo
- Pool de conexões (PgBouncer ou equivalente) para aplicações com muitas conexões curtas
- Rotinas de manutenção documentadas e automatizadas, para o seu time manter o que ficou bom
RESILIÊNCIA
Backup, recuperação e upgrade
Backup que nunca foi restaurado não é backup. E versão fora de suporte é risco esperando data.
- Backup contínuo com recuperação a um ponto no tempo e restaurações testadas periodicamente
- Upgrade de versão major com pg_upgrade ou replicação lógica, com janela mínima e caminho de volta
- Alta disponibilidade com réplica e failover, quando o negócio não pode parar
- Migração entre provedores — RDS, Aurora, Azure Database for PostgreSQL ou servidor próprio — sem perder dados
SEGURANÇA
Segurança e observabilidade
Quem acessa o quê, e como você fica sabendo quando algo sai do normal.
- Roles e permissões com menor privilégio; segurança em nível de linha (RLS) quando vários clientes dividem o mesmo banco
- Criptografia em trânsito e em repouso, segredos fora do código e auditoria de acesso
- Monitoramento com alertas de consultas lentas, crescimento anormal, réplica atrasada e espaço em disco
- Painéis que o seu time entende, com as métricas que importam para o negócio