# Supabase と Firebase の比較

Supabase は Postgres（SQL）、Firebase は Firestore（NoSQL）。無料枠はどちらも商用可だが性質が逆で、Supabase は7日無操作で一時停止、Firebase は外部 HTTP 通信に有料プランが要る。

## 主要な差分

- データベース: Supabase = Postgres（SQL）/ Firebase = Firestore（NoSQL ドキュメント）。
- 無料枠の落とし穴: Supabase は7日間アクティビティが無いと自動一時停止。Firebase Spark は外部 HTTP 通信が不可。
- ロックイン: Supabase は OSS でセルフホスト可。Firebase はプロプライエタリ。
- カスタムドメイン: Supabase は Pro 以上。Firebase Hosting は無料。

## 解説と実務上の注意

### 選択の本質は 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 であってホスティングが主目的ではないため、フロントエンドを別のホスティングに置く構成なら、この差はほぼ無関係になります。

## Rights

| key | Supabase | Firebase |
|---|---|---|
| commercial_use_allowed | yes | yes |

## Constraints

| key | Supabase | Firebase |
|---|---|---|
| api_available | yes | yes |
| cron_available | yes | yes |
| custom_domain_available | conditional | yes |
| webhook_available | yes | yes |

## 結論：どちらを選ぶべきか

**Supabase を選ぶべきケース** — SQL と JOIN が使いたい、要件がまだ固まっていない、集計や管理画面が必要、無料枠で外部 API を叩きたい、ベンダーロックインを避けたい。

**Firebase を選ぶべきケース** — リアルタイム同期が中心、読み書きのパターンが明確、モバイルアプリで認証・プッシュ通知・クラッシュレポートまで一式まとめたい、Google エコシステムに乗っている。

**どちらでも必須の設定** — Supabase 無料枠なら7日の自動停止を防ぐ監視。Firebase Blaze なら予算アラート。どちらも設定を怠ると事故に直結します。

## よくある質問

### Supabase の無料プロジェクトが止まるのはなぜですか？

無料枠は7日間アクティビティがないと自動的に一時停止します。復帰には手動操作が必要です。アクセスがまばらな用途では、定期的な監視かPro プランへの移行を検討してください。

### Firebase の無料プランで外部 API を呼べますか？

呼べません。Spark プランでは Cloud Functions からの外部 HTTP 通信が制限されており、Blaze（従量課金）への移行が必要です。外部 API 連携が要件なら Supabase のほうが無料枠で完結します。

### あとから Firebase から他のサービスに移行できますか？

容易ではありません。Firestore は NoSQL の独自データモデルで、移行先で同じ形のまま動くものがないため、実質的にデータ設計とアプリの書き直しになります。Supabase は素の Postgres なので pg_dump で他のマネージド Postgres に移せます。

### Firebase で高額請求になることはありますか？

あります。Blaze は完全な従量課金で、Firestore は読み取り件数で課金されるため、非効率なクエリが高額請求を生む事故が実際に起きています。予算アラートの設定は必須です。

## 関連ページ

- Supabase: https://atlas.lb-product.com/entities/supabase
- Firebase: https://atlas.lb-product.com/entities/firebase

Canonical HTML: https://atlas.lb-product.com/compare/supabase-vs-firebase