ゲームのデータベース選び：Firestore・Supabase・自前
遊びをつくる執筆にClaudeを使用しています。
ブラウザゲームにスコアの永続保存やセーブデータのクラウド同期を追加しようとするとき、最初にぶつかる問いが「どのデータベースを使うか」です。選択肢はFirestore（Firebase）、Supabase、そして自前サーバー構築の大きく三つに分かれますが、どれが「正解」かはゲームの規模・更新頻度・開発者のスキルセットによって変わります。 この記事では三つの選択肢をゲーム開発の文脈で比較し、「今の自分のプロジェクトにどれが合うか」を判断するための基準と、選んだあとの最初の一歩を示します。セーブデータの設計方法や暗号化の話は別途扱い、ここではデータベース選択そのものに絞ります。
Firestoreが向いているケース
FirestoreはGoogleのFirebaseプラットフォームが提供するNoSQLドキュメントデータベースです。ゲーム開発者に広く使われている理由は、リアルタイム同期がSDK一行で動く点と、フロントエンドのJavaScriptから直接読み書きできる点にあります。バックエンドサーバーを別途用意しなくてよいため、HTMLとJavaScriptだけで作ったブラウザゲームに最も素直につながります。
向いているのは次のような状況です。
- マルチプレイヤーのスコアボードやロビー状態など、複数クライアントへのリアルタイム配信が必要な場面
- 開発初期でスキーマが固まっておらず、構造を柔軟に変えたい場面
- Firebase AuthenticationやCloud Functionsと組み合わせてエコシステムを一本化したい場合
注意すべき点は料金体系です。Firestoreは読み取り・書き込み・削除の「操作回数」で課金されます。ゲームのランキング画面を毎秒ポーリングするような設計にすると、ユーザーが増えた途端に請求が急増します。リアルタイムリスナーを使ってサーバー側からプッシュを受け取る設計にするか、更新頻度を意識したクエリ設計が必要です。料金の上限や無料枠の詳細は公式サイトで最新の条件を確認してください。
データ構造の選び方も重要です。セーブデータはユーザーIDをドキュメントキーにしたコレクションに丸ごとJSONで保存するのが基本形です。一方、ランキングのような「全ユーザー横断の並び替え」はFirestoreが苦手とする操作のひとつで、クエリに使えるインデックスの組み合わせに制約があります。
Supabaseが向いているケース
Supabaseはオープンソースのバックエンドサービスで、内部でPostgreSQLを使います。ゲーム開発者にとっての最大の特徴は、SQLがそのまま使えることと、テーブル定義・インデックス・リレーションといったRDBの資産を活かせる点です。
向いているのは次のような状況です。
- スコア・プレイ履歴・アイテム所持数など、構造が固まっているデータを集計・ランキング化したい場面
- SQLに慣れている開発者がバックエンドも自分で制御したい場合
- Row Level Security（RLS）を使って「自分のデータは自分だけ読める」というアクセス制御をSQLで書きたい場合
SupabaseにもリアルタイムAPIはありますが、FirestoreのリアルタイムリスナーほどシンプルではなくPostgresのロジカルレプリケーション経由のため、設定の手間が増えます。リアルタイム性よりもデータの整合性や集計のしやすさを優先するゲームに向いています。
JavaScriptからはSupabaseの公式クライアントライブラリを使い、CDNで読み込んでフロントエンドから直接クエリを投げる構成が最も手軽です。ただし、テーブルへの直接アクセスをそのまま公開すると悪意あるユーザーに操作される恐れがあるため、RLSポリシーの設定は省略しないようにしてください。料金・無料枠の詳細は公式サイトを確認してください。
自前サーバー構築が向いているケース
「自前」とは、Node.js＋ExpressやPython＋FastAPIなどでAPIサーバーを自分で立て、データベース（PostgreSQL、MySQLなど）も自分で管理する構成です。VPSやコンテナサービスを借りて運用します。
この選択が合うのは次のケースです。
- ゲームロジックをサーバー側で検証しなければならないチート対策が必要な場合
- データの保存場所や形式に関して厳格な要件がある場合（たとえば特定国のサーバーへの限定など）
- すでに自前のAPIサーバーが存在し、そこに機能追加するほうが自然な場合
反対に、個人開発の初期段階や小規模なゲームでは運用コストと学習コストが見合わないことがほとんどです。サーバーの死活監視、バックアップ、セキュリティパッチの適用まで自分で回す必要があるため、ゲーム開発そのものに使える時間が削られます。
自前を選ぶ場合でも、認証だけはFirebase AuthenticationやSupabase Authに任せてトークンを検証する設計にすると、ゼロからセッション管理を実装するより安全で手間が少なくなります。
三択を決める判断フロー
どれを選ぶか迷ったときは、次の順序で問いに答えてみてください。
- リアルタイム同期が必要か？ 必要ならFirestoreが最も手軽です。
- SQLで集計・ランキングを書きたいか？ 書きたいならSupabaseが向いています。
- サーバー側でゲームロジックの検証が必要か？ 必要なら自前サーバー一択です。
- どれも当てはまらない場合、セーブデータをユーザーごとに保存するだけなら、SupabaseのシンプルなCRUDで十分なことが多いです。
開発の途中で選択を変えるのは大きなコストになります。プロトタイプ段階でも「どんな操作が一番多いか」を想像してから選ぶと、後から作り直す手間を減らせます。ランキングを出したいなら最初からSQLが使えるデータベースを選ぶ、という判断が典型例です。
また、アソバースのクラウドセーブ機能（SDK対応が必要）を使う選択肢もあります。自前でデータベースを用意せずにセーブデータを扱いたい場合は、アソバースSDKの対応範囲を公式情報で確認してみてください。
最初の一歩：選んだあとに最初にやること
Firestoreを選んだ場合： Firebaseコンソールでプロジェクトを作成し、Firestoreをテストモードで起動してブラウザから書き込みが通るか確認します。確認できたら即座にセキュリティルールを本番用に切り替え、認証済みユーザーだけが自分のドキュメントを読み書きできる最小ルールを設定します。テストモードのまま公開するのは危険です。
Supabaseを選んだ場合： プロジェクト作成後、まずテーブルエディタでスコアテーブルを一つ作り、RLSを有効化してから「自分のレコードだけ読み書きできる」ポリシーを追加します。ポリシーなしでRLSを有効にするとすべてのアクセスが拒否されるので、ポリシーの追加を忘れないようにしてください。
自前サーバーを選んだ場合： まずローカルでAPIエンドポイントを一本だけ作り、フロントエンドのゲームからfetchで呼び出せるところまで確認します。デプロイ先はRailwayやFlyなどのコンテナホスティングが初期設定の手間が少なく、CORSの設定とHTTPS化を忘れずに行ってください。
次の行動
Firestore・Supabase・自前のいずれかに絞ったら、まず無料枠の範囲で動作確認用のプロジェクトを一つ作り、ゲームのフロントエンドからデータを一件書き込んで読み出すだけの最小構成を動かしてみてください。セキュリティルールやRLSポリシーは確認と同時に設定する習慣をつけると、後からの修正が格段に減ります。作ったゲームをアソバースに投稿する際は、データベースの接続先やAPIキーをHTMLに直書きせず、環境変数や設定ファイルで管理する方法もあわせて調べてみてください。
参考資料
- Firebase公式ドキュメント（Firestore セキュリティルール）
- Supabase公式ドキュメント（Row Level Security）
- MDN Web Docs（Fetch API）
