Add-on de banco de dados ou servidor de banco de dados: a diferença que realmente importa
Por padrão, o banco de dados de uma aplicação nova roda como um add-on no próprio servidor da aplicação — barato, rápido, e exatamente certo pra começar. O que vale entender antes que isso importe em produção: se esse servidor se perder, os dados do add-on só têm os seus backups como rede de segurança. Um servidor de banco de dados é a outra opção — um dos seus próprios servidores que guarda dados e nada mais, com uma história de falha bem diferente.
O que um servidor de banco de dados realmente muda
Mover dados pra um servidor de banco de dados não é só uma máquina maior. Isso muda o que protege os dados:
- Não recebe proxy web nem ferramentas de build, e nenhuma aplicação nunca é implantada nele — ele existe pra exatamente uma função.
- As portas do datastore ficam abertas só pros servidores de aplicação que o usam, não acessíveis de forma geral.
- Backups, verificados. Todo banco de dados de aplicação num servidor de banco de dados recebe um backup diário, e cada um é checado restaurando de verdade — não considerado bom só porque o job reportou sucesso.
- Um standby, nos planos Pro e Team. Also create a standby provisiona um segundo servidor de banco de dados do mesmo tamanho que mantém uma cópia viva do Postgres, MySQL e Redis, checada a cada 5 minutos.
- Failover automático. Se o primário parar de responder por 3 minutos e o standby também tiver perdido contato de forma independente, o standby assume nas portas usuais, toda aplicação que o usa refaz o deploy contra ele, e você recebe uma notificação listando exatamente o que mudou.
Um add-on no servidor da aplicação não tem nada disso por construção — ele nunca foi pensado pra ser a camada de durabilidade, só o padrão conveniente.
Movendo uma aplicação existente
Settings → Resources → Move data to a database server na aplicação, que lista exatamente o que vai ser copiado e o que começa vazio antes de você apertar o botão:
- A aplicação para.
- Postgres e MySQL são exportados e restaurados no servidor de banco de dados.
- Redis, MongoDB, armazenamento de objetos, definições do RabbitMQ e ClickHouse são copiados também — um Elasticsearch usado só por essa aplicação vem junto também.
- A aplicação refaz o deploy.
Se qualquer etapa falhar, a aplicação volta pros dados antigos — somente leitura, nunca sobrescritos — então uma movimentação que falha não arrisca a própria coisa que estava tentando proteger.
Quando o padrão ainda é a escolha certa
Nem toda aplicação precisa disso desde o primeiro dia. Uma ferramenta interna de baixo risco, um ambiente de staging, qualquer coisa em que perder um dia de dados pra uma restauração de backup é um dar de ombros em vez de um incidente — o padrão do add-on é dimensionado corretamente pra isso, e migrar é uma página de configurações de distância sempre que a conta mudar. O ponto não é “sempre use um servidor de banco de dados”. É saber qual dos dois você está realmente rodando antes que uma indisponibilidade seja o momento em que você descobre.
Referência completa, incluindo connection pooling e upgrades do Postgres: Database servers.