はじめに
先日、画像を自動切替表示するデジタルサイネージWebアプリをFirebase(Firestore / Storage / Authentication / Hosting)で開発・公開しました。
実はこのアプリ、Firebase版が初めてではありません。最初はバックエンドにSupabaseを使って一度作っていたのです。それをわざわざFirebaseで作り直したのには、明確な理由がありました。
この記事では、「機能比較」ではなく運用と料金体系の相性という観点から、なぜ乗り換えたのかを整理します。同じように「たまにしか使わないアプリ」を個人開発している方の参考になれば嬉しいです。
前提:このアプリの使われ方は「月イチ」「半年に一度」
まず大事な前提として、私のデジタルサイネージアプリは毎日動くサービスではありません。
- 月に一度の商談やイベント
- 半年に一度の展示会
こういった「ここぞ」というタイミングでだけ起動して、画像をループ表示する。それ以外の期間は、誰もアクセスしない。
つまり、普段は完全に眠っていて、たまに確実に動いてほしいという、かなり特殊な稼働パターンのアプリなのです。実は、この稼働パターンこそがBaaS選びの落とし穴でした。
Supabaseでつまずいたこと
つまずき①:7日間使わないとプロジェクトが「一時停止」される
Supabaseの無料プランには、7日間アクティビティがないとプロジェクトが自動的に一時停止(pause)されるという仕様があります。
正確に言うと、データが即座に消えるわけではありません。データは保持されていて、ダッシュボードにログインして手動で復元すれば復活します。ただし——
- 復元するまで、アプリは完全に動かない(画面は真っ白)
- 無料プランはバックアップ保持がゼロ日。停止中のデータを守ってくれるスナップショットは存在しない
- 復元操作がスムーズにいかないケースも報告されている
つまり「月イチ利用」の私のアプリは、使おうとするたびに必ず停止状態になっているわけです。展示会当日の朝、会場で「あ、復元し忘れてた」となったら目も当てられません。
対策として「週一でログインしてアクティビティを発生させる」運用をしていたのですが、これがまた地味にしんどい。アプリのためにアプリを起こしに行く、本末転倒な毎週のタスクが発生していました。
補足: GitHub Actionsで定期的にDBへpingを打つ「延命策」も有名ですが、「無料枠を維持するために別の仕組みを組んで監視する」こと自体が、もう運用コストですよね。
つまずき②:うっかり表示させたままにして、翌月の請求にビビる
そして決定打がこちら。週一の「起こしに行く」作業の際、うっかりアプリを表示させたまま放置してしまったことがありました。
有料プランで利用していた私のもとに翌月届いたのは、想定外の請求。数千円〜万近い金額を見て、血の気が引きました。
もちろんこれは私の不注意です。でも、「不注意が即・お金に直結する」「請求額が翌月になるまで体感できない」という構造は、個人開発者にとってかなりのストレスでした。
Firebaseに乗り換えて感じたこと
理由①:無料から始められる柔軟な料金体系
- 初期費用ゼロ、月額無料(Sparkプラン)で開始できるため、個人開発やプロトタイプ作成(PoC)に最適
- サービスが成長して利用者が増えた分だけ支払う従量課金制(Blazeプラン)を採用しており、無駄なコストがかからない
私のように「月イチ・半年に一度」しか使わないアプリの場合、アクセスがない期間の課金は実質ゼロ。眠っているアプリには課金されない料金体系は、まさに低頻度利用と相性ぴったりでした。
理由②:放置してもプロジェクトが止まらない
Firebaseには「○日間使わないと停止」という仕様がありません。半年放置しても、展示会当日にURLを開けば何の儀式もなくそのまま動きます。
「週一の起こしに行く作業」から解放されたのは、精神的にかなり大きかったです。
理由③:予算アラートで「請求の恐怖」を先回りできる
Google Cloud(Firebase)では、事前に「この金額に達したら通知して」と予算アラートを設定できます。設定した金額の50%・90%・100%といった段階でメールが届くので、「翌月突然、万近くの請求書を見て恐れおののく」という事態を避けられます。
⚠️ 注意: 予算アラートはあくまで通知であり、課金を自動的に止めてくれるわけではありません。アラートが来たら自分で原因を確認・対処する必要があります。ここを誤解すると逆に危ないので要注意。
それでも、「気づかないまま課金が膨らみ続ける」のと「早い段階でメールで気づける」のとでは、安心感がまったく違います。
結論:「どっちが優れているか」ではなく「自分の使い方と合うか」
誤解のないように書いておくと、Supabaseが悪いサービスだという話ではありません。
PostgreSQLがそのまま使える強力さ、オープンソースで自己ホストもできる柔軟さなど、Supabaseにしかない魅力はたくさんあります。毎日アクセスがある通常のWebサービスなら、7日停止の仕様はそもそも問題になりません。
ただ、月イチ・半年に一度しか動かないアプリという私のユースケースに限って言えば——
| 観点 | Supabase(無料/有料) | Firebase |
|---|---|---|
| 長期間放置 | 7日で一時停止 → 手動復元が必要 | 停止しない |
| 維持のための運用 | 週一ログイン or 延命cron | 不要 |
| 課金の見え方 | 翌月の請求で判明 | 予算アラートで事前通知(※自動停止ではない) |
| 低頻度利用時のコスト | プランによっては固定費 | 使った分だけ(ほぼゼロ) |
——という比較になり、Firebaseに軍配が上がりました。
BaaS選びの記事は「機能」や「DBの種類」の比較が多いですが、個人開発では自分のアプリの稼働パターンと、料金・停止ポリシーの相性こそが、実は一番効いてくるのかもしれません。
同じように「たまにしか使わないアプリ」を作っている方は、契約前にぜひ放置したらどうなるかを確認してみてください。
参考
- Supabase公式ドキュメント「Production Checklist」(無料プランの一時停止ポリシー)
- Firebase料金ページ(Spark / Blazeプラン)
- Google Cloud「予算とアラートの設定」