Ir para o console
Teste o Cloud Firestore: conheça o banco de dados escalonável e flexível do Firebase e do Google Cloud Platform. Saiba mais sobre o Cloud Firestore.

Compreender o faturamento do Realtime Database

O Firebase cobra pelos dados que você armazena no seu banco de dados e por todo o tráfego de rede de saída na camada de sessão (camada 5) do modelo OSI. A cobrança do armazenamento é de US$ 5 para cada GB/mês, avaliado diariamente. O tráfego de saída inclui a sobrecarga de conexão e criptografia de todas as operações de banco de dados e dos dados transferidos por meio de leituras de banco de dados. Tanto as leituras quanto as gravações de banco de dados podem gerar custos de conexão na sua fatura. Todo o tráfego enviado para o seu banco de dados e recebido dele, incluindo operações negadas pelas regras de segurança, gera custos faturáveis.

Alguns exemplos comuns de tráfego faturado incluem:

  • Dados transferidos: quando os clientes recebem dados do seu banco de dados, o Firebase cobra pelos dados transferidos. Normalmente, isso compõe a maior parte dos seus custos de largura de banda, mas não é o único custo presente na sua fatura.
  • Sobrecarga de protocolo: é necessário um tráfego adicional entre o servidor e os clientes para estabelecer e manter uma sessão. Dependendo do protocolo subjacente, esse tráfego pode incluir: sobrecarga de protocolo em tempo real do Firebase Realtime Database, sobrecarga do WebSocket e sobrecarga do cabeçalho HTTP. Cada vez que uma conexão é estabelecida, essa sobrecarga, juntamente com qualquer sobrecarga de criptografia SSL, contribui para os custos de conexão. Essa largura de banda não é tão grande para uma única solicitação, mas ela pode ser uma parte substancial da sua fatura se os seus payloads forem pequenos ou se as conexões feitas forem frequentes e curtas.
  • Sobrecarga de criptografia SSL: há um custo associado à sobrecarga de criptografia SSL necessária para conexões seguras. Em média, esse custo é de aproximadamente 3,5 KB para o handshake inicial e de algumas dezenas de bytes para cabeçalhos de registro de TLS em cada mensagem de saída. Para a maioria dos apps, isso representa uma porcentagem pequena da sua fatura. No entanto, ela poderá aumentar se seu caso específico precisar de muitos handshakes de SSL. Por exemplo, os dispositivos que não são compatíveis com tickets de sessão TLS podem precisar de vários handshakes de conexão SSL.
  • Dados do Firebase console: essa parcela dos custos do Realtime Database geralmente não é significativa, mas o Firebase cobra pelos dados que você lê e grava no Firebase console.

Estimar seu uso faturado

Para saber quanto você usa do Realtime Database atualmente e fazer uma estimativa da sua fatura, verifique a guia Uso no Firebase console. É possível verificar o uso relativo ao período de faturamento atual, aos últimos 30 dias ou às últimas 24 horas.

O Firebase mostra estatísticas de uso para as seguintes métricas:

  • Conexões: o número de conexões abertas, simultâneas e em tempo real com seu banco de dados. Isso inclui as seguintes conexões em tempo real: WebSocket, long polling e eventos enviados pelo servidor HTML. Não inclui solicitações RESTful.
  • Armazenamento: a quantidade de dados armazenada no seu banco de dados. Isso não inclui Firebase Hosting ou dados armazenados por meio de outros produtos do Firebase.
  • Downloads: todos os bytes transferidos a partir do seu banco de dados, incluindo a sobrecarga do protocolo e da criptografia.
  • Carga: neste gráfico, é possível ver quanto do banco de dados está sendo usado no processamento de solicitações durante um intervalo de um minuto. Você pode ter problemas de desempenho à medida que seu banco de dados se aproxima de 100%.

Otimizar o uso

Veja abaixo algumas práticas recomendadas para otimizar o uso do banco de dados e os custos de largura de banda.

  • Use os SDKs nativos: sempre que possível, use os SDKs que correspondem à plataforma do seu app, em vez da REST API. Os SDKs mantêm conexões abertas, reduzindo os custos de criptografia SSL que normalmente se somam à REST API.
  • Verifique se há bugs: se seus custos de largura de banda forem inesperadamente altos, verifique se seu app está sincronizando mais dados ou em uma frequência maior do que o planejado inicialmente. Para identificar problemas, use a ferramenta de criação de perfil com o objetivo de avaliar suas operações de leitura e ativar a geração de registros de depuração nos SDKs do Android, do iOS e da Web. Verifique os processos em segundo plano e de sincronização no seu app para garantir que tudo esteja funcionando conforme o planejado.
  • Reduza as conexões: se possível, tente otimizar sua largura de banda de conexão. Solicitações de REST pequenas e frequentes podem ser mais caras do que uma única conexão contínua que usa o SDK nativo. Se você realmente for utilizar a REST API, use eventos keep-alive em HTTP ou eventos enviados pelo servidor para reduzir os custos dos handshakes de SSL.
  • Use tickets de sessão TLS: emita tickets de sessão TLS para reduzir os custos com a sobrecarga de criptografia SSL nas conexões retomadas. Isso é muito útil caso você precise de conexões frequentes e seguras ao banco de dados.
  • Faça a indexação de consultas: indexar seus dados reduz a largura de banda total usada para consultas. Isso proporciona o duplo benefício de reduzir os custos e aumentar o desempenho do seu banco de dados. Use a ferramenta de criação de perfil para encontrar consultas não indexadas no seu banco de dados.
  • Otimize seus listeners: adicione consultas para limitar os dados retornados pelas operações de detecção e use listeners que fazem o download somente de atualizações de dados. Por exemplo: on() em vez de once(). Além disso, coloque os listeners na última parte possível do caminho para limitar a quantidade de dados que eles sincronizam.
  • Reduza os custos de armazenamento: execute jobs periódicos de limpeza e reduza dados duplicados no seu banco de dados.
  • Use regras: elas impedem qualquer operação potencialmente cara e não autorizada no seu banco de dados. Por exemplo, usar as regras do Firebase Realtime Database pode evitar uma situação em que um usuário mal-intencionado faz o download do banco de dados inteiro repetidamente. Saiba mais sobre como usar as regras do Firebase Realtime Database.

O melhor plano de otimização para seu app depende do seu caso específico de uso. Esta não é uma lista completa das práticas recomendadas, mas você pode encontrar mais orientações e dicas dos especialistas em Firebase no nosso canal no Slack ou no Stack Overflow (ambos em inglês).