PostgreSQL em produção: o guia definitivo de operação e escala

Vou começar com a parte boa: o PostgreSQL ganhou. Ele é hoje o default de fato para projetos novos, tem extensibilidade que nenhum concorrente relacional chega perto e uma comunidade que entrega release todo ano sem quebrar o mundo.

Agora a parte que ninguém coloca no slide: PostgreSQL é fácil de começar e difícil de operar em escala. Depois de 25 anos cuidando de banco de dados dos outros, aprendi que quase todo incidente sério em Postgres cai em uma destas cinco caixas. Este artigo é o mapa. Cada caixa tem um artigo próprio, aprofundado, com código.

Antes de tudo: o diagnóstico de 5 minutos

Quando eu chego em um Postgres que não conheço, rodo este bloco antes de qualquer opinião. Ele responde 80% das perguntas iniciais:

-- 1. Tamanho e versão
SELECT version();
SELECT pg_size_pretty(pg_database_size(current_database())) AS tamanho_db;

-- 2. As 10 maiores tabelas (com índices)
SELECT relname AS tabela,
       pg_size_pretty(pg_total_relation_size(c.oid)) AS total,
       n_live_tup AS vivos,
       n_dead_tup AS mortos
FROM pg_class c
JOIN pg_stat_user_tables s ON s.relid = c.oid
ORDER BY pg_total_relation_size(c.oid) DESC
LIMIT 10;

-- 3. Conexões e o que está travando
SELECT state, count(*) FROM pg_stat_activity GROUP BY state;
SELECT pid, wait_event_type, wait_event, now() - query_start AS duracao, left(query, 80)
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY duracao DESC NULLS LAST
LIMIT 10;

-- 4. Replicação está viva?
SELECT client_addr, state, sent_lsn, replay_lsn,
       pg_wal_lsn_diff(sent_lsn, replay_lsn) AS bytes_atraso
FROM pg_stat_replication;

Se a coluna mortos estiver na casa dos milhões, pule direto para a seção de VACUUM. Se bytes_atraso estiver crescendo, vá para replicação. O banco costuma contar a própria história.

Dor 1 — Alta disponibilidade e replicação

Replicação física em Postgres é sólida. Failover automático confiável é que não vem na caixa. Você precisa de Patroni, repmgr ou equivalente, de um proxy de conexão, de fencing para evitar split-brain e de um plano testado de volta. Em ambientes híbridos (on-premise mais cloud), a latência entre nós transforma synchronous_commit em uma decisão de negócio, não de infraestrutura.

Aprofundamento: Alta disponibilidade e replicação no PostgreSQL: o que ainda dói.

Dor 2 — VACUUM e bloat

O MVCC do Postgres não atualiza linha: ele escreve uma nova e marca a antiga como morta. Alguém precisa recolher o lixo — e esse alguém é o autovacuum, que em tabelas de alta escrita simplesmente não acompanha. O resultado é bloat: tabela de 40 GB com 12 GB de dados úteis, índices inchados, planos degradando devagar. E, no limite, o temido wraparound de transaction ID.

Aprofundamento: VACUUM e bloat no PostgreSQL: o inimigo silencioso.

Dor 3 — O query planner imprevisível

Aquela query que roda em 30 ms há seis meses vira 40 segundos numa terça-feira, sem deploy, sem mudança de dados relevante. Estatística desatualizada, correlação entre colunas que o planner não enxerga, e pronto: Nested Loop onde deveria ter Hash Join. Postgres historicamente não tem query hints — o que é uma decisão filosófica defensável e um inferno operacional às três da manhã.

Aprofundamento: Query planner imprevisível: o pesadelo do DBA PostgreSQL.

Dor 4 — IA, embeddings e workloads vetoriais

O Postgres virou banco de vetores por acidente e por mérito: com pgvector, você guarda embeddings ao lado dos dados transacionais e faz RAG sem manter um segundo banco. O problema é que índice ANN (HNSW, IVFFlat) tem trade-off de recall versus latência que a maioria dos DBAs nunca precisou calibrar antes.

Aprofundamento: pgvector na prática: IA e busca vetorial no PostgreSQL.

Dor 5 — Segurança e conformidade

Autenticação via scram-sha-256, TLS obrigatório, Row Level Security, roles granulares, auditoria com pgaudit, patch aplicado no prazo. Tudo existe, tudo é nativo ou quase, e quase ninguém implementa direito. Com LGPD e regulações setoriais apertando, "depois a gente arruma" virou risco contratual.

Aprofundamento: Segurança e conformidade no PostgreSQL: LGPD na prática.

O checklist que eu deixo em toda consultoria

Área	Verificação mínima	Frequência
Backup	Restore testado de verdade (não só o backup rodando)	Mensal
Replicação	Lag monitorado, failover ensaiado	Trimestral
VACUUM	Dead tuples e idade de XID por tabela	Diária (alerta)
Planner	pg_stat_statements revisado, ANALYZE após cargas	Semanal
Segurança	Revisão de roles, patch de minor version	Trimestral

E se você veio do MySQL?

Muita gente cai aqui vindo do outro lado da cerca. Já comparei os dois em detalhe em MySQL ou PostgreSQL: qual escolher, e se a dúvida é mais conceitual, MySQL ou SQL: qual a diferença resolve. Quem quer fundamento de SQL com laboratório de verdade encontra em Aprendendo MySQL — o dialeto muda, o raciocínio de índice e plano de execução não.

---

Sobre o autor: Alexandre Almeida atua com bancos de dados há mais de 25 anos, foi instrutor oficial de MySQL e Oracle para mais de 1.000 alunos e escreveu Aprendendo MySQL: Prática, Teoria e Laboratórios. Os exemplos deste guia foram validados em PostgreSQL 16 e 17.

Fontes: PostgreSQL Documentation (High Availability, Routine Vacuuming, Planner Statistics, Client Authentication), notas de release do PostgreSQL 16/17, documentação do Patroni e do pgvector.