با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
صورتحساب Firebase برای داده هایی که در پایگاه داده خود ذخیره می کنید و تمام ترافیک شبکه خروجی در لایه جلسه (لایه 5) مدل OSI. هزینه ذخیره سازی 5 دلار برای هر گیگابایت در ماه محاسبه می شود که روزانه ارزیابی می شود. صورتحساب تحت تأثیر موقعیت پایگاه داده شما قرار نمی گیرد. ترافیک خروجی شامل سربار اتصال و رمزگذاری از کلیه عملیات پایگاه داده و داده های دانلود شده از طریق خواندن پایگاه داده است. هم خواندن و هم نوشتن پایگاه داده می تواند منجر به هزینه های اتصال در صورتحساب شما شود. تمام ترافیک به و از پایگاه داده شما، از جمله عملیاتی که توسط قوانین امنیتی رد شده است، منجر به هزینه های قابل پرداخت می شود.
برخی از نمونه های رایج ترافیک صورتحساب عبارتند از:
داده‌های بارگیری‌شده: وقتی مشتریان داده‌ها را از پایگاه داده شما دریافت می‌کنند، Firebase هزینه داده‌های دانلود شده را دریافت می‌کند. به طور معمول، این بخش عمده هزینه های پهنای باند شما را تشکیل می دهد، اما این تنها عامل در صورتحساب شما نیست.
سربار پروتکل: مقداری ترافیک اضافی بین سرور و کلاینت ها برای ایجاد و نگهداری یک جلسه ضروری است. بسته به پروتکل زیربنایی، این ترافیک ممکن است شامل موارد زیر باشد: سربار پروتکل بیدرنگ پایگاه داده Firebase، سربار WebSocket و سربار هدر HTTP. هر بار که یک اتصال برقرار می شود، این سربار، همراه با هر سربار رمزگذاری SSL، به هزینه های اتصال کمک می کند. اگرچه این پهنای باند زیادی برای یک درخواست واحد نیست، اما اگر بارهای شما کوچک باشد یا اتصالات مکرر و کوتاه داشته باشید، می تواند بخش قابل توجهی از صورتحساب شما باشد.
سربار رمزگذاری SSL: هزینه های مربوط به سربار رمزگذاری SSL برای اتصالات ایمن ضروری است. به طور متوسط، این هزینه تقریباً 3.5 کیلوبایت برای دست دادن اولیه و تقریباً ده ها بایت برای سرصفحه های ضبط TLS در هر پیام ارسالی است. برای اکثر برنامه ها، این درصد کمی از صورت حساب شما است. با این حال، اگر مورد خاص شما نیاز به دست دادن های SSL زیادی داشته باشد، این می تواند درصد زیادی داشته باشد. برای مثال، دستگاه‌هایی که از بلیط‌های جلسه TLS پشتیبانی نمی‌کنند ممکن است به تعداد زیادی دست دادن اتصال SSL نیاز داشته باشند.
داده‌های کنسول Firebase : اگرچه این معمولاً بخش قابل‌توجهی از هزینه‌های Realtime Database نیست، Firebase برای داده‌هایی که از کنسول Firebase می‌خوانید و می‌نویسید هزینه‌ای را دریافت می‌کند.
مصرف صورتحساب خود را تخمین بزنید
برای مشاهده اتصالات کنونی Realtime Database و مصرف داده، برگه Usage را در کنسول Firebase بررسی کنید. می‌توانید میزان استفاده را در دوره صورتحساب فعلی، 30 روز گذشته یا 24 ساعت گذشته بررسی کنید.
Firebase آمار استفاده را برای معیارهای زیر نشان می دهد:
اتصالات: تعداد اتصالات همزمان، در حال حاضر باز و بیدرنگ به پایگاه داده شما. این شامل اتصالات بیدرنگ زیر است: WebSocket، نظرسنجی طولانی، و رویدادهای ارسال شده توسط سرور HTML. این شامل درخواست های RESTful نیست.
ذخیره سازی: چه مقدار داده در پایگاه داده شما ذخیره می شود. این شامل میزبانی Firebase یا داده های ذخیره شده از طریق سایر محصولات Firebase نمی شود.
دانلودها: تمام بایت های دانلود شده از پایگاه داده شما، از جمله سربار پروتکل و رمزگذاری.
بارگذاری: این نمودار نشان می دهد که چه مقدار از پایگاه داده شما در یک بازه زمانی 1 دقیقه ای در حال پردازش است، درخواست ها را پردازش می کند. با نزدیک شدن به 100% پایگاه داده شما ممکن است مشکلات عملکرد را مشاهده کنید.
استفاده را بهینه کنید
چند روش وجود دارد که می توانید برای بهینه سازی استفاده از پایگاه داده و هزینه های پهنای باند خود از آنها استفاده کنید.
از SDK های بومی استفاده کنید: در صورت امکان، به جای REST API از SDK هایی استفاده کنید که با پلتفرم برنامه شما مطابقت دارند. SDK ها اتصالات باز را حفظ می کنند و هزینه های رمزگذاری SSL را که معمولاً با REST API جمع می شود، کاهش می دهند.
اشکالات را بررسی کنید: اگر هزینه‌های پهنای باند شما به طور غیرمنتظره‌ای بالا است، بررسی کنید که برنامه شما داده‌های بیشتری را همگام‌سازی نمی‌کند یا بیشتر از آنچه در نظر داشتید همگام‌سازی نمی‌کند. برای مشخص کردن مشکلات، از ابزار نمایه ساز برای اندازه‌گیری عملیات خواندن خود استفاده کنید و ثبت اشکال‌زدایی را در Android ، Objective-C و Web SDK روشن کنید. پس‌زمینه و فرآیندهای همگام‌سازی را در برنامه خود بررسی کنید تا مطمئن شوید همه چیز همانطور که می‌خواهید کار می‌کند.
کاهش اتصالات: در صورت امکان، سعی کنید پهنای باند اتصال خود را بهینه کنید. درخواست های مکرر و کوچک REST می تواند پرهزینه تر از یک اتصال منفرد و مداوم با استفاده از SDK بومی باشد. اگر از REST API استفاده می‌کنید، استفاده از رویدادهای HTTP حفظ زنده یا ارسال‌شده توسط سرور را در نظر بگیرید، که می‌تواند هزینه‌های دست دادن SSL را کاهش دهد.
از بلیط‌های جلسه TLS استفاده کنید: با صدور بلیط‌های جلسه TLS ، هزینه‌های سربار رمزگذاری SSL در اتصالات از سر گرفته شده را کاهش دهید. اگر به اتصالات مکرر و ایمن به پایگاه داده نیاز دارید، این به ویژه مفید است.
پرس و جوهای شاخص:نمایه سازی داده های شما کل پهنای باندی را که برای پرس و جوها استفاده می کنید کاهش می دهد، که این مزیت مضاعف کاهش هزینه ها و افزایش عملکرد پایگاه داده شما دارد. از ابزار profiler برای یافتن پرس و جوهای فهرست نشده در پایگاه داده خود استفاده کنید.
شنوندگان خود را بهینه کنید: برای محدود کردن داده‌هایی که عملیات گوش دادن شما برمی‌گرداند، درخواست‌هایی اضافه کنید و از شنونده‌هایی استفاده کنید که فقط به‌روزرسانی‌های داده‌ها را دانلود می‌کنند - برای مثال، on() به جای once() . علاوه بر این، شنوندگان خود را تا جایی که می توانید در پایین مسیر قرار دهید تا میزان داده های همگام سازی آنها را محدود کنید.
کاهش هزینه های ذخیره سازی: کارهای پاکسازی دوره ای را اجرا کنید و داده های تکراری را در پایگاه داده خود کاهش دهید.
قوانین استفاده: از هر گونه عملیات بالقوه پرهزینه و غیرمجاز در پایگاه داده خود جلوگیری کنید. به عنوان مثال، استفاده از Firebase Realtime Database Security Rules می تواند از سناریویی جلوگیری کند که در آن یک کاربر مخرب به طور مکرر کل پایگاه داده شما را دانلود می کند. درباره استفاده از قوانین پایگاه داده بیدرنگ Firebase بیشتر بیاموزید.
بهترین طرح بهینه سازی برای برنامه شما به مورد استفاده خاص شما بستگی دارد. اگرچه این فهرست جامعی از بهترین روش‌ها نیست، می‌توانید توصیه‌ها و نکات بیشتری را از کارشناسان Firebase در کانال Slack یا Stack Overflow بیابید.
تاریخ آخرین بهروزرسانی 2025-08-29 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین بهروزرسانی 2025-08-29 بهوقت ساعت هماهنگ جهانی."],[],[],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)."]]
