VPS para MongoDB no Brasil: guia técnico

Resposta direta

Para rodar MongoDB em uma VPS no Brasil, comece avaliando RAM, disco e rotina de backup antes de olhar apenas para vCPU. Em produção pequena, uma configuração com 2 vCPUs, 4 GB de RAM e 80 GB de SSD já atende muitos painéis internos, APIs e sistemas SaaS iniciais. Para cargas com índices grandes, relatórios frequentes ou muitos writes, o ideal é subir para 4 vCPUs, 8 GB de RAM e SSD NVMe com boa taxa de IOPS, sempre mantendo espaço livre para compactação, logs e snapshots. A localização do servidor também pesa: datacenter no Brasil reduz latência para usuários e aplicações locais, mas precisa ser comparado com disponibilidade, suporte, backup e custo operacional. Não escolha VPS para MongoDB sem plano de restauração testado.

Resumo rápido

• MongoDB depende muito de RAM porque o WiredTiger usa cache para manter dados e índices acessados com frequência.
• SSD é o mínimo aceitável em produção; NVMe ajuda em workloads com muitos writes, índices grandes e consultas concorrentes.
• Uma VPS básica para produção pequena deve partir de 2 vCPUs, 4 GB de RAM e 80 GB de disco SSD.
• Backups precisam combinar retenção, criptografia, cópia fora do servidor e teste de restauração.
• Datacenter no Brasil reduz latência para APIs e usuários locais, mas localização não substitui arquitetura bem feita.
• Firewall, autenticação obrigatória, TLS e bind em IP privado reduzem muito o risco de exposição indevida.
• LetsCloud, Vultr, DigitalOcean, AWS Lightsail e outros provedores podem entrar na análise, mas recursos, regiões e preços precisam ser confirmados nas páginas oficiais antes da decisão.

Como MongoDB usa recursos em uma VPS

MongoDB não se comporta como uma aplicação web comum. Em uma VPS, ele compete por CPU, RAM, disco e rede com o sistema operacional, agentes de backup, logs, monitoramento e, em alguns casos, com a própria aplicação. Por isso, uma instância que parece suficiente no papel pode sofrer em produção quando o banco começa a manter índices maiores, receber picos de escrita ou executar agregações mais pesadas. Uma API Node.js com 30 requisições por segundo e coleções bem indexadas pode funcionar bem em 2 vCPUs e 4 GB de RAM. A mesma VPS pode travar se cada requisição disparar filtros sem índice, ordenações em memória e escrita em múltiplas coleções.

O papel do WiredTiger

O mecanismo padrão WiredTiger trabalha com cache interno. Na prática, ele tenta manter na memória os dados e índices mais acessados. Isso é ótimo para leitura, mas cria uma consequência clara: MongoDB gosta de RAM. Se o working set, que é o conjunto de dados realmente usado no dia a dia, cabe em memória, a resposta tende a ser estável. Se não cabe, o banco acessa o disco com mais frequência. A diferença aparece em consultas que saem de poucos milissegundos para centenas de milissegundos, especialmente quando o storage tem IOPS limitado.

Uma regra prática segura é reservar memória para o sistema operacional e não lotar a VPS com processos paralelos. Em um servidor com 4 GB de RAM, não faz sentido rodar MongoDB, aplicação, Redis, fila, painel web e backup pesado no mesmo horário. Para produção, prefira separar ao menos o banco da aplicação quando o tráfego começar a crescer. Essa lógica é parecida com o que acontece em bancos relacionais, e quem já avaliou VPS para banco PostgreSQL vai notar que a disciplina de índices, cache e backup continua sendo central.

Quando CPU vira gargalo

CPU pesa em agregações, compressão, criação de índices, criptografia TLS e consultas mal planejadas. Para sistemas pequenos, 2 vCPUs costumam ser suficientes. Para dashboards, marketplaces, ERPs internos ou SaaS multiempresa, 4 vCPUs dão mais margem. O ponto é não usar vCPU como remédio para tudo. Se a consulta varre 2 milhões de documentos sem índice, mais CPU só mascara o problema por algum tempo. Antes de escalar, rode explain nas consultas críticas, acompanhe opcounters, page faults, uso de cache e tempo médio de lock.

Armazenamento: SSD, NVMe, IOPS e espaço livre

O disco é um dos pontos mais negligenciados na escolha de VPS para MongoDB. Muitos planos exibem apenas capacidade, como 80 GB ou 160 GB, mas não informam IOPS, throughput, tipo de storage e política de burst. Para MongoDB, isso muda bastante. Um banco pequeno com muitos documentos acessados por índice pode trabalhar bem em SSD comum. Já uma aplicação com alta taxa de escrita, atualizações frequentes e agregações sobre coleções grandes sente a diferença de latência entre SSD SATA, SSD em rede e NVMe. Não dá para afirmar que NVMe resolve todos os problemas, mas ele ajuda quando o gargalo real é entrada e saída de disco.

Por que latência de disco pesa tanto

MongoDB escreve dados, journal e índices. Em cargas de escrita, cada operação pode gerar múltiplos acessos ao storage, e o journal existe justamente para preservar consistência depois de falhas. Se o disco tem latência alta, o banco demora mais para confirmar operações, principalmente quando write concern e journaling estão configurados de forma conservadora. Uma API de pedidos, por exemplo, pode gravar pedido, evento, estoque e log de auditoria em sequência. Em horário de pico, uma VPS com disco lento transforma esse fluxo em fila invisível.

Para produção pequena, considere 80 GB de SSD como ponto de partida quando o banco real tem até 20 GB. Parece sobra, mas não é exagero. Você precisa de espaço para crescimento, logs, compactação, dumps temporários e snapshots. Se o banco ocupa 50 GB em um disco de 60 GB, qualquer manutenção vira risco. Um índice novo pode falhar por falta de espaço. Um mongodump local pode encher a partição. Um log esquecido pode derrubar o serviço.

Espaço livre não é folga, é requisito operacional

Uma configuração prática para início é separar volume de dados em /var/lib/mongodb, manter logs com rotação agressiva e monitorar uso de disco com alerta em 70% e 85%. Em VPS Linux, ferramentas como iostat, vmstat e mongostat ajudam a enxergar espera de I/O. Se await e util ficam altos durante consultas simples, o gargalo pode estar no storage. Em provedores cloud, verifique se o plano usa SSD, NVMe local, volume em rede ou bloco anexado. No caso de LetsCloud, DigitalOcean, Vultr, Linode ou AWS Lightsail, confirme por plano e região, porque tipo de armazenamento, tamanho de disco e recursos adicionais variam e não devem ser assumidos sem fonte atual.

RAM, cache e dimensionamento para produção

A memória é o recurso que mais influencia a experiência diária com MongoDB em uma VPS. Isso acontece porque boa parte da performance vem da capacidade de manter índices e dados quentes no cache. Quando a RAM é insuficiente, o sistema começa a depender mais do disco, aumenta a latência e pode entrar em swap. Swap em banco de dados é um sinal ruim. Ele pode evitar uma queda imediata, mas costuma deixar o serviço instável, lento e difícil de diagnosticar. Em MongoDB, é melhor dimensionar RAM com margem do que operar sempre no limite.

Configurações iniciais por tamanho de aplicação

Para desenvolvimento remoto, homologação ou MVP com poucos usuários, 2 vCPUs, 2 GB de RAM e 40 GB de SSD podem funcionar, desde que a base seja pequena e o banco não receba tráfego constante. Para produção básica, suba para 2 vCPUs, 4 GB de RAM e 80 GB de SSD. Esse perfil atende APIs internas, catálogos pequenos, bots, painéis administrativos e aplicações com alguns milhares de usuários cadastrados, desde que os índices estejam corretos. Para SaaS em crescimento, use 4 vCPUs, 8 GB de RAM e 160 GB de SSD ou NVMe. Para workloads com relatórios, filas de eventos ou muitos tenants, 8 vCPUs e 16 GB de RAM passam a ser uma base mais realista.

A conta não deve olhar apenas o tamanho bruto do banco. Um banco de 30 GB pode rodar bem com 8 GB de RAM se o working set diário for pequeno e os índices forem eficientes. Já um banco de 8 GB pode sofrer com 4 GB de RAM se o sistema consultar coleções inteiras, ordenar sem índice ou carregar documentos muito grandes. Documentos de 2 MB, arrays extensos e campos sem projeção aumentam tráfego de rede, uso de memória e tempo de serialização.

Sinais de que falta memória

Monitore cache dirty, cache used, page faults, uso de swap e resident memory. Se a VPS começa a trocar memória para disco durante picos, você verá consultas oscilando sem mudança no código. Também observe o tamanho dos índices com db.collection.stats. Em muitos sistemas, os índices crescem mais rápido que o esperado porque cada nova funcionalidade adiciona filtros, ordenações e busca por status. Um bom padrão operacional é revisar índices a cada release relevante, removendo índices duplicados e criando índices compostos para consultas reais, não para hipóteses.

Backup, snapshots e restauração sem improviso

Backup para MongoDB em VPS precisa ser tratado como parte da arquitetura, não como tarefa administrativa deixada para depois. O erro mais comum é ativar um cron com mongodump no próprio servidor e considerar o problema resolvido. Isso cria uma falsa sensação de segurança. Se o disco falhar, se a VPS for comprometida ou se alguém apagar a instância, o backup local some junto. O mínimo aceitável é manter cópia fora do servidor, com retenção definida, criptografia e teste periódico de restauração em ambiente separado.

Backup lógico, snapshot e dump

Existem três abordagens frequentes. O backup lógico com mongodump é simples, portátil e bom para bases pequenas ou médias. Ele gera arquivos BSON que podem ser restaurados com mongorestore. Snapshots de volume são rápidos e úteis quando o provedor oferece consistência adequada, mas precisam ser avaliados com cuidado para não capturar dados em estado inconsistente. Em ambientes com replica set, uma prática comum é realizar backup a partir de um secundário, reduzindo impacto no primário. Para bancos maiores, soluções gerenciadas ou ferramentas específicas podem fazer mais sentido.

Um exemplo prático: uma aplicação com banco de 12 GB pode executar mongodump compactado de madrugada, enviar o arquivo para storage externo compatível com S3 e manter retenção de 7 dias diários, 4 semanais e 3 mensais. Para reduzir risco, o arquivo deve ser criptografado antes do envio ou armazenado em bucket com criptografia e política de acesso restrita. Se você está comparando provedores, confira também o guia de VPS com backup automático, porque backup anunciado no painel nem sempre equivale a restore granular, retenção adequada ou cópia independente.

Teste de restore vale mais que promessa

O ponto decisivo é testar restauração. Uma vez por mês, suba uma VPS temporária, restaure o dump, rode checagens básicas e valide se a aplicação conecta. Meça o tempo. Se o restore de 50 GB demora 4 horas, seu RTO real não é 30 minutos. Também defina RPO: perder 24 horas de dados é aceitável para um blog interno, mas pode ser inaceitável para pedidos, pagamentos ou registros médicos. Em produção, combine backup lógico com snapshot e monitore falhas do job. Um backup que falha silenciosamente por 20 dias é pior do que nenhum backup, porque engana a equipe.

Segurança para MongoDB exposto a aplicações reais

MongoDB não deve ficar aberto para a internet sem controle. Ainda aparecem casos de bancos expostos na porta 27017, sem autenticação ou com credenciais fracas. Em uma VPS, você tem liberdade para configurar tudo, mas também assume responsabilidade direta por hardening. O desenho mais seguro é simples: aplicação e banco se comunicam por rede privada ou localhost, o acesso administrativo passa por SSH com chave, e a porta do MongoDB não fica pública. Quando acesso externo for necessário, use VPN, túnel SSH ou allowlist de IPs bem definida.

Firewall e acesso SSH

Comece pelo sistema operacional. Use uma distribuição LTS, aplique updates de segurança, desabilite login SSH por senha, crie usuário sem root direto e proteja chaves privadas. No firewall, libere apenas 22 para IPs administrativos, 80 e 443 se a VPS também servir aplicação web, e 27017 apenas para rede privada ou IPs confiáveis. Em Ubuntu, ufw resolve cenários simples. Em ambientes maiores, regras no firewall do provedor e no iptables ou nftables ajudam a criar uma camada dupla.

Não misture conveniência com exposição. É comum liberar 0.0.0.0/0 temporariamente para testar conexão pelo MongoDB Compass e esquecer a regra aberta. Esse pequeno atalho pode virar incidente. Uma alternativa segura é abrir túnel SSH local, conectando a ferramenta no computador do desenvolvedor a localhost e encaminhando para o servidor. Assim, o banco continua fechado para a internet.

Usuários, TLS e portas

Ative authorization no mongod.conf, crie usuários por aplicação e evite usar conta administrativa no código. A aplicação deve ter permissões apenas no banco necessário. Para conexões entre servidores, avalie TLS, especialmente se o tráfego passar por rede pública. Também vale configurar bindIp com IPs específicos, e não com wildcard. Logs de autenticação devem ser acompanhados, porque tentativas repetidas podem indicar varredura automática. Em produção com dados sensíveis, criptografia em repouso, política de rotação de segredo, auditoria e segregação de acesso deixam de ser extras e passam a ser requisitos de governança.

Localização do servidor no Brasil ou exterior

A localização da VPS influencia latência, experiência do usuário e integração com outros serviços. Para aplicações usadas majoritariamente no Brasil, um servidor em São Paulo, Fortaleza ou outra região nacional pode reduzir o tempo de resposta em chamadas frequentes ao banco, principalmente quando aplicação e MongoDB estão na mesma rede ou no mesmo datacenter. A diferença fica mais visível em APIs que fazem várias consultas por requisição. Se cada tela do sistema executa 8 chamadas à API, e cada chamada depende de leitura no banco, alguns milissegundos extras se acumulam.

Latência para usuários brasileiros

O ideal é manter aplicação e banco próximos. Se a aplicação está no Brasil e o MongoDB está nos Estados Unidos, cada ida e volta pela rede adiciona atraso. Em consultas simples, esse atraso pode ser maior que o tempo de processamento do próprio banco. Para e-commerce, SaaS B2B, plataformas educacionais e sistemas internos acessados durante o expediente brasileiro, latência previsível ajuda bastante. Antes de decidir, rode ping, mtr e testes reais de conexão a partir dos locais onde a aplicação roda. Não use apenas a latência da sua casa como referência.

O tema tem nuances. Há provedores com presença no Brasil, como LetsCloud e Vultr em determinadas ofertas, mas disponibilidade de região, tipo de storage, backup, snapshots, largura de banda e preço são dados variáveis. Devem ser confirmados no site oficial no dia da contratação. Em outros casos, DigitalOcean, Linode, AWS Lightsail, Google Cloud ou Azure podem ser boas escolhas por ecossistema, integrações, documentação ou presença global, mesmo sem manter o banco dentro do Brasil em todos os cenários.

Quando o exterior ainda faz sentido

Servidor fora do Brasil pode ser adequado quando a aplicação atende usuários globais, quando a equipe já opera em uma cloud específica ou quando o banco precisa ficar perto de serviços de IA, filas, objetos ou analytics localizados em outra região. O erro é decidir por país sem olhar arquitetura. Às vezes, colocar tudo no Brasil reduz latência. Em outras, separar aplicação, banco e CDN de forma mal planejada piora a experiência. Se a dúvida é geográfica, aprofunde a comparação em VPS no Brasil ou exterior antes de migrar dados em produção.

Tabela comparativa de perfis de VPS para MongoDB

A tabela abaixo não é ranking de provedores nem comparativo de preço. Ela organiza perfis técnicos para ajudar a conversar com fornecedor, arquiteto ou time de desenvolvimento. Os números são pontos de partida razoáveis para VPS ou Cloud Server com Linux, MongoDB 6 ou 7, journaling ativo e aplicação separada ou com consumo controlado. Em qualquer cenário, valide métricas reais depois do deploy, porque tamanho do documento, qualidade dos índices e padrão de acesso mudam mais a performance que o nome comercial do plano.

Perfil de uso	Configuração inicial	Disco recomendado	Exemplo de workload	Cuidados principais
Desenvolvimento e homologação	2 vCPUs, 2 GB RAM, 40 GB SSD	SSD com alerta em 70%	Ambiente de teste, seed de dados, API interna sem tráfego público	Não usar como produção, limitar acesso por IP e limpar dumps antigos
Produção pequena	2 vCPUs, 4 GB RAM, 80 GB SSD	SSD persistente, preferencialmente com snapshot externo	SaaS inicial, painel administrativo, catálogo com milhares de registros	Backup diário fora da VPS, índices revisados e swap monitorado
Produção em crescimento	4 vCPUs, 8 GB RAM, 160 GB SSD ou NVMe	NVMe ou SSD com boa taxa de IOPS	Marketplace, ERP web, API com consultas concorrentes e filas	Teste de restore mensal, métricas de cache, separação entre app e banco
Produção crítica	8 vCPUs, 16 GB RAM ou mais, 320 GB SSD/NVMe	Storage com redundância e plano de expansão	Dados sensíveis, operação 24 horas, múltiplos tenants	Replica set, backup contínuo, VPN, auditoria e revisão humana da arquitetura

Na prática, a tabela deve ser lida de baixo para cima quando há risco operacional alto. Se o banco sustenta faturamento, atendimento ao cliente ou operação logística, não espere a VPS ficar no limite para agir. Planeje crescimento de disco antes de 70%, revise índices antes de grandes campanhas e faça restore de teste antes de precisar dele. Para provedores, compare painel, API, rede privada, snapshots, volumes adicionais, política de suporte e documentação. LetsCloud pode fazer sentido em projetos que priorizam presença no Brasil e pagamento local, desde que plano, localidade e recursos sejam validados. Provedores globais podem encaixar melhor quando a equipe já usa serviços complementares da mesma nuvem.

Recomendações por perfil

Dev solo e MVP

Para um desenvolvedor solo criando MVP, bot, painel administrativo ou API pequena, a melhor decisão costuma ser começar simples, mas não improvisado. Uma VPS com 2 vCPUs, 2 GB de RAM e 40 GB de SSD serve para desenvolvimento, testes com dados reduzidos e demonstrações para cliente. Se o projeto já tem usuários reais, pule para 4 GB de RAM. Instale MongoDB em uma versão suportada, ative autenticação desde o primeiro dia, configure firewall e mantenha backup diário fora da VPS. Não espere o produto crescer para criar disciplina de restore. Um MVP sem backup vira um problema comercial no primeiro erro de deploy.

Também evite hospedar tudo sem limites na mesma máquina. Aplicação, banco, Redis, workers e painel web podem conviver no início, mas monitore memória e disco. Se o sistema usa uploads, imagens ou arquivos, não guarde tudo no MongoDB. Use storage de objetos quando possível. Para consultas, crie índices baseados nas telas reais do produto. Um índice em email, tenantId e status pode salvar mais desempenho que dobrar vCPU. O objetivo do MVP é aprender rápido, não construir dívida operacional invisível.

Time pequeno com aplicação em crescimento

Times pequenos precisam equilibrar custo, previsibilidade e manutenção. Para uma aplicação com tráfego recorrente, use pelo menos 4 vCPUs, 8 GB de RAM e 160 GB de SSD ou NVMe. Separe aplicação e banco em VPS diferentes quando os deploys ficarem frequentes ou quando workers consumirem CPU de forma irregular. Essa separação reduz impacto de vazamento de memória na aplicação e facilita backup do banco. Também permite reiniciar serviços web sem encostar no MongoDB.

Nesse perfil, a equipe deve criar rotina semanal de revisão: tamanho das coleções, crescimento dos índices, queries lentas, jobs de backup e uso de disco. Configure slow query log com limite adequado, por exemplo 100 ms ou 200 ms, e investigue padrões repetidos. Se o produto atende clientes brasileiros, teste provedores com datacenter no Brasil e compare latência real com regiões externas. Não decida só pela propaganda de baixa latência. Rode uma carga simples com dados parecidos com produção e observe p95 e p99, não apenas média.

Produção crítica com dados sensíveis

Produção crítica pede uma arquitetura mais cuidadosa que uma VPS única. Se MongoDB armazena pedidos, prontuários, documentos financeiros, dados pessoais em volume relevante ou informações de clientes pagantes, considere replica set, backup contínuo, criptografia, controle de acesso por função e rede privada. Uma VPS principal com 8 vCPUs e 16 GB de RAM pode ser o começo, mas disponibilidade depende de redundância, não apenas de tamanho. Se o servidor único cair, o plano grande também fica indisponível.

Nesse caso, defina RPO, RTO, retenção e procedimento de incidente por escrito. Quem restaura? Onde estão as chaves? Quanto tempo leva para subir outro nó? Quais IPs podem acessar o banco? Também vale avaliar MongoDB gerenciado quando a equipe não tem experiência em operação de banco. VPS entrega controle e flexibilidade, mas exige manutenção contínua. Para ambientes regulados, registre logs, revise permissões e valide se o provedor atende requisitos contratuais de localidade, suporte e proteção de dados. A escolha técnica precisa conversar com risco jurídico e continuidade de negócio.