Supabase と Firebase の比較

選択の本質は SQL か NoSQL か

機能表を並べる前に、この2つを分けている一番大きな要素を確認しておきます。Supabase は Postgres、Firebase は Firestore です。 リレーショナルかドキュメントか、という設計思想の違いがそのまま開発体験と将来の制約を決めます。

Postgres（Supabase）の利点は、データモデルを後から変えられることです。 JOIN が書け、集計クエリが素直に書け、外部キー制約でデータ整合性を DB 側に担保させられます。要件が固まっていない段階でも、正規化してから後で見直すという普通の進め方ができます。

Firestore（Firebase）はクエリパターンを先に決める必要があります。 JOIN がなく、複雑な集計が苦手で、「この画面でこう表示する」に合わせてデータを非正規化して持つのが基本設計になります。書き込み時にコストを払って読み込みを速くするモデルなので、はまれば非常に速い。ただし後から画面要件が変わると、データ構造そのものを作り直すことになりがちです。

判断の目安はシンプルです。要件が固まっていない、レポートや管理画面で集計を出す予定がある → Supabase。読み書きのパターンが明確で、リアルタイム同期が主役 → Firebase。

無料枠の落とし穴が正反対

どちらも無料枠で商用利用できます（commercial_use_allowed: yes）が、罠の位置が違います。

Supabase の無料枠は、7日間アクティビティがないとプロジェクトが自動的に一時停止します。 復帰は手動操作です。アクセスがまばらな社内ツールや、公開したまま放置しがちな小規模サービスでは、気付かないうちに止まっていたという事故が起きます。監視を入れていなければ、ユーザーからの報告で初めて気付くことになります。

Firebase Spark（無料）の制約はもっと構造的です。Cloud Functions から外部への HTTP 通信ができません。 Google 外部の API を叩く処理は、Blaze（従量課金）への移行が必須になります。外部の決済 API、通知サービス、自社の別 API — こうした連携が1つでも要件にあるなら、Firebase の無料枠は最初から選択肢になりません。

対して Supabase の Edge Functions は無料枠でも外部 HTTP を発行できます。 外部 API 連携が要件にあるなら、この一点で Supabase が有利です。

従量課金の怖さは Firebase のほうが大きい

Blaze プランは完全な従量課金で、上限を設定していないと請求が青天井になり得ます。 Firestore は「読み取り件数」で課金されるため、非効率なクエリ（大量ドキュメントの取得、ループ内でのクエリ発行）が一晩で高額請求を生む事故が実際に起きています。Blaze を有効にするなら、予算アラートの設定は運用開始時の必須作業です。

出口の設計 — ここが最大の非対称

長期的に見て最も大きな差は、逃げられるかどうかです。

Supabase は OSS で、セルフホストできます。 中身は素の Postgres なので、いざとなれば pg_dump で吸い出して他のマネージド Postgres（RDS、Cloud SQL、Neon など）に移せます。Supabase をやめても Postgres の資産は残る。

Firebase はプロプライエタリで、Firestore は Firestore にしか存在しません。 データをエクスポートできても、その形のまま動く先がない。移行は実質的にデータモデルの再設計とアプリの書き直しになります。

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

カスタムドメイン

細かいですが実務で効きます。Firebase Hosting のカスタムドメインは無料です（custom_domain_available: yes）。Supabase のカスタムドメインは Pro 以上が必要です（custom_domain_available: conditional）。ただし Supabase は BaaS であってホスティングが主目的ではないため、フロントエンドを別のホスティングに置く構成なら、この差はほぼ無関係になります。