Supabase と Firebase の違い（2026年）：AI アプリのバックエンドはどちらか

アプリがデータ中心で、SQL を使いたく、いつか移行する可能性があるなら Supabase を選んでください。リアルタイムのモバイルアプリをリリースし、初日から課金設定を一切したくないなら Firebase を選んでください。あとはコストの計算と、それぞれがぶつかる 2 つの壁の話です。

どちらも「バックエンド・アズ・ア・サービス」、つまりデータベース、認証、ファイルストレージ、API が最初から用意されていて、自分でサーバーを立てる必要がありません。似ているのはそこまでです。両者はデータをまったく異なる形で保存し、正反対のモデルで課金し、片方からは立ち去れますが、もう片方からはほぼ立ち去れません。2026 年の AI アプリにとって、この 3 つの違いはどんな機能一覧よりも大きく結果を左右します。

まず結論を短くまとめ、そのあとで裏づけとなる計算を示します。

何を作るかで決まる結論

アプリの中身が主に互いに関連するテーブル（ユーザー、注文、投稿、コメント）で、SQL を書けるか少なくとも読めるなら、Supabase の上に作ってください。本物の PostgreSQL データベースが手に入るので、JOIN もトランザクションも使え、不正なデータを入口で止めるスキーマも手に入ります。さらにオープンソースなので、ホスティングプランでは足りなくなった日にデータベースをまるごと持ち出し、好きな場所で動かせます。この出口の価値は、必要になるまで多くの創業者が気づかないほど大きいものです。

一方、アプリの核となる機能が端末をまたいだリアルタイムの状態同期（チャットアプリ、共同編集ツール、オフラインでも即座に感じられる必要のあるもの）なら、Firebase の上に作ってください。Firestore のリアルタイム同期とオフライン永続化はいまなお業界標準であり、クレジットカードを入力しないままリリースできます。その代わり、Google の条件で Google から借りることになり、請求は操作ごとに計測されます。チームが驚かされるのは、まさにここです。

以下はすべて、この 2 つの判断が実際の価格、実際の AI 機能、そして本番運用に入ってから結果を分ける落とし穴に対してどう持ちこたえるか、という話です。

Supabase と Firebase の違いを本当に決める唯一の軸

機能一覧をはがすと、両者を分ける問いはひとつだけです。持ち出せるデータベースを所有しているのか、それとも持ち出せないサービスを借りているのか。

Supabase は PostgreSQL の上にダッシュボードを載せたものです。PostgreSQL は地球上でもっとも広く使われているオープンソースのリレーショナルデータベースであり、Supabase はそれをフォークもせず隠しもしません。生の接続文字列が手に入ります。自分のサーバーへ、AWS へ、別のホストへ移りたくなったら、標準の pg_dump を実行すればそれで終わりです。あなたのデータに独自仕様の部分はありません。

Firebase は Firestore、すなわち Google の中にしか存在しない NoSQL ドキュメントデータベースです。NoSQL とは固定スキーマがないという意味で、JSON のようなドキュメントを保存し、データベースはそれらの間に関係を強制しません。テーブル設計で立ち止まらずに済むため、初期のプロトタイピングは非常に速く進みます。同時に、SQL はなく、本当の JOIN もなく、あとから別のシステムへデータをきれいに書き出す手段もない、ということでもあります。データモデルの選択とベンダーの選択は同じひとつの決定です。Firestore は持ち出せません。

多くの AI アプリでは答えは Supabase に傾きます。AI 機能は構造化されクエリ可能なデータ、つまりユーザーテーブル、ドキュメントテーブル、絞り込みや結合ができる埋め込み（エンベディング）列に頼るからです。NoSQL でも実現はできますが、SQL なら無料で手に入るものをアプリケーションコード側で作り直すことになります。例外は「端末をまたいだ即時同期」そのものが製品である場合で、これは Firestore が誰よりも得意とする唯一の領域です。

:::callout{variant="note" title=""リレーショナル" が実務にもたらすもの"}
あるユーザーがアカウントを削除し、その人が作成したコメント、いいね、ファイルをすべて一緒に消す必要があるとします。PostgreSQL なら一度定義するだけのルール（カスケード削除付きの外部キー）ひとつで済み、データベースが永久にそれを守ります。Firestore では関連ドキュメントを 1 件ずつ探して削除するコードを自分で書くことになり、経路をひとつ見落とせば孤立データが積み上がります。リレーショナルデータベースは「まとまって属するデータは一貫したまま保たれる」という仕事を、あなたではなくデータベースの仕事にします。
:::

Supabase の料金と Firebase の料金：誰もが読み違える部分

見出しになるのは月額ではありません。課金モデルです。Supabase は定額に加えて予測可能な超過料金を取り、Firebase は操作ごとに課金するため、請求額はトラフィックと一緒に動きます。ときには一晩で動きます。

Supabase：計画を立てられる固定額

Supabase Free は $0 で、実用に耐えるアプリを支えます。月間アクティブユーザー 50,000、500 MB のデータベース、5 GB の下り転送、1 GB のファイルストレージです。全員が引っかかる落とし穴は、無料プロジェクトが 1 週間の無操作で一時停止すること、そしてアクティブなプロジェクトが 2 件までに制限されることです。一時停止したプロジェクトはクリックして復帰させるまでデモが止まったままになります。個人プロジェクトなら問題ありませんが、クライアントが予告なく開く可能性のあるものでは問題になります。

Supabase Pro は月額 $25 で、最初のプロジェクトが含まれ、追加プロジェクトは月額 $10 からです。この $25 で月間アクティブユーザー 100,000（超過分は 1 ユーザーあたり $0.00325）、プロジェクトごとに 8 GB のディスク（超過分は $0.125/GB）、250 GB の下り転送（超過分は $0.09/GB）、100 GB のファイルストレージ（超過分は $0.0213/GB）が手に入ります。さらに月額 $10 分のコンピュートクレジットが含まれ、小さな常時稼働インスタンスを 1 つ動かすのに十分です。Team プランは月額 $599 に跳ね上がり、主に追加されるのはコンプライアンス（SOC2、ISO、SSO）です。それ未満の規模なら必要ありません。

開発者がこのモデルを好む理由は、ユーザー数を見れば請求額が分かるからです。$25 の Pro は本番アプリを十分に支えますし、超過料金は十分に低く、アクティブユーザー 10,000 人と数ギガバイトのデータでも $25 から $50 の範囲に収まります。

Firebase：無料でなくなるまでは無料、その後はメーター制

Firebase Spark は本当の意味で無料のプランで、その最大の長所は支払い方法をまったく必要としない点です。Firestore はストレージ 1 GiB、1 日あたり読み取り 50K 回、書き込み 20K 回、削除 20K 回、下り転送は月 10 GiB。Authentication は月間アクティブユーザー 50,000。Realtime Database はストレージ 1 GB、ダウンロード月 10 GB です。プロトタイプやトラフィックの少ないアプリなら、カードを登録しないまま Spark に無期限に留まり、何も支払わずに済みます。

さらに必要になった時点で、従量課金プランの Blaze に切り替えます（条件を満たせば Google が $300 のクレジットを提供します）。Blaze は Spark の無料枠をそのまま残し、それを超えた分をすべて計測します。Cloud Functions は月 2M 回の呼び出しまで無料でその後は 100 万回あたり $0.40、Cloud Storage は 5 GB を超えた保存分が $0.026/GB、1 日 1 GB を超えたダウンロードが $0.12/GB、Firestore の読み取り・書き込み・削除は 1 日の無料枠を超えると Google Cloud の価格で操作ごとに課金されます。Firebase はいまや SQL Connect を通じてマネージド PostgreSQL も提供しており、3 か月の無料トライアルのあと月額およそ $9.37 からです。結局は多くの人が SQL を求めている、という静かな認めどころです。

無料プランの真っ向勝負

どちらも月間アクティブユーザー 50,000 まで無料で、ほとんどのアイデアを検証するには十分すぎるほどです。違いは 2 つの落とし穴にあります。

Supabase の落とし穴は一時停止です。無料プロジェクトを 1 週間放置すると、起こすまで眠ります。デモでは煩わしいものの、実際のトラフィックが出るか Pro に移れば関係なくなります。

Firebase の落とし穴はアップグレードの崖です。Spark は本当に無料でカードも不要ですが、そこから外に出た瞬間にメーター課金になり、メーター課金は設計上そもそも予測できません。「定額で少しだけ多めに」という $25 の段はありません。無料から従量課金へ一段で飛びます。

無料プランの正直な読み方はこうです。おそらく一度も課金しないであろう、まったく縛りのないプロトタイプでは Firebase が勝ちます。カードも不要、一時停止もありません。プロジェクトが本気になった瞬間には Supabase が勝ちます。定額 $25 は「計測してから考えましょう」に勝るからです。

それぞれの上で AI アプリを作る

2026 年が 2022 年と本当に違うのはここであり、多くの開発者にとって Supabase が抜け出すのもここです。AI アプリはたいてい、埋め込み（テキストの数値的な指紋）を保存し、クエリにもっとも近い一致を探す必要があります。これがベクトル検索であり、検索・意味検索・RAG（検索拡張生成。LLM に自分のドキュメントを与える手法）の裏側にあるエンジンです。

Supabase はこれを pgvector でネイティブに提供します。PostgreSQL の拡張機能で、通常のデータのすぐ隣にベクトルを保存しインデックスします。ひとつのデータベースなので、ユーザー ID で絞り込みながら同時にベクトル類似度で並べ替える単一のクエリを実行できます。2 つ目のシステムも同期も不要です。Supabase の AI ツールキットは OpenAI と Hugging Face の埋め込みにも直接つながります。

Firebase は findNearest クエリによる Firestore のベクトル検索で応じます。埋め込みをドキュメントに保存し、Firestore を出ないまま最近傍を取得できます。これは動作しますし、すでに Firestore に深く入り込んでいるなら 2 つ目のデータベースを持たずに済みます。ただし、そのために設計されたわけではないドキュメントストアの上でベクトル演算をすることになり、pgvector のクエリをあれほどきれいにしている SQL の絞り込みを失います。AI を中心に据えたアプリにとっては、pgvector のほうが自然な住まいです。

1. 1

   Supabase に埋め込みを保存する

   create extension vector; で拡張機能を有効化し、テーブルに embedding vector(1536) のような列を追加してから、行の通常データと並べて埋め込み配列を挿入します。ひとつのテーブルがコンテンツとそのベクトルの両方を持ちます。

2. 2

   もっとも近い一致を検索する

   ベクトル距離演算子（embedding <=> query_embedding）で並べ替えた通常の select を limit 付きで実行します。同じクエリに普通の where user_id = ... を足せるので、類似検索とアクセス制御が 1 往復で済みます。

3. 3

   速度を保つためにインデックスを張る

   ベクトル列に HNSW インデックスを追加します。通常のインデックスが通常の列を速くするのと同じように、テーブルが大きくなっても最近傍探索を速いまま保ちます。

認証、リアルタイム、その他

認証はどちらも十分にカバーしています。Firebase Auth のほうが成熟しており、対応プロバイダーが多く、モバイル SDK ももっとも滑らかです。「ユーザーがログインできる」ことが iOS と Android で当たり前に動く必要があるなら、非常に優秀です。Supabase Auth は自分の Postgres データベースの上に構築され、RLS（行レベルセキュリティ。各ユーザーが自分の行しか読み書きできず、しかもそれをデータベース自身が強制する仕組み）と組み合わさります。RLS は Supabase で学ぶべきもっとも重要な概念です。API 呼び出しのたびに権限チェックを書かなくても、マルチユーザーのアプリを安全にしてくれるのが RLS だからです。

リアルタイムは Firebase の本拠地です。Firestore と Realtime Database は端末をまたいで状態を同期し、オフラインをうまく扱います。書き込みをキューに入れ、接続が戻ったときに再生します。Supabase にも Postgres の変更フィードの上に作られた Realtime があり、ライブダッシュボードやプレゼンス表示には十分ですが、Firebase のモバイルアプリが頼りにしているオフラインファーストの体験ではありません。製品が共同編集型、あるいはオフライン中心のモバイルアプリなら、この点を大きく Firebase 寄りに評価してください。

あなたが誰かで決まる判断ルール

Supabase と Firebase はどちらが優れていますか？

どちらも万能ではありません。SQL、AI 機能、そして後から移行する自由を求めるデータ中心のアプリには Supabase が優れています。リアルタイムかつオフラインファーストのモバイルアプリ、そしてクレジットカードを必要としない縛りのないプロトタイプには Firebase が優れています。核となる機能が構造化データなのかライブ同期なのかで、道具を合わせてください。

なぜ Google は Firebase を終了するのですか？

Google は Firebase を終了していません。この誤解は、特定の旧製品が非推奨になったこと（たとえば Firebase Dynamic Links は 2025 年 8 月に停止しました）と、Google が一部の機能を Google Cloud に統合していることから生じています。中核のプラットフォームは活発に開発が続いており、Firebase Studio、AI Logic、SQL Connect によるマネージド PostgreSQL といった新しい追加もあります。

Supabase は Firebase の一部ですか？

いいえ。Supabase は独立した別会社で、オープンソースの Firebase 代替としてよく紹介されます。同じ種類のオールインワンのバックエンド（データベース、認証、ストレージ、API）を提供しますが、Google のプロプライエタリな Firestore ではなく PostgreSQL の上に構築されています。

Supabase のデメリットは何ですか？

主に 2 つあります。無料プロジェクトは 1 週間の無操作で一時停止し、デモが中断されます。またリアルタイムとオフライン同期の体験は堅実ではあるものの Firebase ほど成熟しておらず、オフライン中心のモバイルアプリでは依然として Firebase に分があります。さらに、マルチユーザーのアプリを安全に保つには RLS を学ぶ必要があります。

Supabase と Firebase はどちらが安いですか？

トラフィックのない純粋なプロトタイプなら、カード不要で無料の Firebase Spark のほうが安くつきます。実際の利用が始まれば、Supabase のほうがたいてい安く、はるかに予測しやすくなります。定額で月額 $25 の Pro プランに対し、Firebase はトラフィックとともに上がる操作ごとのメーター課金だからです。アプリの読み書きが増えるほど、Supabase の定額モデルが有利になる傾向があります。

バックエンドを選び、そのうえでスタックの残りをそれに合わせてください。こうした作り手向けの分解記事を、実際のコストと壁も含めて毎週 1 本お送りしています。受信トレイで受け取る。