Firebase Realtime Databaseとは｜JSONツリー同期の仕組みと転送量課金【2026年8月時点】

Firebase Realtime Databaseは、データベース全体を1本のJSONツリーとして保持し、接続中のクライアントへ変更をミリ秒単位で配るNoSQLデータベースです。同じFirebaseのCloud Firestoreが読み書きの回数で課金されるのに対し、こちらは保存容量と転送量の2軸だけで課金されます。本記事では、JSONツリーのデータモデルと同期の仕組み、ディスク永続化がApple・Androidに限られるオフライン挙動、ダウンロード量に含まれるプロトコルとSSLの上乗せ分、同時接続20万と毎秒1,000書き込みというスケール上限、そしてCloud Firestoreとの選定基準までを実装者の判断材料として整理します。数値は2026年8月時点の公式ドキュメントおよび料金ページの記載です。

まとめ：転送量と同時接続で決まるRealtime Databaseの採用判断

結論から示します。Realtime Databaseの本質は、単一のJSONツリーに対する購読型の同期エンジンであり、クエリエンジンではありません。ソートと絞り込みを同時に指定できず、テーブル結合もない代わりに、小さなデータの往復を10ミリ秒級で返す一点に振り切った設計になっています。

課金構造も他と違います。読み書きの回数は数えず、保存容量とダウンロード量だけで積み上がる方式で、単価は保存が1GBあたり5ドル毎月、ダウンロードが1GBあたり1ドル。ここで見落としがちなのが、実データ以外にWebSocketのプロトコルとSSL暗号化の分が上乗せされ、セキュリティルールで拒否されたリクエストにも課金される点です。

採用の可否は用途で切り分けられます。プレゼンス表示、共同編集のカーソル、ゲームの状態同期のように、小さなJSONを高頻度で往復させる処理なら第一候補。逆に、履歴データを溜め続ける用途や、複数条件の絞り込みと並べ替えを同時に求める一覧画面では、ドキュメント型のCloud Firestoreに寄せたほうが素直に組めます。

Realtime Databaseの単一JSONツリー構造とリアルタイム同期の仕組み

データモデルと同期方式は表裏一体です。この構造を理解しないまま設計すると、後述する転送量課金がそのまま跳ね返ります。

データベース全体を1本のJSONツリーとして扱う構造と32階層の上限

Realtime Databaseは、テーブルもコレクションも持ちません。データベース1つがまるごと1本のJSONツリーで、すべてのデータはルートからのパスで指し示します。チャットなら messages の下にメッセージIDのノードを置き、その中に本文と送信者IDを持たせる形です。

この構造には、明確な副作用が伴う点に注意が必要です。あるパスを購読すると、その配下のデータがすべて配信対象になるため、深い階層に大きな塊をぶら下げると、1件だけ見たい場面でも配下全体がダウンロードされます。公式が推奨するのはツリーを平たく保つ設計で、上限としてもネストの深さは32階層までと定められています。名前空間を分けるつもりで階層を掘る癖は、ここでは通用しません。

変更をミリ秒で配るリスナーとWebSocket接続の維持コスト

クライアントSDKは、参照したパスに対してリスナーを登録し、サーバー側の変更を受け取ります。通信はリクエストとレスポンスの往復ではなく、開いたままの接続を通じて差分が押し出される方式です。公式は、データが変わるたびに接続中の端末がミリ秒以内に更新を受け取ると説明しており、典型的なレイテンシは10ミリ秒級とされています。

接続は開きっぱなしが前提になります。単一データベースからのブロードキャストと読み取りは、同時レスポンスが毎秒10万程度まで。この方式が効くのは更新頻度が高く1件が小さいデータで、逆に数分に1回しか変わらない参照データを常時購読させると、接続の維持コストだけが積み上がります。サーバー側から変更を検知して処理を走らせたい場合は、Realtime Databaseトリガーを持つCloud Functions for Firebaseを挟む形が定石です。

キー768バイト・文字列10MB・1書き込み16MBという構造上の制約

設計前に頭へ入れておきたい上限が複数あります。特にキー長と1回あたりの書き込みサイズは、後から気づくと移行が重くなる項目です。

キーはUTF-8で768バイトまでで、改行・ピリオド・ドル記号・ブラケット・スラッシュなどは使えません。メールアドレスをそのままキーにする設計がつまずくのはこの制約が理由で、ハッシュ化するか認証側のUIDを使う回避が要ります。REST経由なら1書き込み256MBまで通りますが、SDKからは16MBが壁。画像や動画のバイナリはCloud Storage側へ置き、ツリーには参照だけを持たせる分担が前提です。その置き場所側のバケット構成とセキュリティルールはCloud Storage for Firebaseのルール設計と課金の数え方で扱っています。

オフライン挙動とonDisconnectで組む接続状態の管理設計

オフライン対応はRealtime Databaseの売りの一つですが、プラットフォームによって前提が変わります。ここを取り違えると、Webアプリで期待した挙動が出ません。

ディスク永続化がApple・Androidに限られるプラットフォーム差

公式のデータベース比較表は、Realtime Databaseのオフライン対応をApple・Androidクライアント向けと明記しています。Cloud Firestoreが3系統すべてでオフラインをサポートするのに対し、こちらのWeb SDKにはディスクへの永続化がありません。ブラウザのタブを閉じればキャッシュは消えます。

モバイル側では、SDKがローカルにデータを保持するため、圏外でも読み書きが続き、再接続時に差分が同期されます。地下やエレベーターでの一時的な切断を吸収したいモバイルアプリなら、この挙動がそのまま価値になる仕組み。Webのみで完全なオフライン動作が要件に入っているなら、Realtime Databaseは要件を満たしません。この一点だけでFirestoreを選ぶ理由になります。

onDisconnectと接続状態フラグで作るプレゼンス管理の実装

接続が切れた瞬間に処理を走らせる仕掛けが、サーバー側にあらかじめ書き込みを予約する onDisconnect です。切断・更新・削除の各操作を登録でき、サーバーはセキュリティルールを検証したうえで、接続が失われた時点でそれを実行します。予約は cancel で取り消せます。

この仕掛けが最も効くのがプレゼンス管理です。ログイン時にオンライン状態を書き、同時に切断時のオフライン書き込みを予約しておけば、アプリが強制終了しても状態が残りません。クライアント自身の接続状態は、専用の読み取り専用フラグを購読して判定します。フラグはクライアントごとの状態を表すため、他の端末とは同期されない点に注意してください。認証情報と紐づけて誰がオンラインかを表すなら、Firebase Authenticationが払い出すUIDをキーに使うのが素直な設計です。

保存容量と転送量の2軸で積み上がるRealtime Databaseの課金構造

Firestoreとの費用比較でつまずくのは、数える対象が違うためです。回数ではなくバイト数で積み上がる前提に切り替える必要があります。

保存5ドル毎GBとダウンロード1ドル毎GBの単価と無料枠の実額

無料のSparkプランと従量課金のBlazeプランで、枠の切り方が変わります。同時接続数に上限が設けられているのはRealtime Database特有で、Firestoreの料金表には対応する行がありません。

Blazeでも保存1GBとダウンロード1日360MB（月あたり約10GB相当）までは無料枠に収まります。保存容量は日次で評価される方式で、履歴を溜め続けると単価5ドルがそのまま毎月効いてくる構造。プロジェクト全体でFirestoreやCloud Functionsを併用する場合の合算試算は、Firebaseの料金と無料枠・Blaze超過単価の実額にまとめています。

請求対象のダウンロード量に含まれるプロトコルとSSL暗号化の分

請求額が見積もりと合わない典型的な原因が、実データ以外の上乗せです。公式は課金対象のダウンロードとして、データ本体に加えて、セッションの確立と維持に必要なプロトコルのオーバーヘッド、そしてSSL暗号化の分を挙げています。初回ハンドシェイクで約3.5KB、以降は送信メッセージごとにTLSレコードヘッダの数十バイトが乗る計算です。

ここから導かれる注意点が3つあります。第一に、小さなメッセージを高頻度で送るほどオーバーヘッドの比率が上がるため、RESTで1件ずつ叩く実装は接続を張り続けるSDKより割高になりがちです。第二に、Firebaseコンソール上での読み書きにも課金されます。第三に、セキュリティルールで拒否されたリクエストも通信としては発生しており、課金対象に含まれます。ルールの書き漏れは、情報漏えいだけでなく請求にも跳ね返る設計です。

database:profileで洗い出す帯域と未インデックスクエリ

どのパスが帯域を食っているかは、推測ではなく計測で把握可能です。Firebase CLIには firebase database:profile というプロファイラがあり、パスごとの応答速度、送受信バイト数、そしてインデックスを張らずに実行された高コストなクエリを報告します。追加すべきインデックスのルールも提示されます。

実行にはプロジェクトの編集者以上の権限が要り、コマンド起動後にログを収集して、Enterキーで集計に移る流れです。--raw を付けると、ユーザーエージェントやIPを含む個々の操作まで確認できます。CLIの認証とプロジェクト切り替えの運用はFirebase CLIの認証とデプロイ運用で扱いました。請求が跳ねてから調べるより、負荷試験の段階で1度回しておくほうが安く済みます。

同時接続20万と毎秒1000書き込みで来るスケール上限と分割

自動でどこまでも伸びるFirestoreと違い、こちらには具体的な天井があります。天井の位置を知ったうえで設計するかどうかで、運用の難易度が変わります。

単一データベースの上限値とマルチデータベースへ分割する判断基準

1つのデータベースがさばけるのは、公式の記載で同時接続20万、書き込み毎秒1,000程度まで。書き込みはソフト上限で、超えると調整が入る扱いです。リスナーが張られたパス配下は累計7,500万ノードまでという制限もあり、1本のツリーに全ユーザーのデータを載せ続ける設計は、ある規模で頭打ちになります。

回避手段は、同一プロジェクト内に複数のデータベースインスタンスを作ってデータを分割するシャーディングです。テナントごと、機能ごとにインスタンスを分け、それぞれにセキュリティルールを持たせることが可能です。ただし複数データベースはBlazeプラン限定で、アプリ側はどのインスタンスに何があるかを解決する仕組みを自前で持つ必要があります。この運用を持てないチームが20万接続を見込むなら、上限のないFirestoreを選ぶほうが総コストは低く収まります。

リージョン3拠点とURL形式の差・後から変更できない作成時の選択

インスタンスを置ける場所は、us-central1（アイオワ）、europe-west1（ベルギー）、asia-southeast1（シンガポール）の3拠点です。日本国内のリージョンはありません。国内利用でレイテンシを詰めるならシンガポールが最も近い選択肢になります。

URLの形式も拠点で変わり、us-central1だけが firebaseio.com のドメインを使い、他の2拠点は firebasedatabase.app 側のドメインになります。SDKの初期化やCIの環境変数で参照先を誤ると、空のデータベースへ接続して原因究明に時間を取られる箇所。加えて、いったん作成したインスタンスのロケーションは後から変更できません。データの所在地に制約がある案件では、プロジェクト作成の段階で確定させてください。作成手順そのものはFirebaseの導入手順にまとめています。

Cloud Firestoreとの選定基準とRealtime Databaseを見送る場面

ここは中立に並べず、判断を言い切ります。Realtime Databaseは古いから避けるべき製品ではなく、刺さる用途が狭いだけの製品です。

ソートか絞り込みのどちらか一方に限られるクエリ制約と設計への影響

公式の比較で明示されているとおり、Realtime Databaseのクエリはプロパティに対する並べ替えか絞り込みのどちらか一方しか指定できません。Firestoreのように複数条件を連結して、絞り込みと並べ替えを1つのクエリで組み合わせる書き方は通らない仕様です。

実務での影響は一覧画面に集中します。「未読のみを新着順で20件」のような要求は、条件を結合したキーを別途持たせるか、多めに取得してクライアント側で絞る対処になり、後者はそのまま転送量課金に乗ります。インデックスはセキュリティルールの中に indexOn として宣言する方式で、宣言がないクエリはサーバー側で全件を評価するため、データ量が増えるほど遅く高くなる仕組みです。引きたいクエリが複数条件を含む時点で、Firestore側に寄せる判断が妥当になります。

Realtime Databaseを選ぶ具体条件と見送るべき失敗パターン

採用してよいのは次の条件を満たす場合です。1件のペイロードが小さく更新頻度が高い、同時接続が20万に届かない規模、クエリが単純なパス取得と単一条件で足りる、そしてモバイル中心でオフライン継続が要る。プレゼンス、共同編集のカーソル位置、対戦ゲームの状態、IoT機器の現在値といった処理が該当します。Firestoreは読み書きの回数で課金されるため、毎秒何度も小さな値を書き換える処理ではRealtime Databaseのほうが費用面で有利です。

逆に、見送るべきパターンを挙げます。チャットの全履歴やログを溜め続ける用途は、保存単価5ドル毎GBが毎月効いて費用が膨らむ典型例。複数条件の検索や集計が中心の管理画面も、クエリ制約に対して非正規化を重ねる作業が積み上がり、破綻します。結合と集計が要件の中心なら、GraphQL経由でCloud SQLを扱うFirebase Data Connectを検討する道もあります。Webだけで完結するアプリでオフライン動作を求める要件も対象外です。既存プロダクトの請求が保存側で膨らんでいるなら、直近データだけをRealtime Databaseに残し、履歴をFirestoreやBigQueryへ逃がす二段構えが定石。こうしたデータベース選定やGoogle Cloud上のバックエンド構築を外部に任せたい場合は、Google Cloudを含むインフラ構築と受託開発から相談できます。

よくある質問

Realtime Databaseの採用を検討する実装者から挙がりやすい質問をまとめます。

Realtime DatabaseとCloud Firestoreはどちらを選ぶべきですか？

扱うデータの形とクエリ要件で決まります。小さなJSONを高頻度で往復させ、クエリが単一条件で足りるならRealtime Databaseが向きます。複数条件の絞り込みと並べ替えを組み合わせる、Webでもオフライン動作が要る、同時接続の上限を意識したくない、といった要件があるならFirestoreです。新規プロジェクトで判断がつかない場合は、機能範囲の広いFirestoreから始め、レイテンシや書き込み頻度で問題が出た部分だけをRealtime Databaseへ寄せる構成が扱いやすくなります。

Realtime Databaseは今後も新規プロジェクトで使えますか？

2026年8月時点で提供は継続しており、料金ページにも通常のプロダクトとして単価が掲載されています。Blazeプランでの複数データベース作成やリージョン選択も現行機能です。ただしFirebaseの新機能はFirestore側を軸に追加される傾向があり、ベクトル検索のような後発機能はRealtime Database側に用意されていません。将来的な機能拡張を織り込む要件なら、その差を前提に選んでください。

同時接続数が上限に近づいたらどう対処しますか？

1データベースあたりの同時接続は20万が上限です。近づいた場合の公式な対処は、同一プロジェクト内に複数のデータベースインスタンスを作り、テナントや機能単位でデータを分割するシャーディングになります。分割はBlazeプランでのみ可能で、接続先の振り分けはアプリ側の実装です。あわせて、常時購読が不要な参照データを都度取得へ切り替えると、接続数と転送量の両方が下がります。

ローカル環境でRealtime Databaseの動作を確認できますか？

できます。Firebase Local Emulator Suiteに Realtime Database のエミュレータが含まれ、既定では9000番ポートで動きます。セキュリティルールの許可と拒否、トリガー関数の発火、データ移行スクリプトの流し込みまでローカルで確認でき、課金も発生しません。Java実装のため、実行環境にJDKが要る点だけ注意してください。

Realtime Databaseの設計や移行を外部に相談できますか？

可能です。ツリー構造の設計、転送量を抑えるリスナーの張り方、FirestoreやBigQueryへ履歴を逃がす二段構えの構成、既存アプリからの移行まで受託開発で対応できます。データモデルは後から変更するほど手戻りが大きくなるため、要件が固まる前の段階でご相談ください。

関連記事

• Cloud Firestoreとは？NoSQLドキュメントDBの仕組み・料金・実装判断：ドキュメント型の対になる選択肢で、読み取り回数課金とインデックス設計を扱っています。
• Firebaseの料金｜無料枠とBlaze超過単価の実額：プロジェクト横断で単価を合算し、予算アラートを設定する際の参照先です。
• Cloud Functions for Firebaseとは｜トリガー設計と第2世代の実装判断：データ変更を受けてサーバー側の処理を走らせる関数の設計です。
• Firebase Local Emulator Suiteとは｜ローカル再現の構成とCI組み込み：ルールとトリガーをローカルで検証する手順をまとめています。
• Firebase Authenticationとは？認証方式・導入手順・料金：セキュリティルールと組み合わせる認証基盤の導入です。