Firebase는 데이터베이스에 저장하는 데이터 및 OSI 모델의 세션 계층(계층 5)의
모든 발신 트래픽에 대해 요금을 청구합니다. 1GB당 $5의 스토리지 요금이 매월 청구되며 평가는 매일 이루어집니다. 청구 금액은 고객의 데이터베이스 위치에 영향을 받지 않습니다. 아웃바운드 트래픽에는 모든 데이터베이스 작업의 연결 및 암호화 오버헤드와 데이터베이스 읽기를 통해 다운로드한 데이터가 포함됩니다. 데이터베이스 읽기와 쓰기 모두에 대해 연결 비용이 청구될 수 있습니다. 보안 규칙에 의해 거부된 작업을 포함하여 데이터베이스와 주고받는 모든 트래픽이 청구 가능 비용이 됩니다.
청구 대상 트래픽의 일반적인 예는 다음과 같습니다.
다운로드한 데이터: 클라이언트가 데이터베이스에서 데이터를 가져오면 Firebase는
다운로드한 데이터에 대해 요금을 부과합니다. 일반적으로 이 요금이 대역폭 비용에서
큰 부분을 차지하지만 유일한 항목은 아닙니다.
프로토콜 오버헤드: 세션을 설정하고 유지하려면 서버와 클라이언트 간에
추가적인 트래픽이 필요합니다. 기본 프로토콜에 따라 이 트래픽에는
Firebase 실시간 데이터베이스의 실시간 프로토콜 오버헤드, WebSocket
오버헤드, HTTP 헤더 오버헤드가 포함될 수 있습니다. 연결이
설정될 때마다 이 오버헤드와 함께 SSL 암호화 오버헤드가
연결 비용에 추가됩니다. 단일 요청이라면 이러한 오버헤드가 많은 대역폭을
차지하지는 않지만 페이로드가 작거나 짧은 연결을 자주 하는 경우에는
요금에서 상당한 부분을 차지할 수 있습니다.
SSL 암호화 오버헤드: 보안 연결에 필요한 SSL 암호화 오버헤드에
대해서도 비용이 발생합니다. 평균적으로 이 비용은
초기 핸드셰이크의 경우 약 3.5KB, 각 발신 메시지의 TLS 레코드 헤더의 경우
약 수십 바이트입니다. 대부분의 앱은 요금에서 이 비용이 미미한 비중을
차지합니다. 그러나 SSL 핸드셰이크가 많이 필요한 경우라면
큰 비중을 차지하게 될 수 있습니다. 예를 들어 기기에서 TLS 세션 티켓을 지원하지 않는 경우 SSL 연결 핸드셰이크가 많이 필요할 수 있습니다.
Firebase Console 데이터: 일반적으로 Realtime Database 비용에서 큰 부분은 아니지만, Firebase Console에서 읽고 쓰는 데이터에 대해 요금이 부과됩니다.
청구 사용량 추정
현재 Realtime Database 연결과 데이터 사용량을 보려면 Firebase Console에서 사용량 탭을 확인하세요. 현재 결제 기간, 지난 30일, 지난 24시간 동안의 사용량을 확인할 수 있습니다.
Firebase는 다음 측정항목에 대한 사용량 통계를 보여줍니다.
연결: 현재 열려 있는 데이터베이스 실시간 동시 연결
수입니다. 여기에는 WebSocket, 장기 폴링, HTML 서버 전송
이벤트와 같은 실시간 연결이 포함됩니다. RESTful 요청은
포함되지 않습니다.
저장용량: 데이터베이스에 저장된 데이터의 양입니다. Firebase 호스팅 또는
다른 Firebase 제품을 통해 저장된 데이터는 포함되지 않습니다.
다운로드: 프로토콜 및 암호화 오버헤드를 포함하여 데이터베이스에서
다운로드한 모든 바이트입니다.
로드: 이 그래프는 지정된 1분 간격 동안 요청을 처리하는 데 데이터베이스를
얼마나 사용하는지 보여줍니다. 데이터베이스가 100%에 가까워지면 성능 문제가 발생할 수 있습니다.
사용 최적화
데이터베이스 사용량 및 대역폭 비용을 최적화하기 위한 권장사항은 다음과 같습니다.
기본 SDK 사용: 가능하면 REST API 대신 앱의 플랫폼에 해당하는
SDK를 사용하세요. SDK는 개방형 연결을 유지하므로 REST API를
사용할 때 일반적으로 추가되는 SSL 암호화 비용이
줄어듭니다.
버그 확인: 대역폭 비용이 예상보다 높다면 앱의 동기화 데이터 양이나 빈도가 원래 의도한 것보다 더 많은지 확인해 보세요. 문제의 원인을 찾아내려면 프로파일러 도구를 사용하여 읽기 작업을 측정하고 Android, Objective-C, 웹 SDK에서 디버그 로깅을 사용합니다. 앱의 백그라운드 및 동기화 프로세스를
점검하여 정상적으로 작동하는지 확인하세요.
연결 줄이기: 가능하면 연결 대역폭을 최적화하세요. 작고 빈번한 REST 요청은 기본 SDK를 사용한 단일 연속 연결보다 비용이 많이 들 수 있습니다. REST API를 사용하는 경우 HTTP 연결 유지 또는 서버 전송 이벤트를 사용하여 SSL 핸드셰이크에 따르는 비용을 줄여 보세요.
TLS 세션 티켓 사용:TLS 세션 티켓을 발급하여 재개된 연결의 SSL 암호화 오버헤드 비용을 줄이세요.
이 방법은 데이터베이스에 대한 보안 연결이 자주 필요한 경우에
특히 유용합니다.
쿼리 색인 생성:데이터 색인을 생성하면 쿼리에 사용되는 총 대역폭이 감소하여 비용 절감과 데이터베이스 성능 향상을 동시에 이룰 수 있습니다. 프로파일러 도구를 사용하면 데이터베이스에서 색인이 생성되지 않은 쿼리를 발견할 수 있습니다.
리스너 최적화: 리슨 작업으로 반환되는 데이터를 제한하는 쿼리를 추가하고 데이터 업데이트만 다운로드하는 리스너(예: once() 대신 on())를 사용하세요. 또한 리스너를 경로에서 최대한 하위에 배치하여 동기화하는 데이터 양을 제한하세요.
저장소 비용 줄이기: 주기적으로 정리 작업을 실행하고 데이터베이스의
중복 데이터를 줄이세요.
규칙 사용: 데이터베이스에서 비용이 많이 발생할 수 있는 승인되지 않은
작업을 방지합니다. 예를 들어 Firebase Realtime Database Security Rules을 사용하면 악의적인 사용자가 전체 데이터베이스를 반복적으로 다운로드하는 상황을 피할 수 있습니다.
Firebase 실시간 데이터베이스 규칙 사용에 대해 자세히 알아보세요.
앱에 가장 적합한 최적화 계획은 구체적인 사용 사례에 따라 다릅니다.
위에서 설명한 내용 외에도 추가 권장사항이 있으며, Slack 채널 또는 Stack Overflow에서 Firebase 전문가의 조언과 도움말을 더 찾아볼 수 있습니다.
[null,null,["최종 업데이트: 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)."]]
