Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Firebase factura por los datos que almacenas en la base de datos y todo el tráfico de red saliente en la capa de sesión (capa 5) del modelo OSI. El almacenamiento tiene un costo de USD 5 por GB al mes, que se evalúa a diario. La ubicación de tu base de datos no influye en la facturación. El tráfico saliente incluye la sobrecarga de conexión y encriptación de todas las operaciones de la base de datos y los datos descargados a través de operaciones de lectura de la base de datos. Tanto las operaciones de lectura como las de escritura de la base de datos pueden generar costos de conexión en tu factura. Todo el tráfico hacia la base de datos y desde ella genera costos facturables, incluidas las operaciones denegadas por las reglas de seguridad.
Algunos ejemplos comunes de tráfico facturado incluyen los siguientes:
Datos descargados: Cuando los clientes obtienen datos de tu base de datos, Firebase cobra por los datos descargados. Por lo general, esto constituye la mayor parte de los costos de ancho de banda, pero no es el único componente en tu factura.
Sobrecarga de protocolo: Se necesita tráfico adicional entre el servidor y los clientes para establecer y mantener una sesión. Según el protocolo subyacente, este tráfico podría incluir la sobrecarga de protocolo en tiempo real de Firebase Realtime Database, la sobrecarga de WebSocket y la sobrecarga del encabezado HTTP. Cada vez que se establece una conexión, esta sobrecarga, junto con cualquier sobrecarga de encriptación de SSL, contribuye a los costos de conexión. Pese a que esto no significa una gran cantidad de ancho de banda para una sola solicitud, puede ser sustancial si las cargas útiles son muy pequeñas o si haces conexiones cortas con frecuencia.
Sobrecarga de encriptación de SSL: Hay un costo asociado con la sobrecarga de encriptación de SSL necesaria para las conexiones seguras. En promedio, este costo equivale a 3.5 KB para el protocolo de enlace inicial y aproximadamente decenas de bytes para los encabezados del registro TLS en cada mensaje saliente. Para la mayoría de las apps, este es un porcentaje pequeño de la factura. Sin embargo, puede convertirse en un mayor porcentaje si tu caso específico necesita una gran cantidad de protocolos de enlace SSL. Por ejemplo, es posible que los dispositivos que no admiten solicitudes de sesión TLS necesiten una gran cantidad de protocolos de enlace de conexión SSL.
Datos de Firebase console: Pese a que, comúnmente, esto no es una porción
significativa de los costos de Realtime Database, Firebase cobra por los datos que lees y
escribes desde Firebase console.
Estima el uso facturado
Para ver las conexiones y el uso de datos actuales de Realtime Database, consulta la pestaña
Uso
en Firebase console. Puedes revisar el uso en el período de
facturación actual, los últimos 30 días o las últimas 24 horas.
Firebase muestra estadísticas de uso para las siguientes métricas:
Conexiones: La cantidad de conexiones simultáneas actualmente abiertas a tu base de datos en tiempo real. Esto incluye las siguientes conexiones en tiempo real: WebSocket, sondeos largos y eventos enviados por el servidor HTML. No incluye solicitudes RESTful.
Almacenamiento: La cantidad de datos que se almacenan en la base de datos. Esto no incluye el hosting de Firebase ni los datos almacenados a través de otros productos de Firebase.
Descargas: Todos los bytes descargados de tu base de datos, incluidas las sobrecargas de protocolo y de encriptación.
Carga: Este gráfico muestra qué porcentaje de la base de datos se está usando en el procesamiento de solicitudes, en un intervalo determinado de 1 minuto. Pueden surgir problemas de rendimiento a medida que la base de datos se acerca al 100%.
Optimiza el uso
Te ofrecemos algunas prácticas recomendadas para optimizar los costos de ancho de banda y uso de la base de datos.
Usa los SDK nativos: Siempre que sea posible, usa los SDK que correspondan a la plataforma de tu app, en lugar de la API de REST. Los SDK mantienen conexiones abiertas, lo que reduce los costos de encriptación de SSL que comúnmente se suman con la API de REST.
Verifica que no haya errores: Si los costos de ancho de banda son inesperadamente altos, verifica que la app no esté sincronizando más datos ni se esté sincronizando con mayor frecuencia de lo esperado. Para identificar problemas, usa el generador de perfiles a fin de medir las operaciones de lectura y activar el registro de depuración en los SDK de
Android,
Objective-C,
y la Web. Verifica los procesos en segundo plano y de sincronización de la app para asegurarte de que todo funcione según lo esperado.
Reduce las conexiones: Si es posible, intenta optimizar el ancho de banda de la conexión. Las solicitudes de REST pequeñas y frecuentes pueden ser más costosas que una conexión única y continua con el SDK nativo. Además, si usas la API de REST, te recomendamos usar una conexión HTTP continua o eventos enviados por el servidor, los que pueden reducir los costos de los protocolos de enlace SSL.
Usa solicitudes de sesión TLS: Reduce los costos por la sobrecarga de encriptación de SSL en las conexiones reanudadas mediante la emisión de solicitudes de sesión TLS.
Esto es particularmente útil si necesitas conexiones frecuentes y seguras a la base de datos.
Indexa las consultas:Indexar tus datos reduce el ancho de banda total que usas para las consultas, lo que ofrece el beneficio doble de reducir los costos y de aumentar el rendimiento de la base de datos. Usa el generador de perfiles para encontrar consultas no indexadas en la base de datos.
Optimiza los objetos de escucha: Agrega consultas para limitar los datos que muestran las operaciones de escucha y usa agentes de escucha que solo descarguen actualizaciones de los datos. Por ejemplo, on() en lugar de once(). Además, ubica los agentes de escucha en una ruta de acceso lo más específica que puedas para limitar la cantidad de datos que sincronizan.
Reduce los costos de almacenamiento: Ejecuta trabajos de limpieza periódicos y reduce los datos duplicados en tu base de datos.
Usa reglas: Evita cualquier operación potencialmente costosa y no autorizada en la base de datos. Por ejemplo, usar Firebase Realtime Database Security Rules permite evitar una situación
en la que un usuario malicioso descargue reiteradamente toda tu base de datos.
Obtén más información sobre el
uso de reglas de Firebase Realtime Database.
El mejor plan de optimización para la app depende de tu caso de uso específico.
Si bien esta no es una lista exhaustiva de prácticas recomendadas, puedes encontrar más consejos y sugerencias de los expertos de Firebase en nuestro canal de Slack o en Stack Overflow.
[null,null,["Última actualización: 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)."]]
