Catch up on everything announced at Firebase Summit, and learn how Firebase can help you accelerate app development and run your app with confidence. Learn More

Entenda o faturamento do Realtime Database

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

O Firebase cobra pelos dados que você armazena em seu banco de dados e todo o tráfego de rede de saída na camada de sessão (camada 5) do modelo OSI. O armazenamento é cobrado a US$ 5 para cada GB/mês, avaliado diariamente. O faturamento não é afetado pela localização do seu banco de dados. O tráfego de saída inclui sobrecarga de conexão e criptografia de todas as operações de banco de dados e dados baixados por meio de leituras de banco de dados. Tanto as leituras quanto as gravações do banco de dados podem levar a custos de conexão em sua conta. Todo o tráfego de e para seu banco de dados, incluindo operações negadas por regras de segurança, gera custos faturáveis.

Alguns exemplos comuns de tráfego faturado incluem:

  • Dados baixados: quando os clientes obtêm dados do seu banco de dados, o Firebase cobra pelos dados baixados. Normalmente, isso representa a maior parte dos custos de largura de banda, mas não é o único fator em sua conta.
  • Sobrecarga de protocolo: Algum tráfego adicional entre o servidor e os clientes é necessário 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 de WebSocket e sobrecarga de cabeçalho HTTP. Cada vez que uma conexão é estabelecida, essa sobrecarga, combinada com qualquer sobrecarga de criptografia SSL, contribui para os custos de conexão. Embora isso não seja muita largura de banda para uma única solicitação, pode ser uma parte substancial da sua conta se suas cargas úteis forem pequenas ou você fizer conexões 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 aproximadamente dezenas de bytes para cabeçalhos de registro TLS em cada mensagem de saída. Para a maioria dos aplicativos, essa é uma pequena porcentagem da sua conta. No entanto, isso pode se tornar uma grande porcentagem se o seu caso específico exigir muitos handshakes SSL. Por exemplo, os dispositivos que não oferecem suporte a tíquetes de sessão TLS podem exigir um grande número de handshakes de conexão SSL.
  • Dados do console do Firebase: embora essa geralmente não seja uma parte significativa dos custos do Realtime Database, o Firebase cobra pelos dados que você lê e grava no console do Firebase.

Estime seu uso faturado

Para ver suas conexões atuais do Realtime Database e o uso de dados, verifique a guia Uso no console do Firebase. Você pode verificar o uso no período de cobrança atual, nos últimos 30 dias ou nas últimas 24 horas.

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

  • Conexões: O número de conexões em tempo real simultâneas, abertas no momento, ao seu banco de dados. Isso inclui as seguintes conexões em tempo real: WebSocket, sondagem longa e eventos enviados pelo servidor HTML. Não inclui solicitações RESTful.
  • Armazenamento: quantos dados são armazenados em seu banco de dados. Isso não inclui hospedagem do Firebase ou dados armazenados por meio de outros produtos do Firebase.
  • Downloads: Todos os bytes baixados de seu banco de dados, incluindo sobrecarga de protocolo e criptografia.
  • Carga: Este gráfico mostra quanto do seu banco de dados está em uso, processando solicitações, em um determinado intervalo de 1 minuto. Você pode ver problemas de desempenho à medida que seu banco de dados se aproxima de 100%.

Otimizar o uso

Existem algumas práticas recomendadas que você pode empregar 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 aplicativo, em vez da API REST. Os SDKs mantêm conexões abertas, reduzindo os custos de criptografia SSL que normalmente se somam à API REST.
  • Verifique se há bugs: se seus custos de largura de banda forem inesperadamente altos, verifique se seu aplicativo não está sincronizando mais dados ou sincronizando com mais frequência do que você pretendia originalmente. Para identificar problemas, use a ferramenta Profiler para medir suas operações de leitura e ative o registro de depuração nos SDKs Android , Objective-C e Web . Verifique os processos de segundo plano e de sincronização em seu aplicativo para garantir que tudo esteja funcionando conforme o esperado.
  • Reduza as conexões: Se possível, tente otimizar a largura de banda da sua conexão. Solicitações REST frequentes e pequenas podem ser mais caras do que uma única conexão contínua usando o SDK nativo. Se você usar a API REST, considere usar um HTTP keep-alive ou eventos enviados pelo servidor , o que pode reduzir os custos de handshakes SSL.
  • Use tíquetes de sessão TLS: reduza os custos indiretos de criptografia SSL em conexões retomadas emitindo tíquetes de sessão TLS . Isso é particularmente útil se você precisar de conexões seguras e frequentes com o banco de dados.
  • Indexar consultas: indexar seus dados reduz a largura de banda total que você usa para consultas, o que tem o duplo benefício de reduzir seus custos e aumentar o desempenho de seu banco de dados. Use a ferramenta de criação de perfil para localizar consultas não indexadas em seu banco de dados.
  • Otimize seus ouvintes: adicione consultas para limitar os dados que suas operações de escuta retornam e use ouvintes que apenas baixam atualizações para dados — por exemplo, on() em vez de once() . Além disso, coloque seus ouvintes o mais longe possível no caminho para limitar a quantidade de dados que eles sincronizam.
  • Reduza os custos de armazenamento: execute trabalhos de limpeza periódicos e reduza quaisquer dados duplicados em seu banco de dados.
  • Regras de uso: evite quaisquer operações não autorizadas potencialmente onerosas em seu banco de dados. Por exemplo, usar as regras do Firebase Realtime Database pode evitar um cenário em que um usuário mal-intencionado faça download repetidamente de todo o banco de dados. Saiba mais sobre como usar as regras do Firebase Realtime Database .

O melhor plano de otimização para seu aplicativo depende do seu caso de uso específico. Embora esta não seja uma lista exaustiva de práticas recomendadas, você pode encontrar mais conselhos e dicas dos especialistas do Firebase em nosso canal Slack ou no Stack Overflow .