はじめに

先日、画像を自動切替表示するデジタルサイネージWebアプリをFirebase(Firestore / Storage / Authentication / Hosting)で開発・公開しました。

実はこのアプリ、Firebase版が初めてではありません。最初はバックエンドにSupabaseを使って一度作っていたのです。それをわざわざFirebaseで作り直したのには、明確な理由がありました。

この記事では、「機能比較」ではなく運用と料金体系の相性という観点から、なぜ乗り換えたのかを整理します。同じように「たまにしか使わないアプリ」を個人開発している方の参考になれば嬉しいです。

前提:このアプリの使われ方は「月イチ」「半年に一度」

まず大事な前提として、私のデジタルサイネージアプリは毎日動くサービスではありません。

こういった「ここぞ」というタイミングでだけ起動して、画像をループ表示する。それ以外の期間は、誰もアクセスしない。

つまり、普段は完全に眠っていて、たまに確実に動いてほしいという、かなり特殊な稼働パターンのアプリなのです。実は、この稼働パターンこそがBaaS選びの落とし穴でした。

Supabaseの無料プランには、7日間アクティビティがないとプロジェクトが自動的に一時停止(pause)されるという仕様があります。

正確に言うと、データが即座に消えるわけではありません。データは保持されていて、ダッシュボードにログインして手動で復元すれば復活します。ただし——

つまり「月イチ利用」の私のアプリは、使おうとするたびに必ず停止状態になっているわけです。展示会当日の朝、会場で「あ、復元し忘れてた」となったら目も当てられません。

対策として「週一でログインしてアクティビティを発生させる」運用をしていたのですが、これがまた地味にしんどい。アプリのためにアプリを起こしに行く、本末転倒な毎週のタスクが発生していました。

補足: GitHub Actionsで定期的にDBへpingを打つ「延命策」も有名ですが、「無料枠を維持するために別の仕組みを組んで監視する」こと自体が、もう運用コストですよね。

そして決定打がこちら。週一の「起こしに行く」作業の際、うっかりアプリを表示させたまま放置してしまったことがありました。

有料プランで利用していた私のもとに翌月届いたのは、想定外の請求。数千円〜万近い金額を見て、血の気が引きました。

もちろんこれは私の不注意です。でも、「不注意が即・お金に直結する」「請求額が翌月になるまで体感できない」という構造は、個人開発者にとってかなりのストレスでした。

私のように「月イチ・半年に一度」しか使わないアプリの場合、アクセスがない期間の課金は実質ゼロ。眠っているアプリには課金されない料金体系は、まさに低頻度利用と相性ぴったりでした。

Firebaseには「○日間使わないと停止」という仕様がありません。半年放置しても、展示会当日にURLを開けば何の儀式もなくそのまま動きます。

「週一の起こしに行く作業」から解放されたのは、精神的にかなり大きかったです。

Google Cloud(Firebase)では、事前に「この金額に達したら通知して」と予算アラートを設定できます。設定した金額の50%・90%・100%といった段階でメールが届くので、「翌月突然、万近くの請求書を見て恐れおののく」という事態を避けられます。

⚠️ 注意: 予算アラートはあくまで通知であり、課金を自動的に止めてくれるわけではありません。アラートが来たら自分で原因を確認・対処する必要があります。ここを誤解すると逆に危ないので要注意。

それでも、「気づかないまま課金が膨らみ続ける」のと「早い段階でメールで気づける」のとでは、安心感がまったく違います。

誤解のないように書いておくと、Supabaseが悪いサービスだという話ではありません。

PostgreSQLがそのまま使える強力さ、オープンソースで自己ホストもできる柔軟さなど、Supabaseにしかない魅力はたくさんあります。毎日アクセスがある通常のWebサービスなら、7日停止の仕様はそもそも問題になりません。

ただ、月イチ・半年に一度しか動かないアプリという私のユースケースに限って言えば——

——という比較になり、Firebaseに軍配が上がりました。

BaaS選びの記事は「機能」や「DBの種類」の比較が多いですが、個人開発では自分のアプリの稼働パターンと、料金・停止ポリシーの相性こそが、実は一番効いてくるのかもしれません。

同じように「たまにしか使わないアプリ」を作っている方は、契約前にぜひ放置したらどうなるかを確認してみてください。