【2026年版】Firebase・個別SaaSから Supabase へ移行する判断と進め方

「Firebaseの請求が、今月いくらになるか読めない」——そんな不安を抱えていませんか。

無料枠を超えた途端に金額が跳ね上がった。あるいは、認証はFirebase、データは別のSaaS、分析はまた別のツール…と散らばってしまい、もう誰も全体像を把握できていない。そんな状態に心当たりがあるかもしれません。

先にお伝えしておきたいことがあります。「移行＝正義」ではありません。 Firebaseのままが正解のケースも、たくさんあります。

この記事では、Supabaseに「移すべきか・残すべきか」をフラットに見たうえで、もし移すなら現実的な進め方まで一緒に整理します。固有のスタック名（Firebase / Supabase）で発注先や判断材料を探している、技術決裁者・情シス・内製チームの方を想定しています。

この記事で分かることは、次の3つです。

移すか残すかを決める「5つの判断軸」
データ移行とRLS設計を、どう進めるか
サービスを止めずに乗り換えるコツ

まず前提：FirebaseとSupabaseは「似て非なる」もの

どちらが上か、という話ではありません。向くケースが違うだけです。まずはその違いをフェアに整理します。

Firebaseは、Googleが提供するモバイル/Webアプリ向けのバックエンドです。認証・データベース・ストレージ・サーバーレス関数がそろい、エコシステムの統合が強みです。

Supabase（スパベース＝PostgreSQLをベースにしたオープンソースのBaaS）も、認証・ストレージ・リアルタイム・サーバーレス関数を持ちます。ここは両者とてもよく似ています。

決定的な違いは「データベースの型」

最大の違いは、データの持ち方です。

Firestore：ドキュメント型（NoSQL）。柔軟だが、join（テーブルの結合）や外部キー、スキーマ強制がない
Supabase：PostgreSQL（リレーショナル/SQL）。テーブル・外部キー・join・制約・ビューを備えた本格的なリレーショナルモデル

この違いが、移行の「難所」であり、同時に「利点」でもあります（出典：Bytebase / Supabase公式、2026年6月時点）。

つまり、Supabaseへの移行は「そっくり置き換える」作業ではありません。データの考え方を「翻訳」し直す作業です。ここを最初に腹落ちさせておくと、後の判断がぶれません。

移すべきか・残すべきか──5つの判断軸

抽象論ではなく、自社に当てはめて考えられるよう、5つの軸で整理します。それぞれ「Firebaseのままが向くケース」と「Supabaseに移す価値が出るケース」を併記します。

1. コスト予測性

ここが移行を検討する最大のきっかけになりがちです。

Firebaseの従量課金プラン「Blaze」には、ハードな支出上限（spend cap）がありません。画像へのbot巡回、突然のバズ、古いファイルの削除忘れといった「1日のミス」が、予期しない高額請求につながりうる構造です。「pay as you go は悪ではないが、予算は立てにくい」と整理されています（出典：SashiDo、2026年6月時点）。具体的な金額はリージョンや操作数で大きく変わるため、必ず公式の料金ページで自社の利用量を当てはめて試算してください。

一方Supabaseは、Proプラン（$25/月）で支出上限（Spend caps）がデフォルトでオンです。請求が暴走しにくい設計になっています（出典：Supabase公式料金ページ、2026年6月時点）。

ただし注意があります。「Supabaseは安いから必ず安くなる」とは限りません。 SupabaseのProにもMAU（月間アクティブユーザー）・DB容量・egress（外向き通信量）の超過課金があり、規模次第ではFirebaseと逆転しえます。利点は「絶対額が安い」ことより、「請求が予測しやすい」ことにあります。実際の金額は必ず自社の利用量で試算してください。

Firebaseのまま：利用量が小さく、請求が安定して読めている
Supabaseへ：読めない従量課金が経営の不安になっている

2. データの形

集計・結合・レポートが増えてきたなら、SQL（PostgreSQL）が効きます。「先月の売上を顧客セグメント別に出したい」といった要求が増えるほど、リレーショナルの強みが出ます。

逆に、単純な読み書きが中心なら、Firestoreで十分なことも多いです。

3. ベンダーロックインの不安

Supabaseはオープンソースで、pg_dump（PostgreSQL標準のバックアップ）でいつでもデータを持ち出せます。自前ホストも選べるため、「いつでも離脱できる」出口が確保しやすいのが特徴です（出典：Bytebase、2026年6月時点）。

Firebaseは統合の強さが魅力ですが、特定機能への依存はリスクにもなります。実例として、Firebase Dynamic Linksは2025年8月25日に完全停止しました（出典：Firebase公式FAQ、2026年6月時点）。依存先の都合で、仕様変更や終了が起こりうる——この点も判断軸に入れておくべきです。

4. 既存資産

モバイルSDKやFirebase特有の連携機能を深く使っているほど、移行コストは上がります。「残す」という判断も、十分に合理的です。無理に動かす必要はありません。

5. 社内の運用体制

SQLを扱える人、あるいは扱う気のある人が社内にいるか。ここは見落とされがちですが、移行後の運用まで含めると重要な軸です。いないなら、その負担まで含めて判断します（この点は後ほどFAQで触れます）。

移行の山場(1) データ移行：NoSQLからSQLへ「形」を作り直す

ここからは、移すと決めた場合の現実的な進め方です。まず最大の誤解を解いておきます。

移行は「データをコピーするだけ」ではありません。 非正規化されたFirestoreのドキュメント構造を、リレーショナルなスキーマへ「再設計」する作業が本体です。重く非正規化していた場合、データモデリングだけで数週間かかることもあります（出典：dev.to、2026年6月時点）。費用見積もりの主軸は、データ移行そのものより「スキーマ再設計」に置くのが現実的です。

ネストや配列をどう扱うか

Firestoreのネスト構造や配列フィールドは、次のどちらかで持ち直します。

別テーブルに切る（正規化）：サブコレクションは、外部キーを持つ別テーブルに変換するのが基本
JSONB列で持つ：構造をそのまま1つの列に格納する

どちらが良いかは、後で集計したいか・検索したいかで変わります。

移行手順の骨子

現状のデータ構造を棚卸しする
PostgreSQLのスキーマを設計する（型を厳密に定義し直す）
移行スクリプトで変換・投入する
件数と整合性を突合して検証する

Supabase公式は、Firestore→Postgres変換用に3つのCLIスクリプト（collections.js / firestore2json.js / json2supabase.js）を提供しています。複雑な構造は、事前にJSONを複数テーブルへ分割するプログラムを書く必要があります（出典：Supabase公式ドキュメント、2026年6月時点）。

ここでAI＋人のハイブリッド運用が効きます。スキーマ変換やマッピングの「叩き台」はAIで素早く作り、最終のデータ整合性チェックは人が確認する——この分担です。完全自動化、とは言いません。規模により工数は変わります。

似た発想で「既存システムにAIを後から組み込む」考え方は、作り直さずにAI化する現実的なアプローチでも触れています。あわせて読むと、自前化の線引きがイメージしやすくなります。

移行の山場(2) RLS設計：「誰がどの行を見られるか」を作り込む

Supabase移行で、最も事故が起きやすいのがここです。

RLS（Row Level Security＝行レベルのアクセス制御。テーブルの行単位で「誰がアクセスできるか」を制御する仕組み）を、丁寧に作り込む必要があります。

Firebaseのルールとの違い

Firebaseは独自記法のセキュリティルールでアクセスを制御します。SupabaseはSQLのポリシーで書きます。考え方は近いものの、書き換えが必要です。

よく使うポリシーの方針は、次のとおりです。

本人の行だけ見せる
組織（テナント）単位で分ける
管理者ロールは全件見られる

「有効化」と「正しい設計」は別物

ここで2つの落とし穴があります。

1つ目。RLSを有効化し忘れると、APIキーを持つ全員（未ログインユーザー含む）が全テーブルの全行にアクセスできてしまいます。 テーブル作成直後にRLSを有効化し、「デフォルト拒否」で組むのが安全な原則です（出典：IT Path Solutions、2026年6月時点）。

2つ目。RLSポリシーには、読みを制御するUSINGと、書きを制御するWITH CHECKがあります。書き込み系でUSINGしか書いていないと、見える行であれば任意の値に書き換えられてしまいます。RLSは、アプリ側のフィルタだけに頼らない「多層防御」として機能させるものです（出典：Makerkit、2026年6月時点）。

パフォーマンスとテスト

RLSは設計を誤ると遅くなります。Supabase公式は、ポリシーで使う列にインデックスを張ること、auth.uid()を(select auth.uid())のようにサブクエリで包むことを推奨しています。同社の検証では、インデックス付与や関数のラップで、ナイーブな実装に比べ実行時間が大きく短縮された結果が示されています（出典：Supabase公式、2026年6月時点）。行数が増えるほど、この最適化の効き目は大きくなります。

そして最後に、ロール別のテストを必ず行います。「見えてはいけない行が、見えていないか」を検証する——ここを省くと、そのまま情報漏えいに直結します。

移行の山場(3) 認証とダウンタイム：サービスを止めずに乗り換える

認証移行の現実

「パスワードも全部そのまま移せる」という安易な断定は危険です。

Firebaseはscrypt、Supabaseはbcryptと、パスワードのハッシュ方式が異なります。単純コピーではエラーになります。

ただし、ユーザーに再登録を強いる必要はありません。Supabaseコミュニティの移行ツールは、Firebaseのハッシュパラメータを保存し、初回ログイン時に旧パスワードを検証してSupabase側のパスワードへ更新する仕組みを用意しています。これにより、ユーザーは原則パスワード再設定なしで移行できます（出典：supabase-community、2026年6月時点）。なお一部のミドルウェアは開発途上（Work in Progress）の扱いのため、本番採用時は最新の実装状況を必ず確認してください。この運用を省くと、全ユーザーにパスワード再設定を強いることになります。

ダウンタイムを避ける段階移行

無停止移行の定石は「二重書き込み（デュアルライト）＋バックフィル＋段階的なカットオーバー」です。旧系へ書き続けつつ新系にも書き、全データを移し終えてから切り替えます。シャドウリード（新旧の結果を突き合わせる読み取り検証）を挟むと、より安全に確信を持てます（出典：dev.to、2026年6月時点）。言葉が硬いので、順を追って整理します。

読み取りだけ先に切替、または旧システムから読み続ける
二重書き込み（デュアルライト）：新旧両方に書き込む期間を設ける
バックフィル＋整合検証：旧の全データを新へ移し、両系の整合を検証する
十分な確信が得られたら、読み取りの正本を新へ寄せ、旧を停止する

一括 vs 段階の使い分け

一括（ビッグバン）：小規模なら、短時間メンテで一気に移すのが速い。ただしロールバック不能リスクが高い
段階移行：止められないサービス向け。実質ノーダウンに近づけられるが、検証期間を含めて相応の工数がかかる

どちらを選んでも、ロールバック計画は必ず用意します。 「戻せる状態」を保ったまま進めるのが、現場の鉄則です（出典：dev.to、2026年6月時点）。移行スクリプトの生成や差分チェックはAIで省力化できますが、切替の最終判断は人が行います。

散らばったSaaSからの移行も、同じ考え方で

ここまではFirebaseを軸に話しましたが、考え方はもっと広く使えます。

「認証はA社、フォームはB社、CRMはC社」と分散したSaaSを、Supabase＋Next.jsの自社基盤に寄せる場合も、5つの判断軸とデータ移行・RLSの考え方はそのまま共通です。ツールの乱立そのものに悩んでいる方は、もあわせてご覧ください。

進め方のコツは2つです。

全部を一度に移さない：痛みの大きいツールから順に統合する「スモールスタート」を推奨します
残すべきSaaSを見極める：会計・決済・メール送信など専門領域は、無理に自前化せず、APIで連携する選択も合理的です

「全部Supabaseに寄せれば一元化できて万事解決」とは考えないことです。自前化が運用負荷を上げる領域もあります。なぜあえて自社開発を選ぶのか、その価値の整理はでも詳しく触れています。

よくある質問（FAQ）

Q1. Firebaseのままではダメなのでしょうか？

ダメではありません。コストの予測性、SQLでの集計、ベンダーロックインの回避——これらの必要が薄ければ、残す判断も十分に合理的です。記事で挙げた「コスト予測性・データの形・ロックインの不安」の3つの軸を、自社に当てはめてみてください。1つも当てはまらないなら、急いで動く理由はありません。

Q2. 移行中にサービスを止めずに済みますか？

規模次第です。小規模なら、短時間のメンテナンスで一括移行する手もあります。止められないサービスなら、二重書き込みを挟む段階移行で「実質ノーダウン」に近づけられます。いずれの場合も、ロールバック（元に戻せる状態）を前提に進めるのが安全です。「無停止で一晩のうちに乗り換え」という期待は、検証期間を含めると現実的でないことが多い、と正直にお伝えしておきます。

Q3. SQLやRLSに詳しい人が社内にいません。移行は無理ですか？

無理ではありません。設計と移行作業そのものは、AI＋人のハイブリッドで巻き取れます。むしろ大切なのは、移行後に「運用を続けられる体制」まで含めて考えることです。誰がインデックスを足すのか、誰がRLSポリシーをテストするのか——そこまで設計に含めておくと安心です。社内に専門家がいない場合こそ、判断の段階から相談するのが安全だと考えています。

まとめ：「移すか」より「どこまで自前にするか」

ここまでを3行で整理します。

まず5つの判断軸（コスト予測性・データの形・ロックイン・既存資産・運用体制）で、移すか残すかを決める
移すなら、データ移行・RLS設計・ダウンタイム回避という3つの山場を、段階移行で越える
どの山場も、AI＋人のハイブリッドで省力化しつつ、最終判断は人が握る

そして、いちばん伝えたいこと。移行の成否は「どこを自前にして、どこを任せ・残すか」の設計で決まります。

なお、ここに挙げた料金・機能は2026年6月時点の整理です。各サービスの仕様は変わるため、実際の判断時は必ず最新の公式情報をご確認ください。

私たちゼットリンカーは、Next.js × Supabase のフルスクラッチ受託で、Firebaseや散らばったSaaSからの移行を、RLS設計・データ移行・ダウンタイム回避までAI＋人のハイブリッドで伴走しています。「移すべきか」の判断だけのご相談でも構いません。現状のスタックを聞かせていただければ、残す・移す・分割するの選択肢を一緒に整理します。お気軽にご相談ください。