DBA Remoto PostgreSQL 24×7 — Quando vale a pena terceirizar?

"Contratar um DBA sênior ou terceirizar?" é uma das decisões mais caras da área de dados — e a mais adiada. Adia-se porque o time acha que dá para segurar mais um mês, adia-se porque contratar leva 90 dias, adia-se até a madrugada em que o banco cai e ninguém sabe o que fazer. Este guia coloca custo, cobertura e sinais práticos lado a lado para que a decisão saia do "achismo" e vire critério.

A HTI opera bancos PostgreSQL de missão crítica desde 1990 no modelo DBA Remoto PostgreSQL com NOC 24/7, SLA contratual e monitoramento comportamental via DBSnoop. Escrevemos este texto para quem está na dúvida honesta — não para vender terceirização a quem já tem estrutura funcionando.

A dúvida entre DBA interno e DBA Remoto não é técnica — é de gestão de risco e economia. O DBA interno oferece proximidade e domínio do negócio; o DBA Remoto oferece escala, cobertura 24/7 e experiência multi-cliente. O erro comum é tratar como escolha binária: na prática, a maioria das empresas de médio porte opera melhor com modelo híbrido — DBA interno cuidando do domínio, DBA Remoto cobrindo plantão, incidentes e projetos de arquitetura.

Antes de comparar preço, alinhe três perguntas com a diretoria: (1) qual o custo por hora de indisponibilidade do banco em receita, SLA de cliente e reputação? (2) o time atual consegue sustentar plantão 24/7 sem burnout? (3) quem cobre férias, licença e turnover do DBA único hoje?

Antes de precificar, é preciso enxergar o escopo. DBA PostgreSQL sênior em ambiente produtivo sério cobre — no mínimo — sete frentes:

• Operação e plantão: monitoramento ativo, resposta a incidente, atendimento de chamado, análise de alerta.
• Performance tuning: análise de queries lentas, otimização de índice, ajuste de shared_buffers, work_mem, autovacuum — profundidade coberta em Performance Tuning PostgreSQL.
• Alta disponibilidade: desenho e operação de cluster com Streaming Replication + Patroni + PgBouncer — assunto de Consultoria PostgreSQL Alta Disponibilidade.
• Backup e DR: configuração de pgBackRest/Barman, teste de restore, exercício de disaster recovery com RTO/RPO medidos.
• Segurança e compliance: controle de acesso, gestão de roles, auditoria, adequação a LGPD, ISO 27001, PCI-DSS.
• Capacity planning: projeção de crescimento, dimensionamento de recursos, análise de tendência de I/O e CPU.
• Arquitetura e projetos: revisão de schema, migração de versão, particionamento, upgrade major, replicação lógica para BI.

Um profissional interno cobre bem 2 ou 3 dessas frentes com profundidade — e "tenta cobrir" as demais. Terceirizar não é abrir mão de conhecimento próprio: é reconhecer que ninguém sozinho cobre as sete com excelência 24/7.

O erro clássico é comparar "salário do DBA" com "mensalidade da terceirizada". Custo real de um DBA CLT no Brasil é o salário multiplicado por 1,7 a 2,1 — encargos, provisões e benefícios. Some ferramental, treinamento, hardware, e o número real fica muito acima da folha.

E há custos invisíveis mas reais: turnover (DBA sênior tem mercado quente — trocar custa 6 a 9 meses de salário em headhunter + rampa), vaga aberta (o banco não pausa enquanto você contrata por 90 dias), bus factor (DBA único de férias durante um incidente = risco de negócio).

"Empresa que só descobre o custo real do DBA interno quando ele pede demissão está subestimando risco operacional."

DBA Remoto sério não é "consultor de plantão" — é operação estruturada. O modelo padrão da HTI, por exemplo, tem seis camadas visíveis para o cliente:

• Onboarding com Health Check: mapeamento do ambiente, inventário, achados por severidade, plano de estabilização — o que muitas vezes já resolve 40% dos incidentes recorrentes.
• Monitoramento próprio 24/7: NOC ativo com métricas técnicas + monitoramento comportamental (DBSnoop) rastreando desvios de padrão além de simples CPU/RAM.
• Plantão coberto por equipe, não por pessoa: escala com 3 a 5 DBAs cobrindo o mesmo cliente — férias, licença e turnover invisíveis para a operação.
• SLA contratual com penalidade: tempo de resposta e tempo de resolução por severidade, com desconto financeiro em caso de descumprimento — não é discurso, está no contrato.
• Runbook e documentação viva: cada incidente atendido gera atualização em runbook, ambiente ganha memória.
• Governança mensal: reunião de revisão com relatório de incidentes, mudanças, capacity trend, recomendações de arquitetura.

Investimento típico de DBA Remoto PostgreSQL 24/7 para ambiente médio (1 a 3 clusters, RTO 15 min, RPO próximo de zero) fica em uma fração do custo de um DBA CLT sênior — com plantão real e sem risco de turnover. Isso é matemática, não marketing.

"Temos plantão on-call" e "temos NOC 24/7" são coisas radicalmente diferentes. Plantão on-call típico significa que um DBA carrega o celular à noite — se ele dormir profundo, viajar, ficar doente ou pedir demissão, o plantão simplesmente não existe naquela janela. NOC 24/7 real significa: equipe em turno ativo, redundância humana, alertas roteados e testados, SLA contratual com histórico auditável.

Para validar cobertura 24/7 de um fornecedor, peça três coisas objetivas: (1) relatório dos últimos 12 meses com horário e tempo de resposta de cada incidente atendido fora do horário comercial; (2) descrição da escala com nome dos profissionais em cada turno; (3) teste de plantão — abrir um chamado de severidade 3 às 3h da manhã em um sábado e medir. Fornecedor que se recusa a fornecer os três está vendendo discurso.

Não é uma decisão de gosto — é de sintomas. Se três ou mais destes se aplicam ao seu ambiente, terceirização (integral ou parcial) já é o caminho mais barato:

• Você tem 1 único DBA (ou nenhum) sustentando produção crítica.
• O DBA atual está em burnout, atende chamado à noite e não tira férias há > 6 meses.
• Vagas de DBA sênior abertas há mais de 60 dias sem candidato aprovado.
• Incidentes noturnos são atendidos por desenvolvedor de plantão que não é DBA.
• Você não sabe o RTO/RPO real do ambiente porque nunca testou restore ou failover.
• Backup não é validado — descoberta-se o problema no incidente.
• Você tem SLA com cliente mas não tem SLA interno com o time de banco.
• Custo de 1 hora de indisponibilidade supera o valor mensal de um contrato de DBA Remoto.
• Alertas de banco vão para WhatsApp / e-mail sem roteamento e ninguém confia neles.
• O ambiente foi montado por consultor que saiu e ninguém domina 100% da arquitetura hoje.

Terceirização não é solução universal. Existem cenários em que DBA interno é a resposta correta:

• Empresas data-native em que o banco é o produto (data platforms, analytics, ML infra) — precisa de DBA vivendo o roadmap.
• Ambientes com dado altamente sensível e política corporativa que proíbe acesso externo mesmo com controle (setores regulados específicos).
• Times grandes (> 8 DBAs) com cobertura 24/7 madura, ferramental próprio, DR testado, runbook vivo e turnover baixo — nesse caso, você já é o fornecedor.
• Startups em fase pré-produto com banco pequeno e sem carga crítica — nem interno nem terceirizado; basta desenvolvedor com boas práticas + monitoramento gerenciado.

A dicotomia "interno vs remoto" é falsa para a maioria das empresas médias. O modelo que funciona na prática combina os dois:

• DBA interno (1 pessoa, horário comercial): domínio do negócio, participação em roadmap, revisão de PR, contato direto com produto.
• DBA Remoto 24/7 (equipe do fornecedor): plantão noturno e fim de semana, incidentes de severidade alta, backup e DR, monitoramento contínuo, projetos de arquitetura (HA, migração, upgrade).
• Governança compartilhada: reunião mensal com o time interno + fornecedor + gestor de tecnologia. Runbook único, dashboard único, SLA formalizado.

Resultado prático: você mantém domínio interno sem pagar por 3 profissionais para cobrir 24/7, e ganha experiência multi-cliente da terceirizada em projetos complexos (arquitetura HA, upgrade major, migração para PostgreSQL). Custo total costuma ser 40-60% menor que o modelo "só interno com plantão".

Se decidir pelo caminho terceirizado (integral ou híbrido), avalie fornecedor por critérios objetivos, não por apresentação comercial:

• Tempo de mercado em PostgreSQL especificamente — não em "banco de dados em geral".
• NOC próprio ou terceirizado — quem responde às 3h da manhã?
• SLA contratual com penalidade financeira por descumprimento (não "melhores esforços").
• Referências ativas — cliente de porte comparável, atendido há > 24 meses, disposto a conversar.
• Metodologia de onboarding — Health Check inicial, período de shadow, transição gradual.
• Ferramental próprio — o monitoramento é do fornecedor ou o cliente precisa manter o dele?
• Modelo de segurança — acesso individualizado, MFA, gravação de sessão, trilha de auditoria.
• Governança formal — reunião mensal com relatório, revisão de SLA, capacity trend.
• Escopo claro — o que está incluído vs o que é projeto extra; sem letras miúdas.