Resposta rápida
Postgres dentro do K8s com operator (CloudNativePG, Zalando, Percona) funciona bem — mas transfere pra você a responsabilidade por backup, failover, tuning e upgrade do banco. DBaaS gerenciado fora do cluster entrega o mesmo Postgres com essa operação por conta do provedor. Regra prática honesta: se você tem DBA/SRE que domina operators e quer controle total, operator é viável; se seu time é de produto e o banco é meio (não fim), DBaaS externo é a escolha racional. Cluster K8s pro stateless + DBaaS pro dado é a arquitetura que mais vemos dar certo em produção B2B.
"Se já tenho Kubernetes, por que pagar DBaaS? Subo um operator e pronto." A frase faz sentido na planilha — até o primeiro incidente de produção às 3h da manhã com o WAL cheio e o failover que não aconteceu. Este artigo compara os dois caminhos sem torcida, com os critérios que importam pra empresa brasileira.
O que um operator realmente faz (e o que sobra pra você)
Operators maduros como CloudNativePG automatizam o grosso: provisionar réplicas, orquestrar failover, agendar backup pra S3, rotacionar certificados. O que continua sendo seu problema:
- Testar restore: o operator agenda backup; quem valida que ele volta é você. Backup nunca restaurado é esperança, não estratégia
- Tuning: shared_buffers, work_mem, autovacuum — o operator aplica o que você mandar, mas decidir o quê continua exigindo conhecimento de Postgres
- IOPS e noisy neighbor: o banco divide node com outros pods. Sem StorageClass NVMe dedicada e requests bem definidos, a latência de query oscila com o vizinho
- Upgrade maior de versão: Postgres 15 → 16 via operator ainda exige planejamento, teste e janela — não é apertar botão
- Monitorar o monitorador: o operator também é software que falha e também precisa de upgrade
O que o DBaaS externo muda
- Operação do banco vira contrato: backup automatizado, réplica, failover e upgrade são responsabilidade do provedor — com engineer respondendo em português quando algo foge do padrão
- Storage dedicado ao banco: IOPS previsível, sem competir com pods de aplicação
- Cluster K8s emagrece: sem StatefulSets críticos, seu cluster vira 100% stateless — mais simples de operar, escalar e até recriar do zero num desastre
- Conexão privada: aplicação no cluster fala com o DBaaS pela rede interna brasileira, sem passar pela internet e sem custo de tráfego
Comparativo direto
| Critério | Operator no K8s | DBaaS externo |
|---|---|---|
| Quem opera o banco | Seu time | Provedor |
| Backup + restore testado | Seu processo | Contrato |
| Failover | Operator (você valida) | Provedor |
| IOPS | Divide com pods | Dedicado |
| Custo direto | Menor (usa o cluster) | Serviço à parte |
| Custo total c/ operação | + horas de DBA/SRE | Previsível na fatura |
| Controle fino (extensões, versão exata) | Total | Cardápio do provedor |
| Exigência de skill no time | Alta (K8s + Postgres) | Baixa (só consumir) |
Quando operator é a escolha certa
- Time tem DBA ou SRE sênior com experiência real em Postgres E em Kubernetes — as duas coisas
- Precisa de extensão exótica ou versão específica que DBaaS não oferece
- Dezenas de bancos pequenos e efêmeros (ambientes de preview/teste por branch) — aí o operator brilha, criando e destruindo bancos via CRD no pipeline
Quando DBaaS externo é a escolha racional
- O banco guarda o dado que paga as contas (ERP, financeiro, SaaS multi-cliente) e o time é de produto, não de infraestrutura
- Ninguém no time testou um restore de verdade nos últimos 90 dias — sinal claro de que a operação own está no limite
- Compliance pede trilha formal: backup com retenção definida, criptografia e responsabilidade contratual (LGPD art. 46, Bacen pra fintech)
A arquitetura que mais dá certo em produção
Depois de acompanhar dezenas de migrações, o desenho vencedor pra B2B brasileiro é consistente:
- Cluster K8s gerenciado: APIs, workers, cron jobs — tudo stateless, com HPA
- DBaaS PostgreSQL/MySQL: o dado transacional, com backup e failover contratuais
- Object Storage S3: uploads, relatórios e o destino dos backups — com Object Lock anti-ransomware
- Rede interna brasileira ligando as três peças, sem cobrança de tráfego entre elas
Cada peça operada por quem faz aquilo o dia inteiro. Seu time foca no produto.
FAQ
CloudNativePG, Zalando ou Percona: se eu for de operator, qual?
CloudNativePG é o mais ativo e virou referência da comunidade — recomendação padrão pra Postgres novo em 2026. Zalando é veterano e sólido, com muita produção acumulada. Percona faz sentido se você já usa o stack Percona (PMM, XtraBackup). Pra MySQL, o operator da Percona é o mais maduro.
Latência: banco fora do cluster não fica mais lento?
Na mesma rede do datacenter, a diferença é de microssegundos a poucos milissegundos — irrelevante perto do tempo da própria query. O que mata latência é IOPS disputado, e nesse quesito o DBaaS com storage dedicado costuma GANHAR do banco em pod.
Posso começar com operator e migrar pra DBaaS depois (ou vice-versa)?
Sim — é Postgres dos dois lados. Migração via réplica lógica ou dump/restore, com corte de conexão em janela curta. O caminho operator → DBaaS é o mais comum que vemos: a empresa cresce, o banco vira crítico e a operação own deixa de compensar.
E bancos de ambientes de teste/staging?
Caso legítimo de misto: produção no DBaaS, ambientes efêmeros via operator no cluster (baratos, descartáveis, criados pelo CI). Melhor dos dois mundos sem contradição.
Próximos passos
- Backup PostgreSQL/MySQL em produção: além do dump
- Kubernetes pra SaaS multi-tenant
- DBaaS PostgreSQL/MySQL Audaks
- Kubernetes Gerenciado Audaks
Banco em pod ou DBaaS? Resolva com dado, não opinião
Diagnóstico gratuito em 24h: avaliamos seu Postgres/MySQL atual (onde roda, backup, failover real), calculamos o custo total dos dois caminhos e recomendamos com franqueza.
Falar com especialista →