先に、要点をまとめます。
- FirebaseからSupabaseへの移行は、データのコピーではありません。Firestoreのドキュメント構造をPostgreSQLのテーブル設計へ作り直す作業が本体で、工数の主軸はスキーマ再設計に置くのが現実的です。
- 「移行すれば安くなる」とは限りません。 SupabaseのProプランは支出上限が既定で有効という予測しやすさが利点で、絶対額が必ず下がるわけではありません。Firebase側も一部サービスで支出上限が使えるようになっています。
- 認証は「ユーザー一覧のコピー」では終わりません。Firebaseはscrypt、Supabaseはbcryptとパスワードのハッシュ方式が異なるため、初回ログイン時に旧パスワードを検証して移し替える仕組みを用意しないと、全ユーザーに再設定を強いることになります。
2026年9月23日時点の情報です。料金・仕様は変動するため、判断時は文中の公式出典で最新の値を確認してください。
FirebaseとSupabaseは何が違うのか？
最大の違いはデータベースの型です。Firestoreはドキュメント型（NoSQL）、SupabaseはPostgreSQL（リレーショナル）で、移行はデータの考え方を翻訳し直す作業になります。
どちらが優れているかという話ではなく、向く場面が違います。認証・データベース・ストレージ・サーバーレス関数という構成要素はよく似ており、機能一覧の比較だけでは判断できません。
| 観点 | Firebase（Firestore） | Supabase（PostgreSQL） |
|---|---|---|
| データの持ち方 | ドキュメント型。スキーマ強制がなく柔軟 | テーブル・外部キー・制約を持つリレーショナル |
| 結合・集計 | join がなく、集計はアプリ側または別途設計 | SQL の join・ビュー・集計関数が使える |
| 権限制御 | Security Rules（独自記法） | RLS（SQLのポリシー） |
| 持ち出し | エクスポート形式に依存 | pg_dump など PostgreSQL 標準の手段が使える |
この違いが移行の難所であり、同時に移行する理由でもあります。 「先月の売上を顧客セグメント別に出したい」といった集計要求が増えているなら、リレーショナルの利点が効きます。逆に単純な読み書きが中心なら、Firestoreのままで足りることが多くあります。
移行を検討する理由はどこにあるのか？
料金、データの扱いやすさ、集計、権限、開発体制のどこが課題かを分けてから判断します。移行を先に決めないでください。
既存システムを移行したいについて相談する老朽化した業務システム、限界がきたSaaS、連絡の取れない開発会社が作ったシステムを、業務を止めずに引き取って作り変える受託開発既存システムを移行したいを見る →現在のクエリや読み書きの方法を改善するだけで解消する課題もあります。理由ごとに、移行以外の選択肢を並べて比較してください。
| 感じている課題 | 先に確認すること | 移行以外の選択肢 |
|---|---|---|
| 請求額が読めない | どの操作が課金の主因か、使用量の内訳を見る | 読み取り回数の削減、不要な購読の停止 |
| 集計・レポートが作れない | 必要な集計の種類と頻度を列挙する | 集計結果を別途保存する、BIツールへ連携する |
| 権限設計が複雑化した | Security Rules で表現できない条件を書き出す | ルールの整理、サーバー側での制御に寄せる |
| 特定機能への依存が不安 | どの機能に依存しているか、代替があるか | 依存箇所だけを個別に置き換える |
特に1行目が重要です。請求額の内訳を見ないまま「Firebaseは高い」と判断すると、移行後に同じ課題が再現します。 課金の主因が読み取り回数なら、それはデータ設計の問題であって、移行先を変えても解決しません。
料金はどう比較するのか？
DBだけでなく、認証、ストレージ、転送、実行、ログ、バックアップ、管理者の作業を同じ条件で比べます。
Supabaseの公式料金ページに掲載されている2026年9月23日時点の内容は次のとおりです。
| プラン | 月額 | 含まれる主な枠 |
|---|---|---|
| Free | 0ドル | MAU 50,000／DB 500MB／egress 5GB／ストレージ 1GB |
| Pro | 25ドル | MAU 100,000／ディスク 8GB（プロジェクトあたり）／egress 250GB／ストレージ 100GB |
| Team | 599ドル | Pro と同等の枠に SOC2・ISO 27001 対応と SLA 付きサポート |
| Enterprise | 個別 | 枠・機能を個別に設定 |
超過分は、MAU 1人あたり0.00325ドル、DB 1GBあたり0.125ドル、egress 1GBあたり0.09ドル、ストレージ 1GBあたり0.0213ドルが月末に加算されると記載されています。Proプランでは支出上限（Spend caps）が既定で有効で、超過して使い続けたい場合は自分でオフにする設計です。
一方のFirebaseは、以前は「Blazeプランに支出上限がない」という整理が一般的でしたが、2026年9月23日時点では状況が変わっています。 Firebase公式ドキュメントによると、支出上限は Firebase AI Logic、Firebase App Hosting、Cloud Functions for Firebase、Firebase Extensions の4サービスで設定でき、上限到達でその月の新規利用が一時停止されます。ただし同ドキュメントは、使用量集計の遅れにより適用が数分遅れその間の超過は通常課金されること、絶対に超えられない「ハードキャップ」ではないため実際の限度よりやや低く設定することを推奨しています。
また請求額の急増を避けるためのドキュメントでは、予算アラートはサービスを停止しない（通知のみ）と明記されています。Firestore や Storage のような中心的なサービスは支出上限の対象外です。
つまり両者の差は「上限を設定できるか」ではなく、「中心となるサービスに上限が効くか」に移っています。 自社が主に使っているサービスが対象に含まれるかを確認してください。
データ移行では何が移せて、何が移せないのか？
件数のコピーは自動化できます。構造の翻訳は自動化できません。
Supabase公式のFirestoreデータ移行ガイドでは、3つのスクリプト（collections.js でコレクション一覧、firestore2json.js でJSON書き出し、json2supabase.js でPostgresへ取り込み）が案内されています。ただし同ガイドには制約が明記されています。Firestoreのコレクションは「フラット化」され、text・numeric・boolean・jsonb といった基本的な型の列を持つテーブルに変換されます。 構造が複雑な場合は、取り込み前にJSONを複数の関連テーブルへ分割するプログラムを自分で書く必要がある、と案内されています（カスタムフックで書き出し時に分割する方法も示されています）。
移行対象ごとに、自動化できる範囲を整理します。
| 対象 | 確認する内容 | 自動化の可否 |
|---|---|---|
| データ本体 | ドキュメント構造、参照、ID、日時、欠損値 | 書き出し・投入は可。構造の再設計は人の作業 |
| ネスト・配列 | 別テーブルに正規化するか、jsonb列で持つか | 判断は人。後で集計・検索したいかで決まる |
| サブコレクション | 外部キーを持つ別テーブルへの変換 | 分割処理を自分で書く必要がある |
| 認証 | プロバイダ、ユーザーID、再ログイン、メール確認 | 一覧は移せるがログイン条件の再現は別作業 |
| 権限 | Security Rules で実現していた条件 | 移せない。RLSポリシーとして書き直す |
| ファイル | 所有者、URL、公開範囲、削除 | 実体は移せるが、URLの変更がアプリに影響する |
| 関数 | トリガー、定期処理、再送、秘密情報 | 移せない。書き直しと再設定が必要 |
| リアルタイム購読 | 購読対象、切断時の挙動、エラー表示 | 移せない。SDK呼び出しの書き換えが必要 |
表の後半、「移せない」と書いた4項目が工数の主体です。 データ件数の一致を確認して終わりにせず、アプリから業務を完了できるかを別に試してください。
認証移行で起きる落とし穴は？
パスワードのハッシュ方式が異なるため、ユーザー一覧を単純コピーしてもログインできません。
Firebaseは scrypt、Supabase は bcrypt を使います。Supabase公式のFirebase Auth移行ガイドでは、firestoreusers2json でユーザーを書き出し、import_users で auth.users へ取り込む手順が案内されており、その際 Firebaseコンソールの認証設定から base64_signer_key、base64_salt_separator、rounds、mem_cost といったハッシュパラメータを取得するよう指示されています。
同ガイドは、既存のFirebaseパスワードを検証して初回ログイン時にSupabase側へ更新するミドルウェアについては、完全版のリポジトリを参照するよう案内しています。この仕組みを用意するかどうかが、「利用者がパスワード再設定なしで移行できるか」の分かれ目です。
認証まわりで先に決めることを整理します。
| 確認項目 | 決めておくこと |
|---|---|
| パスワード認証の利用者 | 初回ログイン時の移し替えを実装するか、再設定を案内するか |
| SNSログイン（Google等） | 移行先で同じプロバイダを設定し、同一人物として紐づく条件を確認する |
| ユーザーID | Firebase の UID を引き継ぐか、新しいIDを振って対応表を持つか |
| メール未確認の利用者 | 移行後の扱い（確認済みとするか、再確認を求めるか） |
| 退会済みの利用者 | 移行対象に含めるか、除外して記録だけ残すか |
ユーザーIDの扱いは特に影響が広範囲です。 他のテーブルがユーザーIDを参照しているため、IDを振り直す場合は全参照の書き換えが必要になります。
権限設計（RLS）で事故が起きやすいのはどこか？
有効化の忘れと、書き込み制御の書き漏れです。
SupabaseのRLSドキュメントでは、公開スキーマのすべてのテーブルでRLSを有効にすることが推奨されています。公開スキーマでRLSが無効なテーブルは、権限を持つロールから読み書きできる状態です。 さらに同ドキュメントは、ポリシーを追加しても既存の権限付与（grant）が自動的に取り消されるわけではないため、明示的に revoke する必要があると注意しています。
もう一つの事故点は using と with check の使い分けです。ドキュメントの説明を整理します。
| 操作 | 使う句 | 意味 |
|---|---|---|
| SELECT | using | 見える行を絞り込む |
| INSERT | with check | 新しい行がポリシーを満たすか検査する |
| UPDATE | using と with check の両方 | どの行を変更できるか＋変更後の行が妥当か |
| DELETE | using | どの行を削除できるか |
UPDATE で with check を書き漏らすと、見える行を任意の値に書き換えられる余地が残ります。 また同ドキュメントには、UPDATE を機能させるには対応する SELECT ポリシーも必要と記載されています。
性能面では2点が推奨されています。ポリシーで絞り込みに使う列すべてにインデックスを張ること（インデックスがないと逐次スキャンになる）と、auth.uid() のような補助関数を select で包むこと（最適化器が文単位で結果をキャッシュでき、行ごとの呼び出しを避けられる）です。あわせて、ロール別のテストを必ず行ってください。「見えてはいけない行が見えていないか」の検証を省くと、そのまま情報漏えいにつながります。
切り替えと切り戻しはどう設計するのか？
停止なしを先に約束せず、戻せる状態を保ったまま進めます。
小さな移行リハーサルから始めてください。会員管理を例にすると、通常会員・退会済み・SNSログイン・メール未確認・添付ありの記録を選び、IDの対応、権限、ログイン、更新、退会を通しで確認します。件数が一致しても、アプリから業務を完了できるかは別に試す必要があります。
切り戻しの条件は、判断に迷わない形で先に書き出します。権限外の参照ができる状態が1件でも確認された、請求対象の照合が合わない、必要なログインが成立しない利用者がいる、主要画面の応答が業務に支障する水準まで落ちた。こうした条件を公開停止の判断基準にします。
あわせて、戻す担当、戻す環境、移行後に追加されたデータの扱いを決めます。二重書き込みを行うなら、どちらを正本とするか、失敗時にどう整合を取るかも事前に決めてください。ここが曖昧なまま二重書き込みを始めると、戻すときにデータが分岐します。
一括で短時間の停止を挟む方式と、段階的に切り替える方式のどちらを選んでも、ロールバック計画は必ず用意します。 一括は速い代わりに戻しにくく、段階移行は検証期間を含めて相応の工数がかかります。
工数と費用を見積もる
認証移行、データ変換、アプリ修正、新旧照合、並行稼働、切り戻しを個別に積み上げます。
まとめて「移行一式」とせず、上記の工程ごとに分けてください。特にスキーマ再設計は、データ移行スクリプトの作成とは別の作業として扱います。
当社の作業単価は 1時間11,000円（税込） です。要件定義・契約後のすり合わせ・開発・テスト・バッファの時間を積み上げて見積もります。バッファは未確定事項ごとに理由を示し、クラウド・API等の実費と保守契約は別に確認します。初回相談・認識合わせの無料モック・お見積もりは無料です。見積もりの進め方と相談シートで整理できます。
既製のSaaSに業務が収まらなくなってきた段階なら、SaaSからのフルスクラッチ移行で、限界のサインの見極め方と業務を止めない移行の進め方を整理しています。移行後の構成そのものはNext.js・Supabaseで業務システムを作る、ホスティング先の費用比較はVercelとAWSの費用を比べるもあわせて参考にしてください。
よくある質問
Q. データを移せばアプリはそのまま動きますか？
動きません。SDK呼び出し、クエリ、認証、権限、関数の変更が必要かを個別に確認してください。特にリアルタイム購読とサーバーレス関数は移せず、書き直しになります。データ移行とアプリ移行は分けて見積もるのが実務的です。
Q. 停止なしで移行できますか？
更新量、外部連携、移行方式によります。無停止を先に約束せず、並行稼働と切り戻しの条件を検証してから判断してください。検証期間を含めると「一晩で乗り換え」という期待は現実的でない場合が多くあります。
Q. Firebaseのままではいけないのでしょうか？
問題ありません。請求の予測性、SQLでの集計、特定機能への依存の不安。これらのどれも当てはまらないなら、残す判断は十分に合理的です。移行コストは既存資産の深さに比例して上がるため、モバイルSDKやFirebase固有の連携を深く使っているほど、残す理由が強くなります。 ただし、依存先の仕様変更や提供終了は判断材料に入れてください。Firebase Dynamic Links が2025年8月25日に停止した例があります。
自社の状況を整理して相談する
まず、Firebaseの利用機能、認証方式、データ構造、切り戻し条件を書き出してください。この記事に合う検討シートとAI相談用プロンプトで、未確認の項目を残したまま整理できます。シートを完成させる前でも、お気軽にご相談いただけます。
運営・編集