Quanto custa um banco de dados na nuvem?

Um banco de dados na nuvem é um servidor de banco (PostgreSQL, MySQL, MongoDB ou Redis) que fica ligado num provedor, com disco e rede, e que a sua aplicação acessa por uma string de conexão. O preço não é um número único: depende da memória que o banco usa, do volume de dados que ele guarda e de como o provedor cobra cada parte.

Os preços de terceiros mudam com frequência, por isso este guia mostra como a conta se forma, não a tabela de cada provedor. Confira os valores atuais na página do provedor antes de decidir.

O que compõe o custo de um banco na nuvem?#

Quase toda fatura se divide em cinco itens:

1. Instância (RAM e CPU): o servidor em si. Em geral, é o maior item.
2. Armazenamento: o disco, cobrado por GB, às vezes com IOPS (operações por segundo) à parte.
3. Tráfego: dados que saem do banco para fora da rede do provedor.
4. Cópias e snapshots: retenção acima da cota incluída costuma ser cobrada.
5. Alta disponibilidade: réplicas e failover multiplicam o custo da instância.

Dois bancos com o mesmo tamanho de dados podem custar muito diferente se um tem réplica e o outro não.

Quais são os modelos de cobrança?#

Cada provedor escolhe uma forma de cobrar, e ela define o quanto você consegue prever a fatura:

• Plano fixo com cota: você paga um valor mensal e recebe RAM, disco e tráfego dentro de limites. É o mais fácil de prever.
• Instância por hora: você escolhe o tamanho e paga pelas horas ligadas. Para estimar o mês, multiplique a tarifa por 730, o número aproximado de horas num mês.
• Por uso: a cobrança acompanha operações ou armazenamento consumido. É barata quando o uso é baixo e difícil de prever quando ele oscila.

Como cobram alguns provedores conhecidos?#

Os mesmos modelos aparecem nas ofertas mais conhecidas:

Valores e limites atuais: Supabase e MongoDB. No Amazon RDS, a instância é cobrada por hora, e armazenamento, backup acima da cota e transferência de dados são itens separados, como descreve a página de preços do RDS para PostgreSQL. Some tudo na calculadora do provedor, porque o valor da instância sozinho engana.

Como estimar o tamanho e a RAM do seu banco?#

Meça o que você já tem. Cada motor tem um comando:

-- PostgreSQL
SELECT pg_size_pretty(pg_database_size(current_database()));

-- MySQL
SELECT table_schema AS banco,
       ROUND(SUM(data_length + index_length) / 1024 / 1024, 1) AS mb
FROM information_schema.tables
GROUP BY table_schema;

// MongoDB (mongosh): valores em MB (dataSize, storageSize, indexSize)
db.stats(1024 * 1024)

redis-cli INFO memory | grep used_memory_human

Depois faça a conta: tamanho atual, mais o crescimento mensal vezes o número de meses, mais 30% de folga. Um banco com 2 GB que cresce 300 MB por mês chega a cerca de 5,6 GB em um ano (2 + 3,6) e, com folga, pede uns 7,3 GB de disco.

Para RAM, a regra prática é que os índices e os dados mais acessados caibam na memória. No Redis isso é literal: todo o conjunto de dados fica em RAM, então o used_memory define o tamanho mínimo da instância. O comando está documentado em INFO do Redis.

Quais são os custos escondidos?#

• Tráfego de saída: servir dados para fora da rede do provedor pode ser cobrado por GB. Aplicação e banco no mesmo datacenter evitam isso e reduzem a latência.
• Pausa e estouro de cota: camadas sem custo pausam ou bloqueiam ao passar do limite, e o plano seguinte pode ser um salto grande de preço.
• Ambientes duplicados: ter staging e produção separados dobra a fatura.
• Retenção de cópias: guardar mais dias de snapshot ou backup consome disco. Veja como fazer backup de um banco de dados.
• Migração futura: sair de um provedor com formato proprietário custa horas de trabalho. Motores abertos como PostgreSQL e MySQL facilitam a saída.

Como reduzir o custo sem perder confiabilidade?#

Escolha o motor certo para o dado: qual banco de dados escolher evita pagar por um cluster de documentos quando uma tabela relacional resolve. Use o Redis só para o que precisa de velocidade, não como armazenamento principal. Remova dados antigos com rotinas de expiração e crie só os índices necessários, porque todo índice ocupa disco e RAM. Mantenha aplicação e banco na mesma região. O passo a passo para colocar um banco no ar está em como hospedar um banco de dados.

Como fazer isso na Square Cloud#

Na Square Cloud, os itens que você somou acima viram o preço fixo de um plano, cobrado em reais. A hospedagem de MongoDB, PostgreSQL, MySQL e Redis começa no Standard, a partir de R$ 44,99 por mês com 4 GB de RAM; o Hobby não inclui bancos. Não há cobrança por banda nem por requisição (política de uso justo), e o banco fica no mesmo datacenter das aplicações, com latência média de cerca de 1 ms, então o tráfego entre os dois não aparece na conta.

A estimativa de RAM que você fez é a que importa aqui. A RAM do plano é um pool compartilhado entre aplicações e bancos: cada banco usa no mínimo 512 MB (Redis) ou 1024 MB (MongoDB, PostgreSQL e MySQL). Uma API web de 512 MB com um PostgreSQL de 1024 MB e um Redis de 512 MB soma 2 GB e cabe no Standard de 4 GB com folga. O número de bancos só é limitado por essa RAM, com motores diferentes lado a lado.

A retenção de cópias também já vem no plano. Todo plano com bancos faz um snapshot automático diário, guardado por 7 dias (o mais recente por até 30 dias), e você tira snapshots manuais quando quiser, por exemplo antes de uma migration. Um snapshot restaura no mesmo banco, em outro do mesmo motor ou num banco novo, ou sai como .zip. Cada banco roda em nó único, sem réplica: para dados críticos, guarde também uma cópia sua fora da plataforma.

Você cria o banco no painel (nome, memória e motor) e ele fica pronto em segundos, com TLS obrigatório. Veja os bancos disponíveis hoje em Bancos de dados, a retenção em Snapshots e os planos em Preços.