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 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 faturamento não é afetado pela localização do seu banco de dados. 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 usando as 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 gera custos faturáveis, incluindo operações negadas pelas regras de segurança.
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, esse tráfego pode incluir: sobrecarga de protocolos 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, e 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 tíquetes de sessão TLS podem precisar de vários handshakes de conexão SSL.
Dados do console do Firebase: embora essa parcela dos custos do Realtime Database geralmente
não seja significativa, o Firebase cobra pelos dados que você lê e grava
no console do Firebase.
Estimar seu uso faturado
Para conferir suas conexões atuais do Realtime Database e o uso de dados, verifique a guia
Uso
no console do Firebase. É 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 usando 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 1 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 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 os seus custos de largura de banda forem inesperadamente altos, verifique
se o seu app está sincronizando mais dados ou em uma frequência maior do que o planejado
inicialmente. Para identificar problemas, use a ferramenta do criador de perfil. Com ela, você
avalia as suas operações de leitura e ativa a geração de registros
de depuração nos SDKs do
Android, do
Objective-C
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ê usa a API REST,
considere utilizar um sinal de atividade HTTP para manter uma conexão aberta ou
eventos enviados pelo servidor
para reduzir os custos de handshakes de SSL.
Use tíquetes de sessão da TLS: emita tíquetes de sessão da 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 os 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 banco de dados. Use a ferramenta do criador de perfil para encontrar consultas não indexadas no 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 das 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, o uso de Firebase Realtime Database Security Rules pode evitar que um
usuário mal-intencionado faça downloads repetidos 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 app depende do seu caso de uso específico.
Esta não é uma lista completa das práticas recomendadas, mas é possível encontrar mais orientações e dicas dos especialistas em Firebase no nosso canal no Slack ou no Stack Overflow.
[null,null,["Última atualização 2025-08-16 UTC."],[],[],null,["\u003cbr /\u003e\n\nFirebase bills for the data you store in your database and all outbound network\ntraffic at the session layer (layer 5) of the OSI model. Storage is billed at\n$5 for each GB/month, evaluated daily. Billing is not affected by the location\nof your database. Outbound traffic includes connection and encryption overhead\nfrom all database operations and data downloaded through database reads. Both\ndatabase reads and writes can lead to connection costs on your bill. All\ntraffic to and from your database, including operations denied by security\nrules, leads to billable costs.\n\nSome common examples of billed traffic include:\n\n- **Data downloaded:** When clients get data from your database, Firebase charges for the downloaded data. Typically, this makes up the bulk of your bandwidth costs, but it isn't the only factor in your bill.\n- **Protocol overhead:** Some additional traffic between the server and clients is necessary to establish and maintain a session. Depending on the underlying protocol, this traffic might include: Firebase Realtime Database's realtime protocol overhead, WebSocket overhead, and HTTP header overhead. Each time a connection is established, this overhead, combined with any SSL encryption overhead, contributes to the connection costs. Although this isn't a lot of bandwidth for a single request, it can be a substantial part of your bill if your payloads are tiny or you make frequent, short connections.\n- **SSL encryption overhead:** There is a cost associated with the SSL encryption overhead necessary for secure connections. On average, this cost is approximately 3.5KB for the initial handshake, and approximately tens of bytes for TLS record headers on each outgoing message. For most apps, this is a small percentage of your bill. However, this can become a large percentage if your specific case requires a lot of SSL handshakes. For example, devices that don't support [TLS session tickets](https://tools.ietf.org/html/rfc5077) might require large numbers of SSL connection handshakes.\n- **Firebase console data:** Although this isn't usually a significant portion of Realtime Database costs, Firebase charges for data that you read and write from the Firebase console.\n\n| When your project is on the Blaze pricing plan, [**set up budget alerts**](/docs/projects/billing/avoid-surprise-bills#set-up-budget-alert-emails) using the console. You can use the [Blaze plan calculator](/pricing#blaze-calculator) to estimate your monthly costs.\n|\n| Be aware that **budget alerts do *not* cap your usage or\n| charges** --- they are *alerts* about your costs so that you can\n| take action, if needed. For example, you might consider\n| [using\n| budget notifications to programmatically disable Cloud Billing on a\n| project](https://cloud.google.com/billing/docs/how-to/disable-billing-with-notifications).\n\nEstimate your billed usage\n\nTo see your current Realtime Database connections and data usage, check the\n[Usage](https://console.firebase.google.com/project/_/database/usage/current-billing/)\ntab in the Firebase console. You can check usage over the current billing\nperiod, the last 30 days, or the last 24 hours.\n\nFirebase shows usage statistics for the following metrics:\n\n- **Connections:** The number of simultaneous, currently open, realtime connections to your database. This includes the following realtime connections: WebSocket, long polling, and HTML server-sent events. It does not include RESTful requests.\n- **Storage:** How much data is stored in your database. This doesn't include Firebase hosting or data stored through other Firebase products.\n- **Downloads:** All bytes downloaded from your database, including protocol and encryption overhead.\n- **Load:** This graph shows how much of your database is in use, processing requests, over a given 1-minute interval. You might see performance issues as your database approaches 100%.\n\nOptimize usage\n\nThere are a few best practices you can employ to optimize your database usage\nand bandwidth costs.\n\n- **Use the native SDKs:** Whenever possible, use the SDKs that correspond to your app's platform, instead of the REST API. The SDKs maintain open connections, reducing the SSL encryption costs that typically add up with the REST API.\n- **Check for bugs:** If your bandwidth costs are unexpectedly high, verify that your app isn't syncing more data or syncing more often than you originally intended. To pinpoint issues, use the [profiler tool](/docs/database/usage/profile) to measure your read operations and turn on debug logging in the [Android](https://firebase.google.com/docs/reference/android/com/google/firebase/database/Logger), [Objective-C](https://firebase.google.com/docs/reference/ios/firebasecore/api/reference/Enums/FIRLoggerLevel), and [Web](https://firebase.google.com/docs/reference/js/database#enablelogging) SDKs. Check background and sync processes in your app to make sure everything is working as you intended.\n- **Reduce connections:** If possible, try to optimize your connection bandwidth. Frequent, small REST requests can be more costly than a single, continuous connection using the native SDK. If you do use the REST API, consider using an HTTP keep-alive or [server-sent events](/docs/reference/rest/database#section-streaming), which can reduce costs from SSL handshakes.\n- **Use TLS session tickets:** Reduce SSL encryption overhead costs on resumed connections by issuing [TLS session tickets](https://tools.ietf.org/html/rfc5077). This is particularly helpful if you do require frequent, secure connections to the database.\n- **Index queries:** [Indexing your data](/docs/database/security/indexing-data) reduces the total bandwidth you use for queries, which has the double benefit of lowering your costs and increasing your database's performance. Use the profiler tool to [find unindexed queries](/docs/database/usage/profile#unindexed_queries) in your database.\n- **Optimize your listeners:** Add queries to limit the data that your listen operations return and use listeners that only download updates to data --- for example, `on()` instead of `once()`. Additionally, place your listeners as far down the path as you can to limit the amount of data they sync.\n- **Reduce storage costs:** Run periodic cleanup jobs and reduce any duplicate data in your database.\n- **Use Rules:** Prevent any potentially costly, unauthorized operations on your database. For example, using Firebase Realtime Database Security Rules could avoid a scenario where a malicious user repeatedly downloads your entire database. Learn more about [using Firebase Realtime Database Rules](/docs/database/security).\n\n| **Note about the profiler tool:** The profiler tool doesn't account for network traffic. It only records an estimate of the application data sent in responses. The profiler tool is intended to give you an overall picture of your database's performance, to help you monitor operations and troubleshoot issues, **not to estimate billing** . To learn more, see [the profiler tool documentation](/docs/database/usage/profile).\n\nThe best optimization plan for your app depends on your particular use case.\nWhile this isn't an exhaustive list of best practices, you can find\nmore advice and tips from the Firebase experts on our\n[Slack channel](https://firebase.community/)\nor on [Stack Overflow](https://stackoverflow.com/questions/tagged/firebase)."]]
