Firebase

無料の Spark プランは「外部と通信できない」

Firebase の無料 Spark プランは商用利用も可能で寛大に見えますが、設計上の壁が1つあります。公式の料金ページは Spark の Outbound networking を「該当なし」としており、Cloud Functions から Google 以外のサービスへ HTTP リクエストを送れません。

これが意味するのは、以下がすべて Blaze（従量課金）必須だということです。

• 決済プロバイダの API 呼び出し（Stripe、PayPal など）
• LLM API の呼び出し（OpenAI、Anthropic など）
• 外部サービスへの Webhook 送信
• 自社の別 API との連携
• 通知サービス（SendGrid、Slack など）

外部連携が要件に1つでもあるなら、Firebase の無料枠は最初から選択肢になりません。 多くのプロジェクトが構築の途中でこれに気付きます。

対して Supabase の Edge Functions は無料枠でも外部 HTTP を発行できます。外部 API 連携が主要件なら、この一点で比較の結論が決まります。

Blaze の従量課金は上限なし。事故が実際に起きている

Blaze は完全な従量課金で、上限を設定していないと請求が青天井になり得ます。

特に危険なのが Firestore の課金構造です。「読み取ったドキュメント数」で課金されるため、以下が直接コストになります。

• 一覧画面で大量のドキュメントを取得する実装
• ループの中でクエリを発行する実装
• リアルタイムリスナーの張りすぎ

非効率なクエリが一晩で高額請求を生む事故は実際に起きています。Blaze を有効にするなら、予算アラートの設定は運用開始時の必須作業です。推奨ではありません。

Firestore は「クエリを先に決める」データベース

Firestore は NoSQL のドキュメントストアです。SQL に慣れていると設計を誤ります。

• JOIN がない
• 集計が苦手（件数を数えるだけでも工夫が要る）
• 「この画面でこう表示する」に合わせてデータを非正規化して持つのが基本設計

書き込み時にコストを払って読み込みを速くするモデルなので、はまれば非常に速い。反面、後から画面要件が変わるとデータ構造そのものを作り直すことになりがちです。要件が固まっていない段階では、後からデータモデルを変えられる Postgres 系のほうが安全です。

出口が狭い

長期で見て最大のリスクはここです。Firestore は Firestore にしか存在しません。 データをエクスポートできても、その形のまま動く移行先がない。移行は実質的にデータ設計とアプリケーションの書き直しになります。

これは Firebase が悪いという話ではなく、深く使うほど生産性が上がる代わりに離脱コストが上がるという取引です。取引だと理解したうえで選ぶなら問題ありません。

Hosting は素直に無料

静的ホスティングについては制約が少なく、カスタムドメインと SSL が Spark でも無料です。フロントエンドの配信だけに使うなら、無料枠でも実用になります。

定期実行

Cloud Scheduler と Cloud Functions の組み合わせで実現しますが、これも Blaze が必要です。無料で定期実行したい場合は成立しません。