SupabaseとFirebaseの違いとは？個人開発での選び方

「SupabaseとFirebaseって、結局どこが違うの？」
「個人開発ならどっちを選べばいいのか知りたい！」

個人開発でバックエンドを選ぶとき、この2つは必ず候補に上がります。
ただ、比較記事を読んでも「PostgreSQLかNoSQLか」で終わってしまい、自分がどちらを選ぶべきかまでは決められないんですよね。

結論としてWebのSaaSを作るならSupabase、モバイルアプリを出すならFirebaseという分かれ方になります。
この記事では、機能の一覧表には出てこない「無料枠の止まり方」と「請求の跳ね方」まで含めて整理しました。

SupabaseとFirebaseの違いを個人開発の視点で整理する

まずは全体像からいきましょう。
2つは同じジャンルのサービスですが、成り立ちがまったく違います。

SupabaseとFirebaseはどちらもBaaSという同じ土俵にある

2つに共通しているのは、バックエンドをまるごと肩代わりしてくれるところです。
データベース、認証、ファイルストレージ、サーバーレス関数まで、必要なものが最初から入っています。

個人開発でこれがどれだけありがたいか、実際に使うとよくわかります。
サーバーを借りて、DBを立てて、バックアップを設計して……という工程がまるごと消えるからです。

Firebaseは2011年に生まれ、2014年にGoogleが買収したサービスで、モバイルアプリの世界では長く定番でした。
Supabaseは2020年に「オープンソースのFirebase代替」として出てきた後発で、Web開発の文脈で一気に広がった存在です。

セットアップの流れも、じつはよく似ています。
どちらも公式サイトでアカウントを作り、管理画面からプロジェクトを作成して、発行された鍵をアプリの環境変数に入れる。ここまでで15分ほどです。

つまり「できること」の一覧で比べても、ほとんど差が出ません。
差が出るのは、その先の作りやすさとお金のかかり方のほうですね。

いちばん大きな違いはデータベースの設計思想

2つを分けている最大の点は、データの持ち方です。
SupabaseはPostgreSQLという昔ながらのリレーショナルデータベースを、そのまま提供しています。

一方のFirebaseは、Firestoreというドキュメント型のNoSQLデータベースが中心。
テーブルと行ではなく、コレクションとドキュメントという階層でデータを持ちます。

この違いは、あとから効いてきます。
データの種類が増えて関係が絡み合ってくるほど、リレーショナルのほうが素直に書けるからです。

逆に、階層がはっきりしていて読み出しが単純なデータなら、Firestoreのほうが速くて安く済みます。
どちらが優れているという話ではなく、扱うデータの形との相性の問題です。

個人開発では「止まり方」と「請求の跳ね方」が効いてくる

機能表を見比べているうちは、正直どちらでも作れます。
でも実際に公開してみると、まったく別のところで差を感じるんですよね。

1つは、無料枠が尽きたときにどう止まるか。
Supabaseは1週間アクセスがないとプロジェクトが一時停止し、Firebaseは1日あたりの操作回数の上限で止まります。

止まり方だけでなく、超えたときにいくら請求されるのかも判断材料になります。Supabase側の内訳はSupabaseの料金は無料枠でどこまで？超過課金の落とし穴にまとめました。

もう1つは、想定外の請求が起きる条件です。
Firestoreは読み取り回数で課金されるので、ループの書き間違いがそのまま金額に変わります。

この3つは、機能比較の表にはまず載っていません。
それでいて、個人開発では一番痛い場所なんですよね。

SupabaseとFirebaseのデータベースの違い

ここからは中身を1つずつ見ていきます。
最初は、選択を左右するデータベースの違いからです。

SupabaseのPostgreSQLはJOINと制約がそのまま使える

SupabaseのデータベースはPostgreSQLそのものです。
特別な方言はなく、普段書いているSQLがそのまま通るんですよね。

たとえば「ユーザーごとの今月の売上を集計する」といった処理は、1本のクエリで書けます。

select u.email, sum(o.amount) as total
from users u
join orders o on o.user_id = u.id
where o.created_at >= date_trunc('month', now())
group by u.email;

外部キーやユニーク制約も使えるので、データの整合性をデータベース側に守らせられます。
アプリのコードで「重複してないか」を毎回チェックしなくて済むのは、1人で作るときほど効いてきますね。

管理画面からSQLエディタを開いて、その場でクエリを試せるのも便利です。
本番のデータを見ながら集計を組み立てられるので、分析用の仕組みを別に作らなくても当面は足ります。

FirebaseのFirestoreは階層構造で速く読める

Firestoreは、コレクションの中にドキュメントを置き、その中にさらにコレクションを持てる構造です。
「users/{userId}/orders/{orderId}」のように、パスでデータの居場所を表します。

この形の強みは、読み出しの速さと安定性です。
データが何百万件に増えても、パスを指定して1件取るコストはほとんど変わりません。

ただしJOINにあたる機能がないので、複数の種類のデータをまたぐ集計は苦手です。
「ユーザーごとの売上合計」を出したければ、あらかじめ集計結果を別のドキュメントに書いておく設計になります。

このあたりは、書き込み時に集計を更新する設計であらかじめ回避します。
裏を返せば、設計の段階で読み出しの形を決め切る必要があるということですね。

作りながら仕様が変わっていく個人開発だと、ここが地味に効いてきます。
「あとで並べ替えを足そう」が、そのままデータ構造の作り直しに化けることがあるからです。

個人開発でどちらの設計が合うかの見極め方

判断の材料はシンプルです。
作ろうとしているものに、表で表せる関係がどれだけあるかを見てください。

顧客とプロジェクトと請求書、といった関係が絡むならリレーショナル。
投稿とコメントのように階層がはっきりしていて、読み出しの形が最初から決まっているならNoSQLが向きます。

もう1つの目安は、あとから集計したくなりそうかどうかです。
SaaSを運営していると、必ず「先月の継続率は？」といった問いが出てきます。

迷うくらいならSupabaseを選んでおくほうが、後戻りは少ないと思っています。

リレーショナルで作っておけば、あとから非正規化して速度を稼ぐ道は残ります。
逆方向はかなり大変なので、選択肢を残せるほうから始めるのが安全ですね。

SupabaseとFirebaseの料金と無料枠の違い

次はお金の話です。
ここが個人開発でいちばん大事なところだと思います。

Supabaseの無料枠は1週間の非アクティブで止まる

Supabaseの無料プランは、個人開発なら十分な内容です。
月間5万ユーザーの認証、データベース500MB、ファイルストレージ1GB、転送量5GBまで使えます。

問題は制限のかかり方のほうですね。
1週間アクセスがないと、プロジェクトが一時停止されます。

公開直後でユーザーがまだいない時期ほど、この条件に引っかかりやすいんです。
停止しても管理画面から復帰できますが、その間はサイトが動きません。

出典：Supabase公式サイト（Pricing）

回避策は単純で、有料のProプラン（月額25ドルから）に上げるか、定期的にアクセスを発生させるかのどちらかです。
Proに上げると停止はなくなり、認証は月間10万ユーザーまで、転送量は250GBまで増えます。

もう1つ、無料プランで同時に持てるアクティブなプロジェクトは2つまでという制限もあります。
検証用と本番を分けたい場合は、この枠がすぐ埋まる点も覚えておいてください。

FirebaseのSparkプランは1日あたりの回数で止まる

Firebaseの無料プランは「Spark」という名前です。
非アクティブでの停止はなく、そのかわり1日あたりの操作回数に上限があります。

Firestoreの場合、1日に読み取り5万回・書き込み2万回・削除2万回まで。
認証は月間5万ユーザーまで無料で、保存できるデータは1GiBまでです。

この上限に達すると、その日はエラーが返るようになります。
課金は発生しないかわりに、アプリが動かなくなるという止まり方ですね。

個人開発だと、開発しているだけで無料枠の半分を使っていた、という話も珍しくありません。
ここは最初から意識しておいたほうがいいところです。

対策としては、本番と開発でFirebaseのプロジェクトを分けておくのが基本になります。
手元の試行錯誤が本番の枠を食わなくなるだけで、精神的にかなりラクになりますよ。

有料に移ったあとの月額と請求が跳ねる条件

有料プランに上がると、性格の違いがはっきりします。
Supabaseは月額25ドルからの固定費に、超過分の従量課金が乗る形です。

対するFirebaseの「Blaze」プランは、無料枠を超えた分だけ払う完全な従量課金です。
Firestoreは読み取り・書き込み・削除それぞれに単価があり、使った回数のぶんだけ積み上がっていきます。
単価はリージョンによって変わるので、Google Cloudの料金ページで自分が使う場所の数字を必ず確認してください。

単価だけ見ると安いのですが、回数課金は事故ったときの上限がありません。
無限ループを1つ書いてしまうと、寝ている間に請求が伸びていきます。

設定さえ入れておけば、Firebaseの従量課金も普通に扱えます。
怖いのは料金体系そのものではなく、上限を決めないまま公開してしまうことのほうですね。

APIやインフラの費用をどう抑えるかはAI SaaSのAPIコストの抑え方｜個人開発の赤字を防ぐ設計方法を解説でも扱っています。

SupabaseとFirebaseで認証・リアルタイム・ストレージはどう違うか

データベース以外の機能も見ておきましょう。
ここは差が小さい部分と、はっきり差が出る部分に分かれます。

認証はどちらも無料で5万人まで使える

認証まわりは、正直どちらを選んでも困りません。
メールとパスワード、Google・GitHubなどのソーシャルログイン、マジックリンクまでひととおり揃っています。

無料枠も、月間5万ユーザーで並んでいます。
個人開発でこの数字に届くころには、もう有料化を検討している段階でしょう。

細かい違いを挙げるなら、Supabaseの認証はユーザーが自分のPostgreSQLの中に入るところですね。
ほかのテーブルと結合できるので、集計や絞り込みがSQLで完結します。

Firebase側は、電話番号でのSMS認証やGoogleアカウントとの連携がとにかく手厚いです。
スマホアプリで「電話番号だけで登録」を実現したいなら、こちらに軍配が上がります。

Supabase側の使い方はSupabaseの使い方｜個人開発の始め方と料金・費用の目安にまとめてあります。

実装の手順そのものは、個人開発SaaSで認証を実装する方法｜3つの選択肢と選び方でClerkも含めて比較しました。

リアルタイム機能はFirebaseのほうが歴史が長い

データの変更を即座に画面へ反映する仕組みは、どちらにもあります。
ただ、Firebaseはこれを出発点にしたサービスなので、蓄積が違います。

オフラインの状態で操作した内容を、接続が戻ったときに自動で同期する。
こうした細かい挙動まで面倒を見てくれるのは、モバイルアプリを作るときに大きな差になります。

Supabaseにもリアルタイム機能はあって、テーブルの変更をそのまま購読できるんですよね。
Webアプリで通知バッジを更新する程度なら、これで十分足ります。

逆に、更新が数分に1回といった頻度なら、リアルタイムにこだわらない手もあります。
画面を開いたときに取り直すだけで足りる場面は、思っているより多いです。

ストレージとサーバーレス関数の違い

ファイルストレージは、どちらも似た使い勝手です。
画像や書類をアップロードして、公開・非公開を切り替えられます。

違いが出るのは権限の書き方ですね。
Supabaseはデータベースと同じRLSのルールで制御し、Firebaseは専用のセキュリティルールを別途書きます。

サーバーレス関数は、SupabaseがEdge Functions、FirebaseがCloud Functionsという名前です。
Cloud Functionsを本格的に使う場合は、課金アカウントを有効にしたBlazeプランへの切り替えが必要になる場面があります。

個人開発の範囲だと、この3つで決定的な差がつくことはあまりありません。
選択を分けるのは、やはりデータベースと料金体系のほうですね。

Supabaseを選ぶ人とFirebaseを選ぶ人の分かれ目

ここまでの違いを、選択の形にまとめます。
結論はシンプルで、何を作るかでほぼ決まります。

Supabaseが向いているのはWebのSaaSを作る人

Next.jsでWebアプリを作り、有料プランで課金する。
この形ならSupabaseがそのままハマります。

顧客・契約・利用履歴といった関係のあるデータを扱ううえ、あとから「解約率を出したい」といった集計が必ず出てくるからです。
SQLが書ければ、その場で答えを取り出せます。

もう1つの理由は、費用の見通しが立つことですね。
月額25ドルという固定費が基準になるので、赤字になる条件を事前に計算できます。

技術構成全体の決め方は個人開発SaaSの技術選定｜Next.jsを軸にした構成の決め方で扱っています。

Firebaseが向いているのはモバイルアプリを出す人

iOSやAndroidのアプリを出すなら、Firebaseの土俵です。
公式SDKの完成度が高く、プッシュ通知やクラッシュ解析まで同じ画面で扱えます。

プッシュ通知は、Supabaseだけでは用意できません。
別のサービスを組み合わせることになるので、そのぶん手間が増えます。

アクセス解析も同様ですね。
Firebaseならアプリ内のイベントをそのまま計測でき、Googleの分析基盤にそのままつながります。

Webの管理画面も一緒に作りたい、という場合は少し悩ましくなります。
その場合はアプリ側をFirebase、管理画面のデータ集計だけ別で持つ、といった割り切りが現実的です。

迷ったときに見る3つの質問

ここまで読んでもまだ決まらない、という場合はこの3つを順番に見てください。

1つ目は「作るのはWebかアプリか」。
Webならばそれだけで、Supabaseがかなり有力になります。

2つ目は「データ同士の関係が絡むか」。
顧客と注文と請求のように3つ以上つながるなら、リレーショナルのほうが素直に書けます。

3つとも同じ方向を指していれば、その選択でほぼ問題ありません。
割れた場合は、Webかアプリかを優先してください。

SupabaseとFirebaseで個人開発者が後悔しやすいところ

最後に、選んだあとに効いてくる話をしておきます。

あとから乗り換えるコストは方向によって全然違う

ここ、あまり書かれていないのですが大事なところです。
SupabaseとFirebaseの乗り換えは、方向によって難易度がまるで違います。

PostgreSQLからFirestoreへ移すのは、まだ手が付けられます。
テーブルの行をドキュメントに変換していけば、形にはなるからです。

逆にFirestoreからPostgreSQLへ移すのは、データ移行ではなく設計のやり直しになります。
非正規化されたドキュメントを正規化されたテーブルに戻す作業は、そのまま作り直しに近い労力です。

迷ったときにSupabaseをすすめるのは、この非対称性があるからです。

もちろん、モバイルアプリが主役ならFirebaseで問題ありません。
言いたいのは「どちらでもいい」と感じたときこそ、戻れるほうを選んでおくと後悔しにくい、ということです。

従量課金の事故は上限とアラートで止められる

Firebaseの従量課金が怖い、という話はよく聞きます。
ただ、実際には手当てのしようがあります。

まずGoogle Cloudのコンソールで予算アラートを設定しましょう。
月の見込み額が閾値を超えたらメールが飛ぶので、朝には気づけます。

そのうえで、アプリ側にも上限を入れておきます。
一覧を取得するクエリには必ず件数の上限を付け、リアルタイム購読を使う画面を絞る。この2つで、暴発する経路はかなり減らせます。

逆に言えば、この設定を入れずに公開するのがいちばん危ないということですね。

「無料だから」で選ぶと公開直後につまずく

無料枠の数字だけで選ぶと、たいてい公開直後に困ります。
アクセスがまだ少ない時期にこそ、それぞれの制限が顔を出すからです。

Supabaseなら1週間の非アクティブでの一時停止。
友人に「見てみて」とURLを送ったのに落ちていた、という事故は本当に起きます。

Firebaseなら、日次の読み取り上限です。
個人ブログで紹介された日にアクセスが集中して、その日だけ動かなくなる、というのがありがちな形ですね。

SaaSがうまくいかない理由は個人開発SaaSが失敗する理由とは？よくある5つの落とし穴と対策にもまとめました。

SupabaseとFirebaseの違いに関するよくある質問

Q：個人開発でSupabaseとFirebaseのどちらが初心者向けですか？

A：SQLを一度も書いたことがないならFirebaseのほうが最初のハードルは低いです。ただ、SQLは学んだ知識が他の現場でもそのまま使えます。長い目で見るならSupabaseから入るほうが得だと思っています。

Q：SupabaseとFirebaseを両方使うのはありですか？

A：ありです。データはSupabaseで持ち、プッシュ通知だけFirebaseを使うといった組み合わせは現実的な選択になります。ただし管理画面が2つに増えるので、個人開発では必要になってから足すくらいでちょうどいいです。

Q：Supabaseの無料プランはいつまで使えますか？

A：期限はありません。ただし1週間アクセスがないとプロジェクトが一時停止し、同時に持てるアクティブなプロジェクトも2つまでという制限があります。公開するサービスで使うなら、有料プランへの切り替えを前提に考えておくと安心です。

Q：Firebaseで想定外の高額請求が来ることは本当にありますか？

A：無料のSparkプランのままなら課金は発生せず、上限に達した時点で止まります。請求が伸びるのはBlazeプランに切り替えたあとで、予算アラートとクエリの件数上限を入れていない場合です。この2つを先に設定しておけば、過度に恐れる必要はありません。

まとめ

SupabaseとFirebaseの違いは、突き詰めるとデータの持ち方とお金のかかり方の2点です。
WebのSaaSならSupabase、モバイルアプリならFirebase。この線引きで、個人開発の場面はほとんど説明がつきます。

そして選ぶときに見落としがちなのが、無料枠の止まり方でした。
Supabaseは非アクティブで一時停止し、Firebaseは1日の回数上限で止まります。

どちらを選んでも、公開前に安全装置を1つ入れておくかどうかで体験がまるで変わります。

SaaSづくり全体の流れは個人開発によるAI搭載SaaSの始め方｜アイデアから法人化まで総まとめにまとめてあります。

選び直しがきくうちに決めておけば、あとは作るだけです。
あなたが今つくろうとしているものは、Webとアプリのどちらから始めるものでしょうか。

個人開発を続けていくと、データの持ち方や分析の設計が伸びしろになる場面が出てきます。その領域を仕事として広げる道は、データサイエンティストに未経験からなるには？おすすめスクール7選にまとめてあります。