Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Firebase, veritabanınızda depoladığınız veriler ve OSI modelinin oturum katmanındaki (5. katman) tüm giden ağ trafiği için faturalandırma yapar. Depolama alanı, günlük olarak değerlendirilen aylık GB başına 5 ABD doları üzerinden faturalandırılır. Faturalandırma, veritabanınızın konumundan etkilenmez. Giden trafik, tüm veritabanı işlemlerinden gelen bağlantı ve şifreleme ek yükünü ve veritabanı okumaları aracılığıyla indirilen verileri içerir. Hem veritabanı okuma hem de yazma işlemleri faturanızda bağlantı maliyetlerine yol açabilir. Güvenlik kuralları tarafından reddedilen işlemler de dahil olmak üzere veritabanınıza ve veritabanınızdan gelen tüm trafik, faturalandırılabilir maliyetlere yol açar.
Faturalandırılan trafiğe ilişkin bazı yaygın örnekler şunlardır:
İndirilen veriler: İstemciler veritabanınızdan veri aldığında Firebase, indirilen veriler için ücret alır. Bu genellikle bant genişliği maliyetlerinizin büyük bir kısmını oluşturur ancak faturanızdaki tek faktör değildir.
Protokol ek yükü: Bir oturumun oluşturulması ve sürdürülmesi için sunucu ile istemciler arasında ek trafik gerekir. Temel protokole bağlı olarak bu trafik şunları içerebilir: Firebase Realtime Database'in gerçek zamanlı protokol ek yükü, WebSocket ek yükü ve HTTP başlığı ek yükü. Her bağlantı kurulduğunda bu ek yük, SSL şifreleme ek yüküyle birlikte bağlantı maliyetlerine katkıda bulunur. Bu, tek bir istek için çok fazla bant genişliği olmasa da yükleriniz küçükse veya sık sık kısa bağlantılar yapıyorsanız faturanızın önemli bir bölümünü oluşturabilir.
SSL şifreleme ek yükü: Güvenli bağlantılar için gerekli olan SSL şifreleme ek yüküyle ilişkili bir maliyet vardır. Ortalama olarak bu maliyet, ilk el sıkışma için yaklaşık 3,5 KB, her giden mesajdaki TLS kaydı başlıkları için ise yaklaşık onlarca bayttır. Çoğu uygulama için bu, faturanızın küçük bir yüzdesidir. Ancak, belirli bir durumda çok sayıda SSL el sıkışması gerekiyorsa bu oran büyük bir yüzdeye ulaşabilir. Örneğin, TLS oturum biletlerini desteklemeyen cihazlar çok sayıda SSL bağlantı el sıkışması gerektirebilir.
Firebase konsol verileri: Bu, genellikle Realtime Database maliyetlerinin önemli bir bölümünü oluşturmasa da Firebase, Firebase konsolundan okuduğunuz ve yazdığınız veriler için ücret alır.
Faturalandırılmış kullanımınızı tahmin etme
Mevcut Realtime Database bağlantılarınızı ve veri kullanımınızı görmek için Firebase konsolundaki Kullanım sekmesini kontrol edin. Mevcut faturalandırma dönemi, son 30 gün veya son 24 saatteki kullanımı kontrol edebilirsiniz.
Firebase, aşağıdaki metriklerle ilgili kullanım istatistiklerini gösterir:
Bağlantılar: Veritabanınıza yapılan eşzamanlı, şu anda açık olan gerçek zamanlı bağlantı sayısı. WebSocket, uzun anket ve HTML sunucu tarafından gönderilen etkinlikler gibi anlık bağlantılar bu kapsamdadır. RESTful istekleri içermez.
Depolama: Veritabanınızda ne kadar veri depolandığı. Firebase Hosting veya diğer Firebase ürünleri aracılığıyla depolanan veriler bu sınıra dahil değildir.
İndirmeler: Protokol ve şifreleme ek yükü dahil olmak üzere veritabanınızdan indirilen tüm baytlar.
Yük: Bu grafik, belirli bir 1 dakikalık aralıkta veritabanınızın ne kadarının kullanıldığını ve istekleri işlediğini gösterir. Veritabanınız %100'e yaklaştıkça performans sorunları yaşayabilirsiniz.
Kullanımı optimize etme
Veritabanı kullanımınızı ve bant genişliği maliyetlerinizi optimize etmek için uygulayabileceğiniz birkaç en iyi uygulama vardır.
Yerel SDK'ları kullanın: Mümkün olduğunda REST API yerine uygulamanızın platformuna karşılık gelen SDK'ları kullanın. SDK'lar açık bağlantıları korur ve genellikle REST API ile artan SSL şifreleme maliyetlerini azaltır.
Hataları kontrol edin: Bant genişliği maliyetleriniz beklenmedik şekilde yüksekse uygulamanızın başlangıçta amaçladığınızdan daha fazla veri senkronize etmediğini veya daha sık senkronize etmediğini doğrulayın. Sorunları belirlemek için profiler aracını kullanarak okuma işlemlerinizi ölçün ve Android, Objective-C ve Web SDK'larında hata ayıklama günlük kaydını etkinleştirin. Uygulamanızdaki arka plan ve senkronizasyon işlemlerini kontrol ederek her şeyin istediğiniz gibi çalıştığından emin olun.
Bağlantı sayısını azaltın: Mümkünse bağlantı bant genişliğinizi optimize etmeyi deneyin. Sık yapılan küçük REST istekleri, yerel SDK kullanılarak yapılan tek ve sürekli bağlantıdan daha maliyetli olabilir. REST API'yi kullanıyorsanız SSL el sıkışmalarından kaynaklanan maliyetleri azaltabilecek bir HTTP keep-alive veya sunucu tarafından gönderilen etkinlikler kullanmayı düşünebilirsiniz.
TLS oturum biletlerini kullanın:TLS oturum biletleri vererek devam ettirilen bağlantılarda SSL şifreleme ek yükü maliyetlerini azaltın.
Bu özellik, özellikle veritabanına sık ve güvenli bağlantılar kurmanız gerekiyorsa yararlıdır.
Dizin sorguları:Verilerinizi dizine eklemek
sorgular için kullandığınız toplam bant genişliğini azaltır. Bu da maliyetlerinizi düşürme ve veritabanınızın performansını artırma gibi iki avantaj sağlar. Veritabanınızda dizinlenmemiş sorguları bulmak için
Profiler aracını kullanın.
Dinleyicilerinizi optimize edin: Dinleme işlemlerinizin döndürdüğü verileri sınırlamak için sorgular ekleyin ve yalnızca verilerdeki güncellemeleri indiren dinleyicileri kullanın (ör. once() yerine on()). Ayrıca, dinleyicilerin senkronize ettiği veri miktarını sınırlamak için onları mümkün olduğunca aşağıya yerleştirin.
Depolama maliyetlerini azaltın: Düzenli olarak temizleme işleri çalıştırın ve veritabanınızdaki yinelenen verileri azaltın.
Kuralları kullanın: Veritabanınızda maliyetli olabilecek yetkisiz işlemleri önleyin. Örneğin, Firebase Realtime Database Security Rules kullanmak kötü niyetli bir kullanıcının veritabanınızın tamamını tekrar tekrar indirdiği bir senaryoyu önleyebilir.
Firebase Realtime Database kurallarını kullanma hakkında daha fazla bilgi edinin.
Uygulamanız için en iyi optimizasyon planı, kullanım alanınıza bağlıdır.
Bu, en iyi uygulamaların kapsamlı bir listesi olmasa da Slack kanalımızda veya Stack Overflow'da Firebase uzmanlarından daha fazla tavsiye ve ipucu bulabilirsiniz.
[null,null,["Son güncelleme tarihi: 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)."]]
