Общие сведения о выставлении счетов за базу данных в реальном времени
Оптимизируйте свои подборки
Сохраняйте и классифицируйте контент в соответствии со своими настройками.
Firebase выставляет счета за данные, хранящиеся в вашей базе данных, и за весь исходящий сетевой трафик на сеансовом уровне (уровень 5) модели OSI. Стоимость хранения составляет 5 долларов США за каждый ГБ в месяц, оплата производится ежедневно. Расположение базы данных не влияет на тарификацию. Исходящий трафик включает в себя расходы на подключение и шифрование, связанные со всеми операциями с базой данных, а также данные, загруженные при чтении из неё. Как чтение, так и запись в базу данных могут привести к включению в ваш счёт платы за подключение. Весь трафик, входящий и исходящий из вашей базы данных, включая операции, запрещённые правилами безопасности, ведёт к оплате.
Вот некоторые распространенные примеры тарифицируемого трафика:
Загруженные данные: когда клиенты получают данные из вашей базы данных, Firebase взимает плату за загрузку данных. Обычно это составляет большую часть расходов на пропускную способность, но это не единственный фактор, учитываемый в вашем счёте.
Накладные расходы протокола: для установления и поддержания сеанса между сервером и клиентами требуется дополнительный трафик. В зависимости от используемого протокола, этот трафик может включать в себя: накладные расходы протокола реального времени Firebase Realtime Database, накладные расходы WebSocket и накладные расходы HTTP-заголовков. При каждом установлении соединения эти накладные расходы, в сочетании с накладными расходами на SSL-шифрование, увеличивают стоимость соединения. Хотя для одного запроса это не так много, это может стать существенной частью вашего счета, если объём полезной нагрузки невелик или вы часто используете короткие соединения.
Накладные расходы на SSL-шифрование: накладные расходы на SSL-шифрование, необходимые для обеспечения безопасности соединений, определённые. В среднем эти расходы составляют около 3,5 КБ для начального согласования и около десятков байт для заголовков записей TLS в каждом исходящем сообщении. Для большинства приложений это небольшая доля вашего счёта. Однако эта доля может стать значительной, если в вашем конкретном случае требуется много SSL-подтверждений. Например, устройства, не поддерживающие билеты сеанса TLS, могут потребовать большого количества SSL-подтверждений.
Данные консоли Firebase : хотя обычно это не составляет значительной части расходов на Realtime Database , Firebase взимает плату за данные, которые вы считываете и записываете из консоли Firebase .
Оцените ваш счет за использование
Чтобы узнать текущие подключения Realtime Database и объём использования данных, откройте вкладку « Использование» в консоли Firebase . Вы можете проверить использование за текущий расчётный период, последние 30 дней или последние 24 часа.
Firebase показывает статистику использования по следующим показателям:
Подключения: количество одновременных открытых в данный момент подключений к вашей базе данных в режиме реального времени. Сюда входят следующие подключения в режиме реального времени: WebSocket, длинные опросы и HTML-события, отправленные сервером. RESTful-запросы сюда не входят.
Хранилище: объём данных, хранящихся в вашей базе данных. Сюда не входят данные, хранящиеся на хостинге Firebase или в других продуктах Firebase.
Загрузки: все байты, загруженные из вашей базы данных, включая затраты на протокол и шифрование.
Нагрузка: этот график показывает, какая часть вашей базы данных используется для обработки запросов в течение заданного минутного интервала. Проблемы с производительностью могут возникнуть, когда загрузка базы данных приближается к 100%.
Оптимизировать использование
Существует несколько лучших методов, которые вы можете использовать для оптимизации использования базы данных и затрат на пропускную способность.
Используйте собственные SDK: по возможности используйте SDK, соответствующие платформе вашего приложения, вместо REST API. SDK поддерживают открытые соединения, снижая затраты на SSL-шифрование, которые обычно возникают при использовании REST API.
Проверьте наличие ошибок: если ваши расходы на полосу пропускания неожиданно высоки, убедитесь, что ваше приложение не синхронизирует больше данных или не делает это чаще, чем планировалось. Чтобы выявить проблемы, используйте инструмент профилирования для измерения операций чтения и включите отладочное ведение журнала в Android , Objective-C и Web SDK. Проверьте фоновые процессы и процессы синхронизации в вашем приложении, чтобы убедиться, что всё работает так, как задумано.
Сократите количество подключений: по возможности оптимизируйте пропускную способность соединения. Частые и небольшие REST-запросы могут быть более затратными, чем одно постоянное соединение с использованием нативного SDK. Если вы используете REST API, рассмотрите возможность использования HTTP-подтверждения активности или событий, отправляемых сервером , что может снизить затраты на SSL-подтверждения.
Используйте билеты сеанса TLS: сократите накладные расходы на SSL-шифрование при возобновлении соединений, выпустив билеты сеанса TLS . Это особенно полезно, если вам требуются частые и безопасные подключения к базе данных.
Индексирование запросов:индексация данных сокращает общую пропускную способность, используемую для запросов, что даёт двойное преимущество: снижение затрат и повышение производительности базы данных. Используйте инструмент профилирования для поиска неиндексированных запросов в вашей базе данных.
Оптимизируйте прослушиватели: добавьте запросы, чтобы ограничить объём данных, возвращаемых операциями прослушивания, и используйте прослушиватели, которые загружают только обновления данных, например, on() вместо once() . Кроме того, размещайте прослушиватели как можно дальше по пути, чтобы ограничить объём синхронизируемых ими данных.
Сокращение затрат на хранение: периодически выполняйте задания по очистке и удаляйте дублирующиеся данные из базы данных.
Использование правил: предотвратите любые потенциально дорогостоящие несанкционированные операции с вашей базой данных. Например, использование Firebase Realtime Database Security Rules поможет избежать ситуации, когда злоумышленник многократно загружает всю вашу базу данных. Узнайте больше об использовании правил Firebase Realtime Database Rules .
Оптимальный план оптимизации для вашего приложения зависит от конкретного сценария использования. Хотя это не исчерпывающий список рекомендаций, вы можете найти больше советов и рекомендаций от экспертов Firebase на нашем канале в Slack или на Stack Overflow .
[null,null,["Последнее обновление: 2025-08-22 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)."]]
