Consultoria PostgreSQL: o que realmente resolve performance e estabilidade em produção.

Uma tabela de 80GB que deveria ter 12GB. Esse tipo de número aparece em quase todo Health Check de PostgreSQL em escala: bloat acumulado por meses porque autovacuum rodava com a configuração padrão, em uma tabela com taxa alta de UPDATE e DELETE. Cada query precisa varrer seis vezes mais páginas do que deveria, o cache fica desnecessariamente ocupado, e o I/O paga a conta.

Ou o cenário inverso: a mesma query roda em 40ms em staging e em 6 segundos em produção. Mesmo schema, mesmo índice — só que as estatísticas do planner em produção refletem uma distribuição de dados muito diferente, e o plano escolhido pelo otimizador é outro. Quem nunca leu um EXPLAIN ANALYZE com calma trata isso como mistério.

PostgreSQL tem fama de "não precisar de DBA" — e essa percepção é exatamente o que causa os piores incidentes em escala. Para carga pequena ou média, o produto se sustenta sozinho. Quando o volume cresce, autovacuum, planner statistics, connection pooling e particionamento deixam de ser opcionais. Este artigo é um guia direto para quem está pesquisando antes de contratar consultoria Postgres séria.

Os sintomas abaixo aparecem quase sempre juntos em ambientes que cresceram rápido sem cuidado técnico de fundo:

1. Bloat de tabelas e índices por autovacuum subdimensionado

Em tabelas grandes com taxa alta de update/delete, o autovacuum padrão (autovacuum_vacuum_scale_factor = 0.2) só dispara quando 20% das linhas estão mortas — e em uma tabela de 100 milhões de linhas isso é tarde demais. O resultado é tabela e índice inchados, com páginas cheias de tuplas mortas que o planner continua tendo que percorrer.

2. Queries lentas em produção, rápidas em staging

Mesmo schema, mesmo índice, comportamento diferente. A causa quase sempre é estatística do planner desatualizada em produção (relação entre o número estimado e o real de linhas diverge muito), ou distribuição real dos dados diferente da amostra que o planner conhece. ANALYZE manual em tabelas críticas, ajuste de default_statistics_target e leitura cuidadosa do EXPLAIN ANALYZE resolvem a maior parte dos casos.

3. Connection pool esgotado

Postgres usa modelo de processo por conexão — não threads. Cada conexão consome memória residente do SO. Em arquiteturas serverless e microsserviços, com centenas de instâncias abrindo conexões, o Postgres satura em max_connections e o servidor entra em swap muito antes de chegar perto do limite de CPU. Sem PgBouncer em transaction pooling, esse padrão é inevitável.

4. Replicação em streaming com lag crescente

A primária aceita writes mais rápido do que a réplica consegue aplicar. Causas comuns: WAL volume crescendo (long-running transactions, autovacuum trabalhando), réplica subdimensionada, rede com latência ou banda insuficiente, ou réplica acumulando queries longas que conflitam com aplicação do WAL (hot_standby_feedback, max_standby_streaming_delay).

5. Falta de particionamento em tabelas de eventos/logs

Tabela de eventos crescendo indefinidamente vira problema de manutenção: vacuum demora mais a cada execução, DELETE para limpar dados antigos gera bloat enorme, e qualquer ALTER TABLE vira janela de manutenção. Em Postgres moderno, particionamento declarativo por RANGE em data transforma "deletar dados de 6 meses atrás" em DETACH PARTITION + DROP TABLE instantâneo, sem bloat.

6. Locks inesperados em migrations de schema

ALTER TABLE em tabela grande pode adquirir ACCESS EXCLUSIVE LOCK e bloquear leituras e escritas inteiras enquanto a operação não termina. Em ambientes de deployment contínuo, isso vira incidente quando o time esquece que "adicionar uma coluna" não é grátis em Postgres antes da versão 11 — e mesmo nas versões modernas algumas formas de ALTER continuam bloqueantes.

7. pg_stat_statements nunca habilitado

Sem pg_stat_statements ligado, não há como responder "quais são as 10 queries que mais consomem tempo total no ambiente?". Qualquer investigação vira amostra de slow log pontual, perdendo o padrão. Habilitar o módulo é uma linha em postgresql.conf — ignorar essa linha é, na prática, escolher operar no escuro.

"Postgres é robusto por padrão. Robusto por padrão também significa que ninguém olha — até o problema já estar grande."

Cada bloco abaixo precisa entregar evidência — saída de DMV, plano de execução, métrica de bloat, número de pages mortas — não conclusão isolada.

Auditoria de autovacuum e bloat

Bloat é espaço ocupado por tuplas mortas (deletadas ou versões antigas de updates) que o vacuum ainda não recuperou. Identificar bloat real requer pgstattuple (preciso, mas pesado) ou queries baseadas em pg_stat_user_tables (n_dead_tup, last_autovacuum) para uma estimativa rápida do conjunto inteiro.

O ajuste de autovacuum é por tabela — não global. Em tabelas críticas, baixar autovacuum_vacuum_scale_factor de 0.2 para 0.02 (ou menos) faz o autovacuum disparar muito antes do bloat acumular. Subir autovacuum_vacuum_cost_limit de 200 para 2000+ aumenta a velocidade do vacuum quando ele roda, evitando que ele fique correndo atrás do prejuízo. Ambos os ajustes valem por tabela via ALTER TABLE ... SET (...):

Tuning de queries via EXPLAIN ANALYZE

EXPLAIN sozinho mostra o plano estimado — o que o planner pretende fazer. EXPLAIN ANALYZE executa a query e mostra o plano real, com linhas estimadas vs. reais e tempo gasto por nó. Divergência grande entre estimativa e realidade aponta estatística desatualizada ou predicado complexo que o planner não consegue estimar bem.

Seq Scan nem sempre é problema — em tabela pequena ou em query que de fato precisa percorrer tudo, é a escolha certa. Seq Scan em tabela grande com filtro seletivo é problema: falta índice, ou o índice existe mas o predicado está escrito de forma não-sargable. Em alguns casos, a solução não é índice B-tree comum: índice parcial (CREATE INDEX ... WHERE status = 'ativo') cobre só as linhas que importam; índice GIN resolve busca em arrays, JSONB e full-text search; índice GIST cobre dados geométricos e ranges. Escolher a estrutura errada pode deixar a query rodando como se o índice não existisse.

Connection pooling e arquitetura

Postgres usa um processo do SO por conexão. Cada conexão custa memória residente real (5-15MB típicos), e contention em locks internos cresce com o número de conexões ativas. Em arquitetura de microsserviços ou serverless — onde dezenas a centenas de instâncias podem abrir conexões simultaneamente — encostar em max_connections é questão de tempo.

PgBouncer em transaction pooling resolve isso multiplexando milhares de conexões de cliente em poucas dezenas de conexões físicas com o Postgres. Em ambiente cloud gerenciado, esse desenho impacta diretamente custo — instâncias menores atendem mais carga real, evitando o reflexo de "subir o tier" que vira o custo descrito no guia de redução de custo em cloud (AWS/Azure RDS).

Replicação e alta disponibilidade

Streaming replication é o mecanismo nativo: primária envia o WAL para uma ou mais réplicas que aplicam em tempo quase real. Em modo assíncrono (padrão), a primária confirma o commit sem esperar a réplica — latência mínima, janela pequena de perda em failover. Síncrono (synchronous_commit = on + synchronous_standby_names) espera ao menos uma réplica confirmar o WAL — RPO próximo de zero ao custo de latência adicional por commit.

Para failover automático em ambientes que exigem alta disponibilidade, Patroni é hoje o padrão de fato. Ele usa um sistema externo de consenso (etcd, Consul, ZooKeeper) para eleger a primária e coordenar promoção. Combinado com PgBouncer e HAProxy no front, entrega failover transparente para a aplicação em segundos — desde que o exercício de failover seja rodado periodicamente, com cronômetro.

O Health Check de banco de dados é um diagnóstico fechado em até 48h: análise de pg_stat_statements, top queries por tempo total e por I/O, auditoria de autovacuum e bloat, revisão de índices nas tabelas quentes, validação de backup/PITR e replicação, e relatório com plano de ação priorizado. Resolve "preciso entender em que estado meu ambiente está e o que atacar primeiro".

O DBA Remoto é sustentação contínua: NOC 24/7 com SLA por severidade, monitoramento proativo, tuning recorrente, gestão de backup e réplica/Patroni, e atuação preventiva. É o que evita que o bloat identificado no Health Check volte ao mesmo patamar em três meses — porque os parâmetros foram ajustados, mas o padrão de carga continuou evoluindo.

Confiar na fama de "Postgres não precisa de manutenção". Essa frase descreve a experiência inicial — não a operação em escala. Em produção real, autovacuum precisa ser ajustado por tabela, estatísticas precisam ser atualizadas em ritmo compatível com a carga, e bloat precisa ser monitorado ativamente.

Ignorar autovacuum até o bloat já estar crítico. Tratar bloat depois é caro: VACUUM FULL exige lock exclusivo (downtime), pg_repack exige espaço em disco extra equivalente à tabela. Ajustar autovacuum antes evita os dois cenários.

Não monitorar pg_stat_statements desde o início. Sem histórico de queries quentes, qualquer otimização é palpite. Habilitar o módulo no dia 1 do ambiente custa nada e dá visão completa de qual query consome quanto, ao longo do tempo.

Subestimar connection pooling em microsserviços. Equipe que veio de MySQL ou de aplicação monolítica frequentemente não percebe o impacto do modelo de processo por conexão do Postgres até a aplicação travar com FATAL: too many connections. PgBouncer não é detalhe de infra — é arquitetura.

Se o seu ambiente é MySQL em vez de PostgreSQL, veja nosso guia específico de consultoria MySQL; para ambientes Microsoft, o equivalente é o guia de consultoria SQL Server.

A HTI Tecnologia é "The Database Company" desde 1990, e o PostgreSQL é hoje uma das tecnologias atendidas — em on-premises, em IaaS, em Amazon RDS for PostgreSQL, em Amazon Aurora PostgreSQL-compatible e em Supabase. A entrega em Postgres apoia na mesma metodologia de DBA que sustenta os outros RDBMSs:

Health Check tático e Assessment estratégico. O Health Check é o diagnóstico fechado em 48h. O Assessment estratégico vai além — desenha o roadmap técnico do ambiente (versão, arquitetura de replicação, particionamento, plano de DR, modelo de monitoramento) com horizonte de 12-24 meses.

NOC 24/7 com SLA por severidade. Operação a partir de sala física controlada com acesso biométrico, NDA padrão antes de qualquer acesso, e trilha de auditoria por operador. SLA com penalidade contratual, não discurso comercial.

DBSnoop aplicado a Postgres. Ferramenta proprietária de monitoramento comportamental que correlaciona comportamento de queries, padrões de acesso e métricas de instância — útil tanto em Postgres on-premises quanto em RDS/Aurora e Supabase, onde a visibilidade nativa para de no que o serviço gerenciado expõe.

Consultoria PostgreSQL bem feita não é mística — é método. Diagnóstico com evidência (pg_stat_statements, EXPLAIN ANALYZE, métricas de bloat), ajuste de autovacuum por tabela e não no global, connection pooling tratado como arquitetura, e plano de DR com failover exercitado periodicamente.

Se algum dos sinais descritos no início descreve o seu ambiente, faz sentido conversar com um DBA Senior antes do próximo pico de carga.