Índice do artigo
- Atlas e self-hosted dividem responsabilidades de forma diferente
- Quando MongoDB Atlas é a melhor decisão
- Quando um cluster self-hosted vale a complexidade
- Custo total: compare operação, não apenas infraestrutura
- Alta disponibilidade e escala exigem testes diferentes
- Teste o cenário que pode quebrar o sistema
- Backup não é failover: defina RPO, RTO e restauração
- Segurança: o serviço gerenciado não corrige uma configuração ruim
- Decisão prática: qual modelo escolher?
- Checklist antes de aprovar a arquitetura
- Fontes e critérios usados
MongoDB Atlas é a escolha mais simples quando a equipe quer terceirizar a operação do cluster; um cluster self-hosted faz mais sentido quando controle de sistema operacional, topologia e janela de manutenção justificam o trabalho adicional. A comparação correta não é “preço do Atlas contra preço de uma VM”: é o custo total de manter disponibilidade, backup, segurança, upgrades, monitoramento e recuperação funcionando.
Atlas e self-hosted dividem responsabilidades de forma diferente
Os dois modelos executam MongoDB, mas colocam a fronteira operacional em lugares distintos. No Atlas, o serviço cuida de grande parte do provisionamento e da camada de infraestrutura. No self-hosted, a equipe controla as máquinas e também assume a operação do banco.
| Responsabilidade | MongoDB Atlas | Self-hosted |
|---|---|---|
| Provisionamento e instalação | Feitos pelo serviço conforme o tipo de cluster | Responsabilidade da equipe |
| Replica set e failover | Gerenciados dentro dos limites do tier | Desenhados, configurados e testados pela equipe |
| Backups e retenção | Políticas e snapshots disponíveis conforme o plano | Ferramenta, armazenamento e restauração são seus |
| Patch do host | Fica fora do seu sistema operacional | Exige janela, teste e rollback |
| Acesso root e filesystem | Não disponível | Disponível |
| Escala | Workflows de escala disponíveis em tiers elegíveis | Automação e capacidade são responsabilidade da equipe |
Quando MongoDB Atlas é a melhor decisão
Atlas tende a ser a melhor decisão quando o objetivo principal é colocar uma aplicação em produção sem formar uma operação de banco de dados ao redor dela. A equipe ainda precisa modelar documentos, criar índices, controlar credenciais e validar restaurações, mas não precisa montar toda a camada de máquinas, discos e failover.
- O time é pequeno e não tem plantão dedicado para banco.
- Backups gerenciados, alertas e failover reduzem risco operacional.
- O workload pode crescer e se beneficiar de workflows de escala elegíveis.
- Multi-região, peering ou integração com a nuvem fazem parte do desenho.
Isso não transforma Atlas em uma solução sem operação. Uma configuração inadequada, índice ausente ou política de retenção errada continua sendo responsabilidade da aplicação. O serviço reduz trabalho de plataforma; não substitui engenharia de dados.
Quando um cluster self-hosted vale a complexidade
Self-hosted é justificável quando existe um requisito concreto abaixo da fronteira do serviço gerenciado. A equipe pode precisar de acesso ao sistema operacional, agentes próprios, uma topologia específica, janela exata para patches, localização de dados ou integração de segurança que o serviço não oferece no formato necessário.
O ganho é controle. O preço é assumir o ciclo completo: instalar versões compatíveis, configurar autenticação e TLS, distribuir membros em máquinas diferentes, observar eleições, crescer armazenamento e provar que o restore funciona. Em produção, “uma VM com MongoDB” não é equivalente a um cluster tolerante a falhas.
# Exemplo de capacidade mínima a documentar antes do self-hosted
replica_members=3
failure_domains=3
backup_target="storage separado do cluster"
restore_test="mensal"
on_call="responsável definido"
Custo total: compare operação, não apenas infraestrutura
O Atlas cobra por uma plataforma que inclui capacidades operacionais conforme a configuração. No self-hosted, a fatura da VM pode parecer menor, mas o cluster de produção pode exigir três nós, armazenamento de backup, monitoramento, tráfego, horas de engenharia e atendimento a incidentes.
Use este modelo antes de escolher:
custo_atlas = cluster + armazenamento + backup/transferência + serviços opcionais
custo_self_hosted = nós + discos + backup + monitoramento + upgrades
+ plantão + testes de restore + resposta a incidentes
Não invente uma economia com uma comparação assimétrica. Um Atlas dedicado deve ser comparado com uma arquitetura self-hosted que entregue disponibilidade, retenção e recuperação equivalentes. Se o self-hosted usar um único nó, registre explicitamente que o nível de risco também é diferente.
Alta disponibilidade e escala exigem testes diferentes
Uma réplica mantém cópias e pode permitir eleição quando um membro falha; ela não protege automaticamente contra exclusão acidental, corrupção replicada ou erro de configuração. Alta disponibilidade e recuperação histórica são controles diferentes.
No Atlas, a equipe escolhe uma configuração compatível com as necessidades de redundância e acompanha limites do tier. No self-hosted, a equipe precisa provisionar os membros, escolher domínios de falha, configurar DNS, testar eleição, medir atraso de replicação e definir limites de crescimento.
Teste o cenário que pode quebrar o sistema
- Registre latência, throughput, uso de CPU, memória, disco e atraso de replicação.
- Desligue um membro em ambiente de teste e confirme o comportamento do driver.
- Execute um restore em uma rede isolada, não apenas uma verificação de que o arquivo existe.
- Repita a medição depois da recuperação e documente RPO e RTO observados.
Backup não é failover: defina RPO, RTO e restauração
O Atlas disponibiliza opções de backup e retenção conforme o deployment. No self-hosted, a equipe escolhe a ferramenta, o destino, o acesso, a retenção e o método de restauração. Nos dois modelos, a aplicação precisa validar se os dados restaurados funcionam.
Documente pelo menos:
- RPO: quanto dado pode ser perdido.
- RTO: em quanto tempo o serviço precisa voltar.
- onde o backup será restaurado e quem autoriza a operação;
- periodicidade do teste e evidência gerada;
- como a aplicação será validada depois do restore.
Segurança: o serviço gerenciado não corrige uma configuração ruim
Atlas oferece controles de rede, criptografia e gestão de acesso dentro do seu modelo de responsabilidade compartilhada. No self-hosted, a equipe precisa proteger exposição de portas, autenticação, TLS, atualizações, firewall, logs, segredos e acesso administrativo.
Em qualquer modelo, aplique menor privilégio, use contas separadas por serviço, evite credenciais no código, restrinja origem de conexão e monitore alterações. Para self-hosted, não exponha o MongoDB diretamente à internet sem uma justificativa e uma camada de defesa documentadas.
Decisão prática: qual modelo escolher?
| Sinal do projeto | Escolha inicial | Por quê |
|---|---|---|
| Equipe sem operação de banco dedicada | Atlas | Reduz a superfície de tarefas de plataforma |
| Necessidade de root ou agente de host | Self-hosted | O controle fica abaixo da camada gerenciada |
| Produção crítica sem restore testado | Nenhum ainda | Primeiro valide recuperação e responsabilidades |
| Topologia ou localização obrigatória | Depende do requisito | Compare limites do Atlas com o desenho próprio |
| Custo de infraestrutura é o único argumento | Recalcule | Inclua engenharia, backup e plantão |
A recomendação mais segura é começar pela responsabilidade que você quer possuir. Escolha Atlas se reduzir operação é mais importante que acesso ao host. Escolha self-hosted apenas quando controle, topologia ou custo total forem requisitos comprovados e houver capacidade para operar o cluster.
Checklist antes de aprovar a arquitetura
- O workload, o crescimento e a retenção estão medidos?
- O custo inclui nós, backup, transferência e horas de operação?
- RPO e RTO foram definidos e testados?
- Há um procedimento de failover e outro de restore?
- Os membros self-hosted ficam em domínios de falha independentes?
- Os acessos, portas, TLS e segredos foram revisados?
- Existe responsável por alertas, patches e incidentes?
Fontes e critérios usados
Esta comparação foi revisada contra a discussão da comunidade MongoDB, o guia comparativo da Raff Technologies e a documentação oficial de Atlas e deployments self-managed. Preços e capacidades mudam por região, tier e data; confirme os valores no painel antes de fechar uma arquitetura.
FAQ: perguntas frequentes
MongoDB Atlas é melhor que self-hosted?
Não existe uma escolha universal. Atlas costuma ser melhor quando a equipe quer backups, monitoramento, failover e escala gerenciados. Self-hosted pode ser melhor quando há necessidade de root, topologia customizada, controle exato de patches ou uma operação de banco já estruturada.
Self-hosted MongoDB é sempre mais barato?
Não. Uma VM pode custar menos que um serviço gerenciado, mas uma comparação de produção precisa incluir nós de réplica, discos, backup, monitoramento, upgrades, plantão e testes de restauração. A economia só existe se a equipe conseguir operar tudo com confiabilidade e custo total menor.
Atlas faz backup automaticamente?
O Atlas oferece opções de backup gerenciado conforme o tipo e a configuração do deployment. A equipe ainda precisa definir retenção, objetivos de recuperação e testar o restore. Backup habilitado não prova, sozinho, que a aplicação conseguirá voltar a operar depois de uma falha.
Um replica set substitui um backup?
Não. A replicação ajuda na disponibilidade quando um membro falha, mas uma exclusão acidental ou corrupção lógica pode ser replicada para os demais membros. Use backup com retenção e restauração testada para recuperar estados históricos.
Quantos nós um cluster self-hosted deve ter?
Para produção, a documentação do MongoDB recomenda pensar em replica sets com membros distribuídos em máquinas e domínios de falha adequados. Três membros são uma referência comum para eleições, mas o desenho final depende de disponibilidade, latência, capacidade e orçamento.
Atlas permite acesso root ao servidor?
Não. Em um serviço gerenciado, a equipe opera o banco dentro das capacidades oferecidas pelo serviço, sem controlar o sistema operacional subjacente. Se root, agentes próprios ou pacotes de host forem requisitos obrigatórios, self-hosted é o caminho a avaliar.
Quando migrar de Atlas para self-hosted?
Considere a migração quando houver um requisito comprovado de controle, topologia, localização ou custo total, e quando a equipe tiver automação, monitoramento, backup e plantão para assumir a operação. Não migre apenas porque uma VM isolada parece mais barata.
Como escolher entre Atlas e self-hosted?
Liste RPO, RTO, crescimento, acesso ao host, requisitos de rede, janela de manutenção, capacidade operacional e custo total. Faça um teste pequeno, meça o resultado e documente o que a equipe terá de operar em cada alternativa antes de decidir.