35+ ANOS NO MERCADO
Operando ininterruptamente desde 1990. Mais de 25.000 horas de consultoria entregues e 596+ incidentes críticos resolvidos em produção. Pattern recognition que só vem com décadas de operação real.
PERFORMANCE TUNING POSTGRESQL — DESDE 2008
Quase nunca é autovacuum. É plano que mudou depois do ANALYZE, é seq scan em tabela com índice ignorado, é bloat acumulado em UPDATE-heavy, é conexão sem pooler segurando 800 sessions. A gente lê o pg_stat_statements e mostra.
DBAs PostgreSQL confiados por
O DIAGNÓSTICO ERRADO
AWS recomenda subir de db.r6g.4xl pra 8xl
Dobra a fatura mensal. E se o gargalo é uma query que faz Bitmap Heap Scan em 50M de tuplas porque o ANALYZE pegou amostra ruim, a instância maior só queima dinheiro.
Time olha CloudWatch, ignora pg_stat_statements
CPU médio em 70% não diz nada. O que mata é a query top-1 que sozinha consome 38% do tempo total de DB. pg_stat_statements diz em 2 minutos qual é.
Autovacuum atrasado, bloat em silêncio
Tabela com 200GB sendo 140GB de bloat. SELECTs lendo páginas vazias. VACUUM FULL trava produção. Sem tuning por tabela do autovacuum_vacuum_scale_factor, o problema volta.
Connection pooling existe, ninguém usou
Aplicação abrindo 600 conexões diretas no Postgres. Cada conexão = um processo. RAM esgota, OOM killer mata o postmaster. PgBouncer em transaction mode resolve em 1 dia.
ESCOPO TÉCNICO
Não é "rodar VACUUM e rezar". É análise de pg_stat_statements, autovacuum tunado por tabela, EXPLAIN ANALYZE com BUFFERS, e prova de redução em latência p95 medida com pg_stat_statements snapshot comparativo.
Análise das top 20 queries por total_exec_time. Identificação de N+1, planos suboptimal, queries com I/O desproporcional. Snapshot baseline vs incident.
autovacuum_vacuum_scale_factor ajustado por tabela quente, autovacuum_analyze_scale_factor para preservar planos, vacuum_cost_limit para não trapacear no I/O.
pg_repack online em produção sem bloqueio, identificação de bloat com pgstattuple, estratégia de prevenção via fillfactor e HOT updates.
EXPLAIN (ANALYZE, BUFFERS, VERBOSE), identificação de underestimates de cardinality, CREATE STATISTICS para correlação, hint via pg_hint_plan quando necessário.
PgBouncer em transaction mode, dimensionamento de pool por carga real, monitoramento de pool exhaustion, integração com RDS Proxy quando faz sentido.
Declarative partitioning por range/list/hash, partition pruning em queries reais, manutenção automatizada de partições novas, BRIN em séries temporais.
ESPECIALISTAS POSTGRES
Não é dev que aprendeu Postgres lendo blog. É DBA com track record em produção desde a versão 8.4, hoje 16, em sala física controlada no PIT/SP.
pg_stat_statements é o seu raio-X. Se ninguém leu nos últimos 30 dias, o problema está te esperando.
RESULTADOS MENSURADOS
FINTECH SÉRIE B
API de checkout
Latência p95 da API de checkout em PostgreSQL 14 reduzida de 850ms para 170ms com 3 índices criados, 1 query reescrita e PgBouncer em transaction mode.
SAAS B2B
Bloat removido
Tabela de eventos de 200GB com 70% de bloat reduzida para 60GB com pg_repack online, sem janela de manutenção, e autovacuum tunado para prevenir reincidência.
E-COMMERCE
Custo mensal
Downgrade de Aurora PostgreSQL r6g.4xl para r6g.2xl após tuning de 8 queries top, sem perda de performance, economia anual de US$ 78K.
METODOLOGIA
Coleta pg_stat + EXPLAIN
Você exporta pg_stat_statements, pg_stat_user_tables, log de auto_explain e config postgresql.conf. Sem precisar dar acesso ao ambiente.
Diagnóstico técnico
Top queries por tempo total, identificação de bloat e estatística desatualizada, análise de connection pattern. Relatório com root cause documentado.
Plano de fix priorizado
Scripts de índice, ajuste de autovacuum por tabela, pg_repack quando necessário, deploy de PgBouncer. Ordenado por ROI.
Aplicação supervisionada
Homologação com workload realista, deploy em produção com rollback documentado. Relatório pós-fix com pg_stat_statements comparativo.
FAQ
Não. O diagnóstico inicial roda em pg_stat_statements export + pg_stat_user_tables + auto_explain log que você gera. Acesso só na fase de aplicação do fix, com usuário restrito e revogado ao fim.
Sim. Aurora PostgreSQL, RDS for PostgreSQL, Cloud SQL (GCP), Azure Database for PostgreSQL e Postgres on-premise. As ferramentas mudam pouco (Performance Insights vs ferramentas nativas), os princípios são os mesmos.
Postgres não tem plan baselines nativo como Oracle, mas trabalhamos com 3 estratégias: extended statistics para correlações, plan stability via pg_hint_plan quando crítico, e monitoramento contínuo de pg_stat_statements para detectar regressão antes do usuário.
pg_repack. Reorganiza tabela online sem locks de longa duração. Executa em paralelo, troca tabela atomicamente ao final. Usamos em produções com SLA 99.9% sem janela.
Sim, mas com a recomendação técnica de planejar upgrade. 9.6 e 10 estão fora de suporte, 11 sai em 2024. Tuning continua funcionando, mas várias melhorias de planner só vêm em 13+.
20 minutos com um DBA Senior PostgreSQL. Você manda o export de pg_stat_statements, a gente devolve diagnóstico técnico. Sem formulário comercial.
Versões e plataformas atendidas
POR QUE A HTI
Desde 1990 sustentando ambientes críticos no Brasil. Não somos uma consultoria genérica que aprendeu banco de dados — somos The Database Company.
Operando ininterruptamente desde 1990. Mais de 25.000 horas de consultoria entregues e 596+ incidentes críticos resolvidos em produção. Pattern recognition que só vem com décadas de operação real.
Único MySQL Authorized Education Center (AMEC) da Oracle University no Brasil — conquista obtida duas vezes. Mais de 1.000 DBAs formados em cursos oficiais HTI.
DBAs em sala de acesso restrito no PIT de São José dos Campos: câmeras 24h, acesso biométrico, rack dedicado. Sem freelancer remoto, sem estação improvisada. Compliance que vai além da política interna.
Monitoramento comportamental desenvolvido internamente. Detecta padrões anômalos de ingestão e acessos a objetos protegidos — sem dependência de ferramenta de terceiro.