---
title: "SupabaseとFirebaseの違い｜DB・認証・料金の比較とどっちを選ぶか【2026年10月】"
url: "https://www.issoh.co.jp/column/details/3002/"
published: 2024-07-09
updated: 2026-10-27
categories: ["プラットフォーム"]
publisher: "株式会社一創"
---

# SupabaseとFirebaseの違い｜DB・認証・料金の比較とどっちを選ぶか【2026年10月】

SupabaseとFirebaseは、どちらも認証・データベース・ストレージ・サーバー関数をまとめて提供するBaaS（Backend as a Service）です。違いの根は、Supabaseが1プロジェクトに1台のPostgreSQLを割り当てるのに対し、FirebaseはドキュメントDBのCloud Firestoreを中心に組み立てられている点にあります。この差が、クエリの書き方、アクセス制御の仕組み、料金の数え方まで連鎖します。

本記事では、データベース・アクセス制御・認証・リアルタイム・料金の5軸で両者を並べ、同じ利用規模での月額試算と、どちらを選ぶべきかの条件を示します。料金・上限・版番号は2026年10月27日時点の公式ドキュメントの値です。

## まとめ：SupabaseとFirebaseの違いと選び方

結論から示します。データ同士の関係（注文と顧客、記事とタグなど）をSQLで結合・集計したいWebアプリならSupabase、オフラインで動くモバイルアプリや、プッシュ通知・Crashlytics・Analyticsを同じコンソールで扱いたいならFirebaseが向いています。

- **データベース**：SupabaseはPostgreSQLそのもの。FirebaseはFirestore（ドキュメント型）が中心ですが、2024年5月にCloud SQL for PostgreSQLを使うFirebase Data Connectが発表され（2026年4月にFirebase SQL Connectへ改称）、「Firebase＝NoSQLだけ」ではなくなりました。
- **アクセス制御**：SupabaseはPostgreSQLのRow Level Security（RLS）、FirebaseはSecurity Rules。Supabaseは既存プロジェクトだと新しいテーブルにクライアント用ロールの全権限が付いた状態で始まるため、RLSの有効化漏れがそのまま情報漏えいになります。
- **料金**：Firebaseは読み書きの回数で課金、SupabaseはPro月額25ドル＋計算資源と超過分。利用が小さいうちはFirebaseが安く、Supabaseは月額が読みやすい代わりに認証ユーザーが10万MAUを超えると1MAUあたり0.00325ドルが積み上がります。
- **無料枠の制約**：SupabaseのFreeは1週間アクセスが無いとプロジェクトが一時停止し、アクティブなプロジェクトは2つまで。FirebaseのSparkはCloud FunctionsとCloud Storageを使えず（Storageは2026年2月3日からBlaze必須）、ファイルを扱うアプリは実質Blazeになります。
- **ロックイン**：SupabaseはApache-2.0のOSSでセルフホストでき、データは標準のpg\_dumpで持ち出せます。Firebaseはセルフホストできず、手元で動くのはLocal Emulator Suiteだけです。

## SupabaseとFirebaseの違いを一覧表で比較

主要な機能を同じ軸で並べると、次のようになります。数値は各社の料金ページと制限ページの値です。

| 比較軸     | Supabase                            | Firebase                              |
| ------- | ----------------------------------- | ------------------------------------- |
| 中心のDB   | PostgreSQL（1プロジェクト1台）               | Cloud Firestore（ドキュメント型）              |
| SQLの選択肢 | 標準で利用可                              | SQL Connect（Cloud SQL for PostgreSQL） |
| アクセス制御  | RLS（SQLのポリシー）                       | Security Rules（独自DSL）                 |
| 認証の無料枠  | Free 5万MAU／Pro 10万MAU               | Identity Platform適用時 5万MAU            |
| リアルタイム  | Postgres Changes・Broadcast・Presence | onSnapshotによるリスナー                     |
| オフライン   | SDKに永続キャッシュ無し                       | Android・Appleは既定で有効                   |
| サーバー関数  | Edge Functions（Deno）                | Cloud Functions（Node.js・Python）       |
| 課金の単位   | プラン月額＋Compute＋超過分                   | 読み書き削除の回数＋保存量                         |
| 東京リージョン | あり（ap-northeast-1）                  | あり（asia-northeast1）                   |
| セルフホスト  | 可（Docker Compose）                   | 不可（エミュレーターのみ）                         |

表の中で選定を左右するのは「中心のDB」「アクセス制御」「課金の単位」の3行です。オフライン対応やセルフホストの可否も、必須要件によっては決め手になります。特に端末内への永続キャッシュと自社環境での本番運用には、両者で明確な違いがあります。

## データベースの違い：PostgreSQLとCloud Firestore

Supabaseのデータはテーブルの行として、Firestoreのデータはコレクションの中のドキュメント（JSONに近い入れ子構造）として保存されます。同じ「注文一覧に顧客名を添えて表示する」処理でも、書き方が変わります。

### 結合と集計の書き方

Supabaseは、外部キーでつながったテーブルを1回の問い合わせで取得できます。supabase-js（2026年10月時点の最新は2.118.0）では、selectの中に関連テーブル名を書くだけで結合されます。

```
// Supabase：orders.customer_id → customers.id の外部キーを辿って1回で取得
const { data, error } = await supabase
  .from('orders')
  .select('id, total, customers(name)')
  .eq('status', 'paid')
  .order('created_at', { ascending: false });
```

Firestore（Standard edition）の通常のクエリは1つのコレクションしか対象にできないため、顧客名を表示するには、注文を取得したあとに顧客ドキュメントを別に読むか、注文ドキュメントに顧客名をあらかじめ複製しておきます。

```
// Firestore：注文を取得し、顧客は別の読み取りで補う（firebase 13系のモジュラーAPI）
const q = query(collection(db, 'orders'),
  where('status', '==', 'paid'), orderBy('createdAt', 'desc'));
const snap = await getDocs(q);
for (const d of snap.docs) {
  const customer = await getDoc(doc(db, 'customers', d.data().customerId));
  // 注文1件ごとに読み取りが1回増え、その分だけ課金対象になる
}
```

Firestoreでは、この補完で読む顧客ドキュメントも読み取り料金の対象です。クエリによってはインデックスエントリの読み取りも課金されるため、取得ドキュメント数だけで料金が決まるわけではありません。注文にも常に最新の顧客名を表示する要件なら、顧客名の変更時に複製先を更新する処理が必要です。注文時点の顧客名を履歴として保存する設計なら、過去の注文を書き換える必要はありません。ORやinを使う条件は、展開後の組み合わせが30までという上限もあります。集計はcount・sum・averageの集計クエリが使えますが、複数コレクションをまたぐGROUP BYのような処理はStandard editionの通常クエリでは書けません。

### Firestore EnterpriseとSQL Connectで変わった点

「Firebaseでは結合できない」という説明は、2026年時点では条件付きで正しい、と言い直す必要があります。Firebaseは2026年4月22日のCloud Next 2026の発表で、[Firestore Enterprise editionのパイプラインクエリを一般提供とし、新しいクエリエンジンにサブクエリによるJOINを加え、全文検索・地理空間クエリをプレビュー提供する](https://firebase.blog/posts/2026/04/Cloud-Next-2026-announcements)と告知しました。同じ発表で、Cloud SQL for PostgreSQLにつなぐFirebase Data ConnectをFirebase SQL Connectへ発展させ、リアルタイム同期・オフラインキャッシュ・SQLでの記述に対応させています。

ただし、どちらも既存のFirestore（Standard edition）にそのまま効く機能ではありません。Enterprise editionは別のエディションとして作成するデータベースで、料金体系もStandardと異なります。SQL Connect自体の課金はBlazeで月25万操作まで無料・以降100万操作あたり0.90ドルですが、土台のCloud SQLは別料金で、公式の案内では最低月9.37ドルからです（初回の対象インスタンスは3か月の無料試用あり）。Firebaseの中でSQLが要るならSQL Connect、という選択肢は増えましたが、SQL ConnectもCloud SQL上のPostgreSQLを利用するため、直接接続や拡張機能の要件は、両サービスで必要な権限と対応範囲を確認して比較してください。SQL Connectの構成と料金は[Firebase Data Connectとは｜SQL Connect改称とCloud SQL＋GraphQLの実装判断【2026年8月時点】](/tech/details/16689/)で、Firestoreの設計は[Cloud Firestoreとは？NoSQLドキュメントDBの仕組み・料金・実装判断【2026年版】](/tech/details/15563/)で扱っています。

## アクセス制御の違い：RLSとSecurity Rules

どちらも、ブラウザやアプリから直接データベースを読み書きさせる設計です。そのため「誰がどの行（ドキュメント）を読めるか」をデータベース側で必ず制限します。Supabaseはこれを[PostgreSQLのRow Level Security](https://supabase.com/docs/guides/database/postgres/row-level-security)で、FirebaseはSecurity Rulesで書きます。

### 本人のタスクに対するRLSとSecurity Rulesの記述比較

「ログインしている本人のタスクだけ読める」という制限は、それぞれ次のように書きます。Firestoreで一覧を取得するときは、クエリにもuserIdがログインユーザーのUIDと等しい条件を指定します。Security Rulesは結果を絞り込むフィルターではなく、許可できない結果を返す可能性のあるクエリ全体を拒否します。

```
-- Supabase（RLS）：SQLでポリシーを定義する
alter table public.todos enable row level security;

create policy "own rows" on public.todos
  for select to authenticated
  using ( (select auth.uid()) = user_id );
```

```
// Firebase（Firestore Security Rules）
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /todos/{todoId} {
      allow read: if request.auth != null
                  && request.auth.uid == resource.data.userId;
    }
  }
}
```

RLSはSQLなので、サブクエリで所属組織のテーブルを引くなど複雑な条件も1つのポリシーに書けます。RLSは直接接続にも適用されますが、スーパーユーザー、BYPASSRLS属性を持つロール、通常のテーブル所有者は対象外です。管理ツールや別アプリでも、接続ロールの権限を確認する必要があります。Security Rulesはクライアントからのアクセスにだけ掛かり、Admin SDKを使うサーバーからのアクセスには適用されません。

### Supabaseで起きやすい有効化漏れ

初期状態の安全側の倒し方が違う点は、選定前に知っておくべきです。Firestoreはデータベース作成時に本番モードを選ぶと、モバイルとWebのクライアントからの読み書きがすべて拒否された状態で始まります。Supabaseの公式ドキュメントは、既存プロジェクトでは`public`スキーマに作った新しいテーブルに、`anon`・`authenticated`・`service_role`の3ロールへ全権限が付いた状態で始まると説明し、RLSの無い公開スキーマのテーブルは権限を持つどのロールからも読み書きできると警告しています。

この挙動を、PostgreSQL 18.6にSupabaseと同じ形の`auth.uid()`関数とロールを用意して再現しました（Supabase本体ではなく、同じ仕組みを素のPostgreSQLで組んだ検証です）。

| 状態                  | 結果                          |
| ------------------- | --------------------------- |
| RLS無効・全権限付与のまま匿名で読む | 2件すべて読める                    |
| RLSを有効にしポリシー無し      | 0件                          |
| 本人のみのselectポリシーを追加  | 自分の1件だけ                     |
| insertポリシー無しで書き込み   | row-level security policy違反 |
| 匿名ロールの権限を取り消す       | permission denied           |

1行目が事故のパターンです。SQLでテーブルを作り、RLSの有効化を忘れると、公開されているAPIキーだけで誰でも全件を読めます。ポリシーを足しても付与済みの権限は消えないため、公式手順は`revoke all ... from anon, authenticated`で権限を外してから必要な分だけ付け直し、`supabase test db`で許可と拒否をテストする流れを推奨しています。RLSの設計は[Supabase RLSの設定手順とAuth連携ポリシー設計｜有効化漏れの検知まで](/tech/details/17056/)で詳しく扱っています。

## 認証の違い：Supabase AuthとFirebase Authentication

メール・パスワード、マジックリンク、Google・GitHubなどのソーシャルログイン、電話番号、匿名ログイン、多要素認証は両者とも揃っています。差が出るのは料金の数え方と、ユーザー情報の置き場所です。

| 項目       | Supabase Auth         | Firebase Authentication |
| -------- | --------------------- | ----------------------- |
| 無料のMAU   | Free 5万／Pro 10万       | Identity Platform適用時 5万 |
| 超過単価     | 0.00325ドル／MAU         | 0.0055ドル（5万〜10万）        |
| 10万MAU超  | 0.00325ドル／MAU         | 0.0046ドル（〜100万）         |
| SAML SSO | Pro 50MAUまで込み         | 50MAUまで無料               |
| ユーザー情報   | 同じPostgreSQLのauthスキーマ | Firebase側の別基盤           |

Supabaseの単価は[Supabaseの課金ドキュメント](https://supabase.com/docs/guides/platform/billing-on-supabase)、Firebase側は[Identity Platformの料金表](https://cloud.google.com/identity-platform/pricing)の値です。Firebaseの料金ページでは、Identity Platformへアップグレードしない基本の認証（電話番号認証のSMSを除く）はSparkでもBlazeでも無料の扱いで、MAU課金はアップグレードしたときにだけ発生します。アップグレードすると多要素認証やSAML・OIDC連携が使える代わりに、SparkのままではTier 1の日次アクティブユーザーが1日3,000人までに制限されます。

Supabase Authの強みは、ユーザーが同じPostgreSQLの`auth.users`に入る点です。RLSのポリシーから`auth.uid()`でそのまま参照でき、ユーザーと業務データを外部キーで結べます。逆に、ユーザー数が数十万規模になる消費者向けアプリでは、MAU課金がプラン料金を上回る点に注意してください（次の章の試算Cを参照）。各サービスの詳細は[Supabase Authとは：非対称JWT鍵とRLS連携で組む認証実装の設計判断](/tech/details/17245/)と[Firebase Authenticationとは？料金・認証方式・導入手順とMFA・IDトークン検証【2026年10月】](/tech/details/5921/)にまとめています。

## 料金の違い：課金単位と同じ規模での月額試算

Firebase（Blazeプラン）は使った分だけ払う従量課金で、Firestoreは読み取り・書き込み・削除の回数と保存量に料金がかかります。Supabaseは組織単位の月額プラン（Free 0ドル、Pro 25ドル〜、Team 599ドル〜、Enterprise個別見積もり）に、プロジェクトごとのCompute（サーバーの大きさ）と、プランの枠を超えた分が加わります。

### Firestore Standardの無料枠と単価

[Firestoreの料金ページ](https://cloud.google.com/firestore/pricing)では、無料枠は1プロジェクト1データベースに限り、保存1GiB・読み取り1日5万件・書き込み1日2万件・削除1日2万件・送信10GiB/月です。超過単価は、表示の既定であるアイオワ（us-central1）で読み取り10万件あたり0.03ドル、書き込み10万件あたり0.09ドル、削除10万件あたり0.01ドル、保存は1GiBあたり月約0.15ドルです。単価はロケーションで変わり、Firebaseの公式の計算例が使うマルチリージョンのnam5では読み取り0.06ドル・書き込み0.18ドル（いずれも10万件あたり）とアイオワの2倍です。東京（asia-northeast1）も別単価なので、本番の見積もりでは料金ページのロケーション選択を東京に切り替えて確認してください。Firebase全体の料金は[Firebaseの料金｜無料枠とBlaze超過単価の実額【2026年8月時点】](/tech/details/16672/)で整理しています。

### Supabaseのプランと枠

Proは月25ドルに、毎月10ドル分のCompute Creditsが付きます。これで最小のMicro（月約10ドル、メモリ1GB）1台分が相殺されるため、1プロジェクトなら25ドルから運用できます。Proの枠はMAU10万・DB容量8GB（超過は1GBあたり0.125ドル）・送信250GB（超過は1GBあたり0.09ドル）・ファイル保存100GB・Edge Functions呼び出し200万回です。Computeの枠は無く、Small（約15ドル）、Medium（約60ドル）、Large（約110ドル）と上げた分だけ増えます。

### 3つの規模での月額試算

同じ利用規模を想定し、Firestoreはアイオワの単価で1か月30日、保存単価は月約0.15ドルとして概算しました。比較対象はDBと認証で、インデックス読み取りの追加課金、削除、バックアップ、ファイル保存、サーバー関数の料金は含めません。1ユーザーが1日にFirestoreのドキュメントを100件読み10件書く、送信量は双方とも枠内、Firebase Authは基本認証、SupabaseのComputeはAがMicro、BがMedium、CがLargeとします。Computeの大きさは負荷試験で決めるもので、ここでは仮置きです。

| 規模                       | Firestore＋Firebase Auth | Supabase Pro |
| ------------------------ | ----------------------- | ------------ |
| A：DAU1,000・MAU3,000・1GiB | 約0.45ドル                 | 25ドル         |
| B：DAU2万・MAU6万・10GiB      | 約23.8ドル                 | 約75.3ドル      |
| C：DAU10万・MAU30万・50GiB    | 約123.4ドル                | 約780.3ドル     |
| 参考：Cで1人1日1,000件読む        | 約933.4ドル                | 約780.3ドル     |

試算から読み取れるのは2点です。1つ目に、Firestoreの料金はユーザー1人あたりの読み取り回数にほぼ比例します。一覧画面を開くたびに数百件を読む設計や、リアルタイムリスナーで頻繁に更新を受ける設計では、最後の行のように順位が入れ替わります。2つ目に、Supabaseは規模Cの約780ドルのうち650ドルが10万MAUを超えた分の認証料金で、ユーザー数が多い消費者向けアプリではAuthがコストの主因になります。なお、FirebaseでもIdentity Platformへアップグレードすると、規模CのMAU課金は約1,195ドルとSupabaseより高くなります。

「Firebaseは高い、Supabaseは安い」という比較記事の定番は、読み取りが多い設計を前提にした話です。自分のアプリの1画面あたりの読み取り件数と、認証ユーザー数の見込みを先に数えてから比べてください。

## リアルタイム・オフライン・サーバー関数の違い

### リアルタイム同期とオフライン

Firestoreは`onSnapshot`でクエリ結果を購読でき、[AndroidとAppleのSDKではオフライン永続化が既定で有効](https://firebase.google.com/docs/firestore/manage-data/enable-offline)（Webは既定で無効）です。電波が切れても端末内のキャッシュに書き込み、つながった時点で同期されます。地下や山間部で使う現場アプリ、通信が不安定な国向けのアプリでは、この差が決め手になります。

Supabase Realtimeは、テーブルの変更を配信するPostgres Changes、クライアント同士でメッセージを送るBroadcast、オンライン状態を共有するPresenceの3方式です。同時接続数の上限はFree 200、Pro 500（利用上限を外すと1万）、Team 1万です。オフライン対応は、Supabaseの[パートナー連携として掲載されているPowerSync](https://supabase.com/partners/integrations/powersync)のように、PostgreSQLと端末内のSQLiteを同期する別サービスを組み合わせて作ります。Firestoreのように主要SDKの既定機能として付いてくるわけではありません。3方式の使い分けは[Supabase Realtimeの実装｜3方式の使い分けとRLS併用・同時接続の上限](/tech/details/17058/)を参照してください。

### Edge FunctionsとCloud Functions

サーバー側の処理は、SupabaseがDenoで動くEdge Functions、FirebaseがNode.jsまたはPythonで動くCloud Functionsです。[Edge Functionsの制限](https://supabase.com/docs/guides/functions/limits)は、メモリ256MB、ワーカーの存続時間の上限がFreeで150秒・有料プランで400秒、CPU時間は1リクエスト2秒までです。別に150秒のリクエストアイドルタイムアウトがあり、その間に応答を返さない場合は504エラーになります。外部APIを呼んで結果を返すような軽い処理向きで、画像変換や長いバッチには向きません。

Cloud Functions（第2世代）はHTTP関数で最大60分、スケジュール関数で1,800秒まで動かせます。ただしSparkプランでは使えず、Blazeが必要です。長時間の集計やPDF生成のような重い処理があるなら、Firebase側のほうが素直に書けます。詳細は[Supabase Edge Functionsとは：Deno実行環境とデプロイ・シークレット・課金単位](/tech/details/17061/)と[Cloud Functions for Firebaseとは｜トリガー設計と第2世代の実装判断【2026年8月時点】](/tech/details/16683/)で扱っています。

## セルフホストとロックインの違い

Supabaseは本体のリポジトリが[Apache-2.0ライセンスで公開](https://github.com/supabase/supabase)されており、Docker Composeで自社サーバーやAWSなどに立てられます。データは普通のPostgreSQLなので、pg\_dumpで取り出して別のPostgreSQLへそのまま移せます。マネージド版をやめても、データとSQLの資産は残ります。運営会社の体力を気にする声もありますが、Supabaseは2026年6月4日に評価額105億ドルで5億ドルのシリーズFを、同年10月2日に1億5,000万ドルの追加調達とTursoの買収を[発表](https://www.prnewswire.com/news-releases/supabase-announces-150m-in-new-funding-and-turso-acquisition-302896752.html)しています。ただし、セルフホストではバックアップ、バージョンアップ、Authのメール送信設定などを自分で引き受けることになります。構成と運用の実際は[Supabaseセルフホストの構成と運用：Envoy移行後のDocker Compose実測](/tech/details/17074/)にまとめています。

Firebaseはセルフホストできません。Local Emulator Suiteで開発中に手元で動かせますが、公式ドキュメントはエミュレーターをセルフホスト版として本番に使わないよう明記しており、本番はGoogle Cloud上だけです。Firestoreのデータはエクスポートできるものの、ドキュメント構造をテーブルへ組み直す作業と、Security Rulesを別の仕組みへ書き換える作業が残ります。データの国内保管が契約上の必須条件で、かつ特定のクラウドに依存したくない案件では、この差が選定理由になります。

## どっちを選ぶか：選ぶ条件と避けるべき場面

ここまでの比較を、選定の判断に落とします。

### Supabaseを選ぶ条件

- 注文・在庫・会員・権限など、テーブル同士の関係が多い業務アプリや管理画面を作る
- SQLで集計やレポートを出す必要があり、BIツールから直接つなぎたい
- pgvectorでベクトル検索をするなど、PostgreSQLの拡張を使いたい
- 将来セルフホストや別クラウドへ移る可能性を残したい

### Firebaseを選ぶ条件

- オフラインで書き込める必要があるモバイルアプリ
- FCMのプッシュ通知、Crashlytics、Analytics、Remote Configをまとめて使う
- データの関係が浅く、ユーザーごとの小さなドキュメントを読み書きする設計（チャット、メモ、設定など）
- 数十万MAU規模の消費者向けアプリで、基本認証で足りる

### 選ぶと失敗しやすい場面

Supabaseを避けたほうがよいのは、RLSを書けるメンバーがいないままクライアントから直接DBを触らせる体制です。前の章の再現どおり、有効化を1つ忘れるだけで全件が読めます。Free枠のまま本番に出すのも危険で、1週間アクセスが無いと一時停止し、自動バックアップもありません。

Firebaseを避けたほうがよいのは、一覧・検索・集計の画面が多い業務システムです。正規化しないために複製したデータの整合性維持と、読み取り回数に比例する料金の両方が、画面が増えるたびに重くなります。Firebase内でSQLが必要ならSQL ConnectやFirestore Enterpriseも候補ですが、そこまで要件がSQL寄りなら最初からSupabaseを選ぶほうが構成は単純です。

どちらでも作れる中規模のWebアプリで迷うなら、データモデルを先に書き出し、テーブル間の結合が設計の中心ならSupabaseを候補にし、Firebaseについても読み取り件数とMAUから月額を試算したうえで、運用体制と合わせて判断します。業務システムやWebアプリのバックエンド選定から開発まで外部に任せたい場合は、[業務用・Webアプリ開発](/service/apps/business/)の支援内容を参照してください。

## FirebaseからSupabaseへ移行するときの手順と注意点

移行は、認証・データ・ファイル・アクセス制御の4つに分けて進めます。Supabaseは[Firestoreデータの移行手順](https://supabase.com/docs/guides/platform/migrating-to-supabase/firestore-data)と、Firebase Authのユーザーを移す手順を公式に用意しています。

1. **認証**：公式ツールのfirestoreusers2jsonでFirebase Authのユーザーを書き出し、import\_usersでSupabaseのauth.usersへ取り込みます。Firebaseのパスワードは独自パラメータ付きのSCRYPTでハッシュされているため、コンソールの「Password hash parameters」を保存しておきます。公式ドキュメントは、初回ログイン時にFirebase側のパスワードで照合してSupabase側を更新する中継サーバーの構成も案内しています。
2. **データ**：Firestoreのコレクションを JSON に書き出し、テーブル設計に合わせて変換して取り込みます。入れ子のマップや配列をそのままjsonb列に入れるか、別テーブルへ正規化するかを、ここで決めます。
3. **ファイル**：Cloud StorageのファイルをSupabase Storageへコピーし、ファイルURLを参照している列を書き換えます。
4. **アクセス制御**：Security RulesをRLSポリシーへ書き直します。自動変換は無いため、ルールの数だけ手作業になります。

一番時間がかかるのは2と4です。Firestoreで複製していたデータを正規化し直すと、アプリ側のクエリもほぼ書き直しになります。全面移行の前に、新しい機能だけをSupabaseで作り、Firebase Authのトークンを[サードパーティ認証](https://supabase.com/docs/guides/auth/third-party/firebase-auth)としてSupabaseに受け入れさせて併用する段階を挟むと、切り替えのリスクを抑えられます。

## よくある質問

### FirebaseとFirestoreの違いは何ですか？

Firebaseは認証・データベース・ストレージ・通知などをまとめたGoogleの開発基盤の名前で、Cloud FirestoreはFirebaseに含まれるドキュメント型データベースの1つです。FirebaseにはほかにRealtime DatabaseとSQL Connect（PostgreSQL）があります。SupabaseとFirebaseを比べるときのデータベースの比較は、主にPostgreSQLとFirestoreの比較になります。

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

規模と設計によって逆転します。本記事の試算Aでは、DAU1,000、1人1日100件の読み取り・10件の書き込みなどの条件でFirestoreは月約0.45ドル、Supabase Proは月25ドルです。Supabaseには別途Freeプランもあります。1ユーザーあたりの読み取りが多い設計ではFirestoreの料金が読み取り回数に比例して増え、Supabaseが安くなります。逆に認証ユーザーが10万MAUを超えると、Supabaseは1MAUあたり0.00325ドルが加わります。

### Supabase AuthとFirebase Authenticationはどちらを選ぶべきですか？

データベースもSupabaseにするなら、ユーザーと業務データを同じPostgreSQLで扱えてRLSから直接参照できるSupabase Authが素直です。数十万規模の利用者がいて基本認証で足りるなら、MAU課金の無いFirebase Authenticationの方が費用を抑えられます。Identity Platformへアップグレードした場合、メールやソーシャル認証などのTier 1は5万MAUまで無料ですが、SAML・OIDCのTier 2は50MAUまで無料で、超過分は1MAUあたり0.015ドルです。SMSを使う認証には別途送信料金がかかります。

### Supabaseの無料プランは本番で使えますか？

おすすめしません。Freeプランは1週間アクセスが無いとプロジェクトが一時停止し、アクティブなプロジェクトは2つまで、DB容量は500MBで自動バックアップもありません。利用者のいるサービスなら、Proへ上げると一時停止が無くなり、7日分の日次バックアップが付きます。

### FirebaseとSupabaseは併用できますか？

できます。SupabaseはFirebase Authのトークンをサードパーティ認証として受け入れられるため、ログインはFirebaseのまま、データだけSupabaseのPostgreSQLに置く構成が組めます。その場合、全ユーザーにカスタムクレーム`role: 'authenticated'`を付ける必要があります。プッシュ通知をFCM、データ保存をSupabaseに分担する構成も可能です。

## 関連記事

- [Supabase Authとは：非対称JWT鍵とRLS連携で組む認証実装の設計判断](/tech/details/17245/)
- [Cloud Firestoreとは？NoSQLドキュメントDBの仕組み・料金・実装判断【2026年版】](/tech/details/15563/)
- [Firebase Data Connectとは｜SQL Connect改称とCloud SQL＋GraphQLの実装判断【2026年8月時点】](/tech/details/16689/)
- [Supabase RLSの設定手順とAuth連携ポリシー設計｜有効化漏れの検知まで](/tech/details/17056/)
- [Firebaseの料金｜無料枠とBlaze超過単価の実額【2026年8月時点】](/tech/details/16672/)

---

出典: [SupabaseとFirebaseの違い｜DB・認証・料金の比較とどっちを選ぶか【2026年10月】](<https://www.issoh.co.jp/column/details/3002/>)（株式会社一創）