Banco de dados gerenciado ou próprio: qual escolher

Toda conversa sobre levar sistemas para a nuvem chega a um ponto delicado: o banco de dados. A aplicação até pode mudar de lugar sem muito drama, mas o banco guarda pedidos, notas, contratos e o histórico inteiro da empresa. A dúvida aparece logo: usar o banco gerenciado do provedor, como Amazon RDS, Google Cloud SQL ou os bancos gerenciados do Azure, ou instalar o banco numa máquina virtual e cuidar dele como sempre se cuidou do servidor da empresa?

A discussão costuma girar em torno de desempenho e de conta mensal, mas a pergunta que mais pesa é outra: quando o disco encher, a réplica atrasar ou alguém apagar uma tabela por engano, quem vai acordar para resolver? Este texto mostra o que cada modelo entrega, onde cada um aperta e quais sinais indicam um ou outro.

Resposta curta: decida por quem vai responder por backup, atualização, réplica e restauração às 3 da manhã. Banco gerenciado troca parte do controle fino por uma operação delegada ao provedor e é a escolha sensata para a maioria das empresas pequenas e médias. Banco instalado em VM ou servidor próprio só compensa quando há equipe que domina banco de dados, exigência de versão ou extensão que o serviço não oferece, ou licença que impede o uso do serviço gerenciado.

O que significa banco gerenciado na prática

Banco gerenciado é um serviço em que o provedor de nuvem entrega o banco de dados já instalado e cuida da camada de infraestrutura. Você escolhe o motor (PostgreSQL, MySQL, SQL Server e outros, conforme o provedor), o tamanho da instância e algumas configurações. O provedor cuida da máquina, do sistema operacional, da instalação do banco, de boa parte das rotinas de backup e das atualizações de manutenção.

O que você não recebe é acesso total ao servidor. Em geral não há login no sistema operacional, nem permissão de superusuário completa no banco, nem liberdade para instalar qualquer extensão ou ferramenta ao lado. É um acordo: você abre mão de mexer em tudo e, em troca, deixa de ser responsável por tudo.

Banco em VM é o caminho tradicional levado para a nuvem: você cria uma máquina virtual, instala o banco e opera como se fosse um servidor seu. Banco em servidor físico é a mesma coisa, só que no rack da empresa ou num data center contratado. Nos dois casos, a responsabilidade técnica fica inteira com a sua equipe ou com quem você contratar.

Um ponto que passa batido: banco gerenciado não significa banco cuidado. O provedor mantém a infraestrutura, mas não sabe se a consulta do fechamento está sem índice ou se a retenção de backup atende à empresa. Isso continua sendo seu.

Backup, restauração e réplica: quem faz o quê em cada modelo

É aqui que a diferença entre os modelos aparece de verdade.

No banco gerenciado

Os serviços gerenciados dos grandes provedores costumam oferecer backup automático, restauração para um ponto no tempo dentro de uma janela de retenção configurável e criação de réplicas de leitura ou de uma instância em espera em outra zona, com troca automática em caso de falha. Os detalhes (janela máxima, tempo de troca, regiões disponíveis) mudam por provedor, por motor e ao longo do tempo, então confirme o que vale hoje com o fornecedor antes de desenhar o plano.

O que continua com você:

• Definir a retenção de acordo com o negócio e com obrigações legais.
• Testar a restauração. Backup automático que nunca foi restaurado é uma hipótese, não uma garantia.
• Ter uma cópia fora da conta principal. Se a conta de nuvem for comprometida ou excluída por engano, os backups automáticos dela podem ir junto. Uma cópia isolada, em outra conta ou outro local, protege contra esse cenário.
• Decidir o que fazer quando a região inteira tiver problema. Réplica em outra zona não é o mesmo que réplica em outra região.
• Não confundir réplica com backup. A réplica copia tudo quase em tempo real, inclusive o DELETE sem WHERE que alguém rodou por engano. Para desfazer erro humano, o que salva é a restauração para um ponto no tempo anterior ao erro.

No banco em VM ou servidor físico

Tudo é com a sua equipe: agendar o backup, verificar se rodou, copiar para outro lugar, monitorar o espaço em disco, configurar a replicação, monitorar o atraso da réplica, montar o procedimento de troca quando o principal cair e treinar quem vai executá-lo.

É trabalho conhecido e bem documentado, mas contínuo, e só aparece quando falha. Sem pessoa dedicada a banco, a rotina costuma ser montada uma vez e esquecida, até o dia em que alguém precisa restaurar e descobre que o backup parou de rodar meses atrás.

Para definir quanto de dado a empresa pode perder e em quanto tempo o sistema precisa voltar, vale ler plano de recuperação de desastres para sistemas. Para entender réplica, failover e o que realmente mantém um sistema no ar, o texto sobre alta disponibilidade de sistemas complementa este.

Atualizações, versões e extensões

Atualizações de manutenção

No gerenciado, correções de segurança e versões menores são aplicadas pelo provedor, normalmente numa janela de manutenção que você escolhe. Ainda é preciso acompanhar os avisos, porque uma atualização pode exigir reinício e o sistema precisa estar preparado para uma breve interrupção ou para a troca para a instância em espera.

Na VM ou no servidor físico, aplicar correção é tarefa da equipe, e é comum encontrar bancos parados em versões antigas porque "está funcionando e ninguém quer mexer". O risco se acumula.

Versões maiores e fim de suporte

Os provedores suportam um conjunto de versões de cada motor e, de tempos em tempos, encerram o suporte às antigas, com prazo para migrar. Isso obriga a planejar e testar a atualização de versão maior com o sistema antes de produção.

Se o seu sistema depende de uma versão específica e não pode ser atualizado tão cedo, esse é um sinal concreto a favor da VM, pelo menos até que a aplicação seja ajustada.

Extensões e configurações

Bancos como o PostgreSQL têm um ecossistema grande de extensões. Os serviços gerenciados oferecem uma lista de extensões suportadas, que varia por provedor e por versão. Se o sistema depende de uma extensão fora dessa lista, de um módulo compilado sob medida ou de uma configuração de baixo nível que o serviço não expõe, o gerenciado deixa de ser opção, ao menos sem adaptar a aplicação.

Antes de decidir, faça o inventário: versão atual, extensões em uso, configurações alteradas em relação ao padrão, rotinas agendadas dentro do banco e qualquer acesso ao sistema de arquivos do servidor. Esse levantamento faz parte de qualquer migração do servidor local para a nuvem bem feita.

Desempenho, ajuste fino e limites do serviço gerenciado

Para a maioria dos sistemas de empresas médias, o desempenho do banco gerenciado é suficiente. Quando o sistema está lento, o motivo costuma ser consulta mal escrita, índice faltando ou modelo de dados inadequado, em qualquer modelo. O texto sobre como diagnosticar sistema lento mostra por onde começar antes de culpar a infraestrutura.

Onde o gerenciado tem limites reais:

• Ajuste de sistema operacional e disco. Não dá para mexer no kernel, no sistema de arquivos ou na organização física dos discos.
• Parâmetros do banco. Muitos parâmetros podem ser alterados, mas não todos.
• Ferramentas ao lado do banco. Agentes de monitoramento, scripts que leem arquivos do servidor ou ferramentas de terceiros que precisam rodar na mesma máquina não têm onde ser instalados.
• Tamanhos de instância. Você escolhe entre os tamanhos oferecidos, não monta a máquina peça por peça.

Na VM há mais liberdade de ajuste, mas ela só ajuda se houver quem saiba usar.

Sobre a conta: o banco gerenciado costuma custar mais pela mesma capacidade de máquina, porque inclui a operação. A comparação justa, porém, soma o tempo de quem opera o banco em VM, o risco de uma restauração que falha e o custo de ficar parado. Para entender onde a conta de nuvem cresce e como reduzir sem perder estabilidade, veja como reduzir custos de nuvem.

Licenças de SQL Server e Oracle na decisão

Com bancos livres como PostgreSQL e MySQL, a licença raramente pesa na decisão. Com SQL Server e Oracle, ela pode ser o fator principal.

Alguns pontos gerais para levar à conversa com o fornecedor e com quem cuida das licenças da empresa:

• Licença incluída ou licença própria. Alguns serviços gerenciados trazem a licença embutida no uso; outros permitem trazer uma licença que a empresa já tem; e há combinações de edição e motor em que o serviço gerenciado não é oferecido. As regras mudam e dependem do contrato.
• Regras de licenciamento por núcleo e por ambiente. Licenças comerciais costumam ter regras sobre quantos núcleos são contados, sobre ambientes de teste e sobre réplicas em espera. Uma arquitetura de alta disponibilidade pode exigir licenças adicionais.
• Recursos que dependem de edição. Certos recursos só existem em edições específicas, e a edição disponível no serviço gerenciado pode não ser a que o sistema usa hoje.

Quando a licença atual não pode ser usada no serviço gerenciado, ou quando o contrato vigente torna a VM claramente mais vantajosa, a VM vira a escolha natural, ao menos por um período. Confirme sempre as condições atuais com o fabricante do banco e com o provedor de nuvem antes de decidir.

Vale também perguntar se o banco comercial ainda é necessário. Discutimos os prós, contras e cuidados em migrar SQL Server ou Oracle para PostgreSQL.

Tabela comparativa: banco gerenciado x banco em VM x servidor físico

Quando escolher cada um

Banco gerenciado é a melhor escolha quando

• A empresa não tem pessoa dedicada a banco de dados, e a TI já cuida de muita coisa.
• O banco é PostgreSQL, MySQL ou outro motor oferecido pelo provedor, sem extensões fora do padrão.
• O sistema precisa de backup confiável e de recuperação rápida, e ninguém quer depender da memória de uma pessoa para isso.
• A aplicação já está ou vai para a nuvem, e a ideia é reduzir trabalho operacional.

Para a maior parte das empresas pequenas e médias, este é o caminho padrão.

Banco em VM faz sentido quando

• Há equipe ou parceiro que domina a operação de banco de dados e vai assumir backup, réplica e atualização com rotina documentada.
• O sistema depende de versão, extensão ou configuração que o serviço gerenciado não oferece.
• A licença de SQL Server ou Oracle que a empresa possui não pode ser usada no serviço gerenciado, ou o contrato torna a VM claramente mais vantajosa.

Servidor físico próprio faz sentido quando

• Há exigência contratual, regulatória ou de latência que obriga o dado a ficar em equipamento da empresa ou em local específico.
• A empresa já tem infraestrutura física madura, com equipe, energia, refrigeração, monitoramento e cópia fora do local funcionando.
• O sistema roda junto de equipamentos locais, como linha de produção, e a conexão com a nuvem não é confiável o bastante.

Sinais de alerta em qualquer modelo

• Ninguém sabe dizer quando foi o último teste de restauração.
• O backup fica no mesmo servidor ou na mesma conta do banco.
• A versão do banco está fora de suporte.
• Só uma pessoa sabe a senha de administrador e como trocar para a réplica.

Se algum aparece, organize a operação antes de discutir modelo.

Perguntas frequentes

O que é banco de dados gerenciado?

Banco de dados gerenciado é um serviço em que o provedor de nuvem entrega o banco já instalado e cuida da máquina, do sistema operacional, de boa parte das rotinas de backup e das atualizações de manutenção. A empresa escolhe o motor, como PostgreSQL ou MySQL, e o tamanho da instância, mas em geral não tem acesso total ao servidor.

Banco de dados gerenciado faz backup sozinho?

Sim, os serviços gerenciados dos grandes provedores costumam oferecer backup automático e restauração para um ponto no tempo dentro de uma janela de retenção. Mesmo assim, a empresa continua responsável por definir a retenção, testar a restauração e manter uma cópia fora da conta principal, porque um problema na conta pode levar os backups automáticos junto.

Réplica de banco de dados substitui o backup?

Não. A réplica copia os dados quase em tempo real, inclusive um comando que apagou registros por engano, então o erro chega à réplica em segundos. Ela serve para manter o sistema no ar quando o servidor principal falha. Para desfazer erro humano, o que salva é a restauração do backup para um momento anterior ao erro.

Dá para migrar um banco em VM para um banco gerenciado depois?

Sim, na maioria dos casos dá, desde que o motor, a versão e as extensões usadas sejam suportados pelo serviço gerenciado. Antes da migração, vale fazer o inventário de versão, extensões, configurações alteradas, rotinas agendadas e acessos ao sistema de arquivos, e testar a aplicação contra o banco novo antes de mudar a produção.

Como a Pervian Tech ajuda a decidir na infraestrutura de banco

Começamos por um diagnóstico inicial gratuito: levantamos o motor e a versão em uso, extensões, tamanho e crescimento dos dados, rotinas de backup existentes, licenças, quanto tempo de parada e de perda de dados o negócio tolera e quem hoje responde pelo banco. Com isso em mãos, a recomendação fica clara.

Quando o banco gerenciado atende, recomendamos o serviço pronto do provedor e configuramos retenção, réplica, cópia isolada, monitoramento e teste de restauração periódico. Quando há motivo real para VM ou servidor próprio, montamos a operação com rotina documentada, alertas e procedimento de troca testado. Esse trabalho faz parte do nosso serviço de cloud e DevOps, e outros textos sobre o tema estão em cloud e infraestrutura.

O investimento é definido sob consulta, depois de entender o ambiente atual. Se você não tem certeza de quem restauraria o seu banco numa madrugada de problema, fale com a gente.