Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Firebase menagih biaya untuk data yang Anda simpan di database dan semua traffic jaringan keluar pada lapisan sesi (lapisan 5) model OSI. Besarnya biaya penyimpanan adalah $5 untuk tiap GB/bulan, dan ini dievaluasi setiap harinya. Penagihan tidak terpengaruh oleh lokasi database Anda. Traffic keluar mencakup overhead koneksi dan enkripsi dari semua operasi database dan data yang didownload melalui operasi baca database. Operasi baca dan tulis database dapat terhitung sebagai biaya koneksi pada tagihan Anda. Semua traffic yang menuju dan berasal dari database Anda, termasuk operasi yang ditolak oleh aturan keamanan, dapat dikenakan biaya.
Beberapa contoh umum dari traffic yang ditagih meliputi:
Data yang didownload: Saat klien mendapatkan data dari database Anda, Firebase mengenakan biaya untuk data yang didownload. Biasanya, ini merupakan sebagian besar dari biaya bandwidth Anda, tetapi bukan satu-satunya faktor dalam tagihan.
Overhead protokol: Diperlukan beberapa traffic tambahan antara server dan klien untuk membuat dan mempertahankan sesi. Bergantung pada protokol yang mendasarinya, traffic ini mungkin mencakup: overhead protokol realtime Firebase Realtime Database, overhead WebSocket, dan overhead header HTTP. Setiap kali koneksi dibuat, overhead ini, yang digabungkan dengan overhead enkripsi SSL, menimbulkan biaya koneksi. Meskipun tidak memerlukan bandwidth yang besar untuk satu permintaan, overhead ini bisa dikenakan biaya yang signifikan jika payload Anda kecil atau Anda sering membuat koneksi pendek.
Overhead enkripsi SSL: Ada biaya terkait overhead enkripsi SSL yang diperlukan untuk koneksi yang aman. Rata-rata, biaya yang dikenakan adalah sekitar 3,5 KB untuk handshake awal dan sekitar puluhan byte untuk header record TLS pada setiap pesan keluar. Untuk kebanyakan aplikasi, biaya ini hanya merupakan sebagian kecil dari tagihan Anda. Namun, persentase biaya ini bisa meningkat jika kasus Anda memerlukan banyak handshake SSL. Misalnya, perangkat yang tidak mendukung tiket sesi TLS kemungkinan akan memerlukan handshake koneksi SSL dalam jumlah besar.
Data Firebase console: Firebase mengenakan biaya untuk pembacaan dan penulisan data yang Anda lakukan dari Firebase console, meskipun biasanya bukan merupakan persentase yang besar dalam total biaya Realtime Database.
Memperkirakan tagihan penggunaan Anda
Untuk melihat koneksi dan penggunaan data Realtime Database Anda saat ini, buka tab Usage di Firebase console. Anda dapat memeriksa penggunaan untuk periode penagihan saat ini, 30 hari terakhir, atau 24 jam terakhir.
Firebase menunjukkan statistik penggunaan untuk metrik berikut:
Koneksi: Jumlah koneksi realtime simultan yang saat ini terbuka ke database Anda. Ini mencakup koneksi realtime berikut: WebSocket, long polling, dan peristiwa HTML yang dikirim oleh server. Koneksi tidak mencakup permintaan RESTful.
Penyimpanan: Jumlah data yang tersimpan dalam database Anda. Ini tidak mencakup hosting Firebase atau data yang disimpan melalui produk Firebase lainnya.
Download: Semua byte yang didownload dari database Anda, termasuk overhead protokol dan enkripsi.
Load: Grafik ini menunjukkan banyaknya penggunaan database Anda untuk memproses permintaan, selama interval 1 menit yang ditentukan. Anda mungkin akan mengalami masalah performa saat beban database mendekati 100%.
Mengoptimalkan penggunaan
Ada beberapa praktik terbaik yang dapat dilakukan untuk mengoptimalkan penggunaan database dan biaya bandwidth.
Gunakan SDK native: Jika memungkinkan, gunakan SDK yang sesuai dengan platform aplikasi Anda, bukan REST API. SDK mempertahankan koneksi terbuka, sehingga mengurangi biaya enkripsi SSL yang biasanya bertambah jika menggunakan REST API.
Periksa bug: Jika biaya bandwidth Anda tinggi, pastikan aplikasi tidak melakukan banyak sinkronisasi data atau sering melakukan sinkronisasi di luar keinginan Anda. Untuk menemukan masalah secara tepat, gunakan alat profiler untuk mengukur operasi baca dan mengaktifkan logging debug di SDK Android, Objective-C, dan Web. Periksa proses sinkronisasi dan proses yang berjalan di latar belakang pada aplikasi Anda untuk memastikan semuanya sesuai keinginan Anda.
Kurangi koneksi: Jika memungkinkan, cobalah untuk mengoptimalkan bandwidth koneksi Anda. Permintaan REST yang kecil tetapi sering mungkin memerlukan biaya yang lebih mahal daripada koneksi tunggal dan berkelanjutan yang menggunakan SDK native. Jika Anda menggunakan REST API, pertimbangkan untuk menggunakan HTTP keep-alive atau peristiwa yang dikirim server, guna mengurangi biaya dari handshake SSL.
Gunakan tiket sesi TLS: Kurangi biaya overhead enkripsi SSL pada koneksi yang dilanjutkan dengan menerbitkan tiket sesi TLS.
Metode ini sangat praktis jika Anda memerlukan koneksi rutin dan aman ke database.
Kueri indeks:Pengindeksan data mengurangi total bandwidth yang digunakan untuk kueri dan memberikan dua keuntungan, yaitu mengurangi biaya serta meningkatkan performa database. Gunakan alat profiler untuk menemukan kueri yang tidak terindeks di database Anda.
Optimalkan pemroses: Tambahkan kueri untuk membatasi data yang ditampilkan oleh operasi pemrosesan dan manfaatkan pemroses yang hanya mendownload pembaruan data — misalnya, on() dan bukan once(). Selain itu, tempatkan pemroses sedalam mungkin pada jalur untuk membatasi jumlah data yang disinkronkan.
Kurangi biaya penyimpanan: Jalankan tugas pembersihan berkala dan kurangi data duplikat di database Anda.
Gunakan Aturan: Cegah operasi yang berpotensi mahal dan tidak sah pada database Anda. Misalnya, penggunaan Firebase Realtime Database Security Rules dapat menghindari skenario yang memungkinkan pengguna yang berbahaya mendownload seluruh database Anda berulang kali.
Pelajari lebih lanjut cara menggunakan Aturan Firebase Realtime Database.
Rencana pengoptimalan terbaik untuk aplikasi Anda bergantung pada kasus penggunaan Anda.
Meskipun daftar ini belum mencakup semua praktik terbaik yang tersedia, Anda dapat menemukan saran dan tips lainnya dari pakar Firebase di saluran Slack atau Stack Overflow kami.
[null,null,["Terakhir diperbarui pada 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)."]]
