Supabase 代替7選：Appwrite・Neon・Firebaseの選び方【2026年】

Supabase 代替を選ぶときは、Supabaseの何を置き換えたいかを先に決めることが大切です。バックエンド一式とセルフホストの選択肢が必要ならAppwrite、Postgresを維持して移行するならNeon、リアルタイムのドキュメントデータを中心にモバイルアプリを作るならFirebaseが候補になります。ここで紹介する7つのサービスは、それぞれ置き換える範囲が異なります。今のデータベース、ログイン、アクセスルールがアプリに合っているなら、Supabaseを使い続ける判断も有効です。

2026年11月14日、各提供元の料金ページとドキュメントで確認しています。 本記事はドキュメントに基づく比較です。実機検証や性能ランキングではありません。

Supabase 代替の比較早見表

料金を比べる前に、置き換える範囲を決めましょう。マネージドデータベースで置き換えられるのは、テーブルを置く場所です。バックエンドプラットフォームなら、ログイン、ファイル保存、サーバー側コードの実行にアプリが利用するサービスも含まれます。

CU-hourはNeonのデータベースコンピュートの課金単位です。その単価だけで月額総額が決まるわけではありません。同様に、FirebaseとAmplifyにも、バックエンドの全リソースをまとめた単一のサブスクリプション料金はありません。各節の料金リンクが、上記の開始価格の出典です。

各サービスで何を置き換えられるか

全体を見渡せるよう、関連する機能を同じセルにまとめています。「ストレージ」はファイルまたはオブジェクトの保存を指し、データベースのディスク容量ではありません。「セルフホスト」はバックエンドを自分で運用することで、フロントエンドだけを別の場所にデプロイする意味ではありません。

意外に感じるかもしれないのがNeonです。現在は認証、オブジェクトストレージ、関数も提供し、リアルタイム機能はベータ版です。「データベースだけで、認証もストレージもない」と捉えると、現在の製品を正しく比較できません。

先にバックエンドの構成を決める

アプリの価値がすでにSQLの中にあるなら、Postgresを維持しましょう。 PostgreSQL、通称Postgresは、Supabaseの基盤となるリレーショナルデータベースです。関連するレコードをテーブルに保存し、テーブルをまたいでクエリできます。顧客、請求書、権限の仕組みがそこで動いているなら、そのモデルを残すことで不要な作り直しを避けられます。

請求書アプリを移行する創業者なら、新しいドキュメントデータベースより先に、Postgresを維持できる候補を検討するのが妥当です。大切なのは管理画面のわかりやすさよりも、事業に必要なクエリとアクセスルールが移行先で動くかどうかです。

統合サービスに問題があるなら、バックエンド全体を置き換えましょう。 ログイン、ファイルAPI、関数ランタイム、運用方法を変えたいなら、サービス一式として評価する必要があります。AppwriteとNhostはこの観点で有力です。サービスを拡充したNeonも検討対象になります。

データモデルを変えるのは、アプリに具体的な利点がある場合に限りましょう。 Firebaseのドキュメント同期、Convexのリアクティブなプログラミングモデル、PocketBaseの小さなセルフホスト構成には、作り直しを検討する理由があります。どのリソースが原因かもわからないまま、請求額が気に入らないというだけでは十分ではありません。

サービス名の違いがまだ整理できない場合は、Supabaseのアーキテクチャ解説で、データ、ID、ファイル、アプリのロジックをそれぞれ何が担当するか確認できます。

移行作業まで見据えた7つの代替サービス

1. Appwrite：バックエンド全体を置き換える有力候補

Appwriteは、認証、データベース、ファイルストレージ、関数、リアルタイムというSupabaseの幅広いサービス群を置き換えます。これらをまとめて使い、マネージドクラウドと自社インフラを実際に選べる構成が欲しい場合、最初に評価したい候補です。

顧客ポータルを作る創業者にとって、魅力は明快です。ログイン、顧客レコード、アップロードされた書類、サーバー側の処理を同じプラットフォームにまとめられます。データベースのホスティングだけを契約する場合より、Supabaseと同じ範囲で比較しやすい選択肢です。

ただし、データベースの構成は丁寧に確認する必要があります。現在の標準サーバーレス構成はTablesDBで、専用データベースの選択肢にはPostgreSQL、MySQL、ドキュメントデータベースなどが挙がっています。PostgreSQLを選べばSupabaseのクライアント呼び出し、ストレージ権限、認証連携までそのまま移せるとは限りません。データベースエンジンの互換性とアプリケーションAPIの互換性は、別々に確認します。

Appwriteはオープンソースで、DockerまたはKubernetesによるセルフホストに対応しています。セルフホストのガイドにも明記されているとおり、保守とスケーリングは自分で担います。管理権限を重視する場合には価値がありますが、自前で運用すれば安くなるという約束ではありません。

別の選択肢を検討すべき場合： 既存のPostgresアーキテクチャを直接使いたく、Appwriteのサービスインターフェースに合わせる作業が、削減できる作業より大きい場合です。また、クラウドのFreeプランではリソース上限に達するとプロジェクトが凍結されます。試作向けの無料枠を、検証せず本番運用の前提にしないことが重要です。

向いている人： セルフホストも選べる、幅広いバックエンド一式を求める創業者。
特徴： マネージドでも自前運用でも利用できるサービスの幅広さ。
料金： Appwriteの料金ページによると、Proは月額$25からです。
無料利用： クラウドのFreeプランがあります。期間限定の試用だけではありません。

移行前にAppwriteをどう評価するか

1. 1

   代表的なユーザー操作を選ぶ

   顧客がログインし、自分のレコードを読み、非公開の書類をアップロードする流れを使います。公開のToDoリストよりも広い範囲のバックエンドを確認できます。

2. 2

   依存する機能を洗い出す

   その操作で使うデータベースクエリ、本人確認、ストレージ権限、サーバー側処理を列挙します。それぞれをAppwriteのどのサービスで置き換えるか決めます。

3. 3

   独立した検証環境を作る

   機密性のないレコードのコピーとテストアカウントを使います。そのアカウントで自分の書類にはアクセスでき、別の顧客の書類にはアクセスできないことを確認します。

4. 4

   運用担当を決める

   バックアップ、アップグレード、障害対応の責任者を決めてから、クラウドかセルフホストかを選びます。そのうえで、移行が元の問題を解決するか判断します。

2. Neon：Postgresを軸に、周辺サービスも選べる構成

Postgresを維持しながら周辺サービスを見直すなら、この中で最初に検討したいのがNeonです。データベースのブランチ機能で独立した環境を作れるため、本番を実験台にせずスキーマ変更を試したい開発者に役立ちます。

ビジネスロジックをすでにサーバー側で処理しているSaaSアプリを考えてみましょう。必要なのはデータベースのホスティング先の変更だけで、ログインやファイルサービスを同時に置き換える必要はないかもしれません。移行範囲を絞れば、プロジェクトを把握しやすくなります。

現在のNeonは、その限定的な役割より広い範囲をカバーできます。バックエンド製品のアップデートには、Managed Better Auth、関数、S3互換のオブジェクトストレージが記載されています。これらのサービスもデータベースと一緒にブランチ化できます。リアルタイム機能は現在ベータ版です。共同編集が製品の要なら、移行理由にする前にその提供段階を評価しましょう。

データベースのコアは、提供元のオープンソースリポジトリで公開されています。ただし、ホスト型バックエンド全体と同等のものを、すぐセルフホストできるという意味ではありません。Neonはマネージドサービスとして選びましょう。リポジトリの公開だけで、全機能から簡単に離脱できると考えるべきではありません。

別の選択肢を検討すべき場合： 密接に統合されたサービスの挙動にアプリが依存しており、依然として調整が必要な場合や、現在ベータ版のリアルタイム機能に代わる成熟した仕組みが必要な場合です。SQLの維持でデータベースの作り直しは減らせますが、サービス移行までなくなるわけではありません。

向いている人： 既存のPostgresアプリを持つ人や、独立したデータベース環境を求める開発者。
特徴： テーブルだけでなく、関連するバックエンドサービスにも広がったブランチ機能。
料金： Launchは従量課金です。コンピュートはCU-hourあたり$0.106で、ほかのリソース料金も発生します。Neonの料金ページを参照してください。
無料利用： Freeプランがあります。

3. Firebase：モバイルでドキュメント同期を使うなら

Firebaseは、リアルタイムデータとオフライン利用が中心になるアプリ、特にモバイルアプリに適しています。Cloud Firestoreはコレクション内にドキュメントを保存するデータベースで、Firestoreのドキュメントにあるとおり、リアルタイムリスナーとオフライン動作をサポートします。

通信が途切れる現場で、スタッフが作業記録を更新するアプリを想像してください。これはFirestoreのクライアント動作を調べる具体的な理由になります。一方、どちらにもログイン機能があるというだけで、すでに稼働している請求書データベースを移す理由としては弱いでしょう。

FirebaseはAuthentication、Firestore、Cloud Storage、Cloud Functionsで主要なバックエンド機能を置き換えられます。独自のマネージドバックエンドであり、本番環境一式を自分のサーバーへ移せる製品ではありません。標準的なFirestore構成では、データの整理方法とクエリ方法も変わります。

ただし重要な補足があります。Firebaseは現在、Cloud SQL for PostgreSQLを基盤とするSQL Connectも提供しています。そのため「FirebaseにはSQLの選択肢がない」という説明は不正確です。Firestoreのドキュメントの扱いとSQL Connectを同一視せず、別のアーキテクチャとして評価してください。

別の選択肢を検討すべき場合： 選んだドキュメントモデルではアプリに必要なリレーショナルクエリを扱いきれなくなった場合や、独立したホスティング、利用量と費用のわかりやすい関係を求める場合です。SupabaseからFirestoreへの移行は、Postgresのダンプを復元する作業ではなく、クエリとアクセスルールを変換する作業になります。

向いている人： Firestoreのリアルタイム動作とオフラインのドキュメント処理が役立つモバイル／Webアプリの開発者。
特徴： クライアント向けのドキュメント同期。
料金： Blazeは従量課金で、Firebaseの料金ページに単一の固定月額料金は記載されていません。
無料利用： Sparkは無料プランですが、現在の料金表ではCloud StorageとCloud FunctionsにBlazeが必要です。

アーキテクチャの違いを詳しく知りたい場合は、SupabaseとFirebaseの比較を参照してください。

4. Nhost：Postgresを残し、GraphQLを明確に選ぶ

Postgresを使いながらGraphQL中心のAPIを求めるなら、Nhostが最も近い選択肢です。GraphQLは、クライアントが特定のフィールドや関連レコードを指定して取得できるクエリ言語です。NhostはPostgres、HasuraのGraphQL API、認証、ストレージ、サーバーレス関数を組み合わせています。

顧客ポータルで、アカウント情報、プロジェクト、直近の活動をまとめて表示するなら、このAPIの形がフロントエンドに合うかもしれません。移行理由は、そのアプリケーションインターフェースを使いたいことです。Postgresを使うプラットフォームならすべて同じように動く、という想定ではありません。

Nhostのソースリポジトリには、オープンソースの構成とDocker Composeによるセルフホスト例が記載されています。データベースのマイグレーションとHasuraのメタデータを追跡するローカル開発についても説明されています。このメタデータは重要です。APIの設定と権限は、データベーススキーマと同じくアプリの一部だからです。

別の選択肢を検討すべき場合： GraphQLとHasuraの設定層を保守したくない場合です。製品に必要なエンドポイントをすでにサーバーが提供しているなら、API層を追加しても顧客の問題を解決せず、管理対象だけが増える可能性があります。

Postgresを維持すれば、データの移行先はなじみのあるものになります。ただし、Supabaseの行ポリシーがNhostのロールベースのAPI認可へ自動変換されるわけではありません。別々の受け入れ基準として確認してください。

向いている人： PostgresとGraphQL中心のバックエンドを明確に求めるチーム。
特徴： Postgresを中心に統合されたGraphQLサブスクリプション、ID、ファイルストレージ。
料金： Proは月額$25からです。Nhostの料金ページには組織単位のプランが掲載されています。
無料利用： Starterは無料です。利用のないプロジェクトは一時停止されます。

5. Convex：リアクティブな開発モデルを選ぶなら

Convexは、JavaScriptまたはTypeScriptの関数を通してアプリを動かすリアクティブバックエンドで、データベースアクセスとサーバー側のアプリケーションロジックを置き換えます。認証、ファイルストレージ、スケジュール実行も提供します。

複数人が共有の作業内容を更新し、その変化をUIに反映する共同計画アプリは、有力な用途です。その挙動を中心に開発したいからConvexを選ぶのであって、既存のSQLアプリを変更せず持ち込めると期待して選ぶものではありません。

データベースのドキュメントでは、重要な区別が示されています。ConvexはJSONに似たドキュメントを保存し、リレーショナルモデリングにも対応しています。Postgresではありませんが、関連を扱えないとするのも誤りです。読み書きにはSQLではなく、関数APIを使います。

セルフホストにも対応しています。バックエンドのライセンスに関するドキュメントでは、競合するホスト型サービスへの制限と、将来的なApacheライセンスへの移行を伴うフェアソースライセンスが説明されています。単純に「オープンソース」とチェックを付けるより、正確に区別すべき内容です。

別の選択肢を検討すべき場合： リアクティブなアプリケーションモデルよりも、SQL互換性やPostgres周辺のツールが重要になった場合です。セルフホストでConvexの実行場所は変えられますが、クエリがSQLになるわけではありません。

向いている人： 新規アプリ、または意図的に作り直すアプリで、リアクティブバックエンドを選ぶ開発者。
特徴： データ関数とリアクティブなアプリの挙動を、同じプログラミングモデルで扱えること。
料金： Convexの料金ページによると、Starterは月額$0＋従量料金からです。
無料利用： Freeプランがあります。

6. PocketBase：小さくセルフホストできるが、本番利用には注意

PocketBaseは、データベース、認証、リアルタイムサブスクリプション、ファイルストレージ、管理画面を、小さなセルフホスト型バックエンドにまとめています。組み込みSQLiteを使うため、マネージドPostgresとも、クラウドサービスを組み合わせた構成とも異なる選択肢です。

社内の備品台帳や小規模なコミュニティツールなら、バックエンドを単一の実行ファイルで運用できるのは魅力です。それでも、デプロイ、バックアップ、監視、アップグレードの担当者は必要です。「1つのファイル」はパッケージの形を示すもので、運用が不要になるという意味ではありません。

提供元の導入ドキュメントには、PocketBaseは現在も活発に開発されており、完全な後方互換性はまだ保証されず、手動の移行作業を受け入れない限り、重要な本番アプリには推奨しないとあります。推測に基づくスケール比較より、この注意事項のほうが重要です。

PocketBaseはオープンソースで、自分でホストします。ユーザー向けのバックエンド機能を複数置き換えられますが、マネージドホスティングのプランでも、SupabaseのPostgresをそのまま復元できる移行先でもありません。SQLiteのデータモデルとアプリケーションAPIに合わせた移行作業が必要です。

別の選択肢を検討すべき場合： アプリの重要度が高まり、自分で提供できる範囲を超える運用上の保証が必要になった場合や、アップグレードの責任がプロジェクトに見合わなくなった場合です。

向いている人： セルフホストの保守を意識的に引き受ける、小規模アプリの運営者。
特徴： データベース、認証、ファイル、リアルタイムをコンパクトなスタンドアロンアプリに統合。
料金： 提供元は無料ソフトウェアとして公開しており、有料のホスト型プランは記載していません。インフラは別途必要です。
無料利用： ソフトウェアを使うために、ホスト型の試用を申し込む必要はありません。

7. AWS Amplify：すでにAWSで運用しているチームに

AWS Amplifyは、AWSサービス上でアプリのバックエンドを構築し、サービス間の境界も管理する意思があるチームに向いています。標準のデータ構成ではAmazon DynamoDBを使い、AWS AppSyncのAPIとリアルタイムサブスクリプションを組み合わせます。

すでにAWSアカウントで運用している企業には、実用的な構成になり得ます。IDにはAmazon Cognito、ファイルにはAmazon S3、独自のバックエンドロジックにはAWS Lambdaを使えます。一方、初めてバックエンドを選ぶ個人の創業者には、障害時に理解すべき概念がその分増えます。

Amplifyのデータ設定ガイドでは、TypeScriptのモデル定義からデータベースとAPIのリソースを作る方法が示されています。効率的に土台を作れますが、Supabaseから移行するには、SQLデータ、権限、関数を選択したAWSサービスへ対応付ける必要があります。

JavaScriptライブラリはオープンソースです。ただし、接続先のマネージドAWSサービスは、移設可能なセルフホスト型バックエンドではありません。自分のAWSアカウントへのデプロイで管理できるのは、そのクラウド構成です。AWSから独立できるという意味ではありません。

別の選択肢を検討すべき場合： アプリの要件が単純で、AWSサービス間の調整が、より一体化されたバックエンドを使う場合よりも多くの運用作業を生む場合です。

向いている人： AWS上のアプリを運用する体制がすでにあるチーム。
特徴： ID、データ、ストレージ、関数をAWS上にコードで定義する構成。
料金： バックエンド利用に月額最低料金はありません。Amplifyの料金ページのとおり、基盤サービスの利用量に応じて課金されます。
無料利用： AWS Free Tierの利用可否は、サービスとアカウントの適用条件によります。

これから評価する場合は、現在のAmplifyのドキュメントを起点に、参照するチュートリアルが同じ構成を説明しているか確認してください。

結局、どのSupabase代替サービスを選ぶべきか

バックエンド一式が必要ならAppwriteです。 サービスの幅広さと明確なセルフホストの選択肢を両立しているため、この用途では最有力です。Postgresの維持とGraphQLの採用をより重視するなら、推奨はNhostに変わります。

Postgresの維持が最優先ならNeonです。 まずデータベースの移行から始め、追加サービスのどれを使うかを後で決めましょう。同じ提供元で両方使えるというだけで、管理可能なデータベース移行を認証基盤の作り直しにまで広げる必要はありません。

作り直す価値のあるアプリの挙動が欲しいならFirebaseかConvexです。 FirebaseのFirestore構成はリアルタイムのドキュメントとオフラインクライアントに、Convexはリアクティブなデータ関数モデルに向いています。どちらも、最も簡単なテーブルを移すより、最も難しいユーザー操作が実際に動くことを示すほうが重要です。

意図的にシンプルさを選ぶならPocketBase、すでにAWSを使う方針ならAmplifyです。 どちらも万能な受け皿ではありません。PocketBaseは運用者に責任を移し、Amplifyは責任をAWSの各サービスへ分散させます。

ベクトル検索の要件がpgvectorで対応できる範囲を超えるなら、Pineconeを独立した検索レイヤーとして評価してください。Supabaseのバックエンドを置き換えるものではありません。

Supabaseを使い続けたほうがよい場合

SQLモデル、ログインフロー、行レベルセキュリティがすでに製品に合っており、移行先で同じものを再現しても大きな利点がないなら、そのまま使い続けましょう。行レベルセキュリティ、略してRLSは、各顧客が自分のレコードだけを見られるようにできる、データベースのルールの仕組みです。

レコードを別の管理画面へ移すだけで、稼働中の顧客ポータルが良くなるわけではありません。価値のある移行には、必要なクライアント動作、運用要件、サービスの制限、記録で確認できる費用の問題など、具体的に示せる解決対象が必要です。

Supabaseの料金を確認する

まず、懸念の原因がプラン、コンピュート、ファイル、通信量、あるいは別のリソースなのかを切り分けます。購入判断に必要な詳しい説明は、Supabaseの料金解説を参照してください。データベースだけの移行では残るサービスも含め、移行後もアプリに必要なサービスを比較しましょう。

Supabaseのストレージ料金を確認する

アップロードファイルが問題なら、データベースエンジンを変えても原因は解消しないかもしれません。バックエンド全体を選び直す前に、保存内容とユーザーのダウンロード方法を点検してください。ストレージだけを変更する場合も、ファイルのアクセスルールとアプリ内のURLを範囲に含め、独立したプロジェクトとして扱います。

Supabaseから移せるものと、作り直すものは何か

Postgresのデータは移しやすい部分ですが、動くアプリは行データだけでは成り立ちません。 Supabaseのバックアップと復元のガイドでは、ロール、スキーマ、データの論理バックアップと復元を説明し、ストレージのオブジェクトとEdge Functionsは別の移行作業として扱っています。

別のPostgresへ移すなら、データベースから着手するのは合理的です。ただし、復元だけで足りると考える前に、対応する拡張機能、バージョン、アプリ固有の依存関係を確認してください。Firestore、Convex、SQLiteへ移す場合は、データ変換とクエリの書き換えを見込む必要があります。

認証にはIDの移行計画が必要です。 Supabaseのセルフホスト環境への復元ガイドには、ユーザーレコードをデータベースダンプに含められる一方、JWTシークレット、プロバイダー設定、リダイレクトURLは個別の設定が必要とあります。このガイドが説明する新しいセルフホストインスタンスへの移行では、既存のトークンは無効になり、ユーザーは再ログインする必要があります。

このガイドはSupabase間の復元を扱っています。別の提供元がすべてのアカウントを取り込めることや、すべてのセッションを維持できることを保証するものではありません。異なる提供元へ移すなら、切り替え日を決める前に、アカウント、ID識別子、ログイン方法をどう対応付けるか確定させましょう。

RLSはエクスポートできますが、その意味は周辺のIDシステムに依存します。 ポリシーはPostgresのオブジェクトであり、本質的に移植できないコードではありません。ただし、SupabaseのRLSドキュメントには、auth.uid()やauth.jwt()などのヘルパーが含まれます。移行先で適切なIDコンテキストを供給するか、ポリシーを調整する必要があります。SQLのインポート成功だけでは、顧客間の分離が保たれている証明にはなりません。

Edge Functionsでは、ランタイムと連携の確認が必要です。 SupabaseのEdge Functionsガイドでは、Deno互換ランタイムで動く移植可能なTypeScript関数と説明されています。移行では、デプロイ、シークレット、ゲートウェイ認証、Supabaseサービスへの呼び出しを扱います。互換性のないランタイムへ移す場合は、コードの変更も必要になり得ます。

本番を移す前に、独立した環境で一連の操作を確認します。ログインし、許可されたレコードを読み、禁止されたアクセスを拒否し、非公開ファイルをアップロードして取得し、重要な業務処理を実行します。移行先でこれらが動くまで、元に戻せる経路を確保してください。

比較対象と評価方法

本記事では、企画で指定された7つの候補と、2026年11月14日に確認した公式製品ページを使っています。評価基準は、置き換える範囲、データベースの継続性、IDとファイルの対応、リアルタイムの挙動、ホスティングの管理権限、有料プランの開始条件、移行責任です。

ログインしての試用、スループット試験、レイテンシーのベンチマークは行っていません。推奨は、文書化された機能に基づくアーキテクチャ上の判断です。重要なのは、ホームページに機能名がいくつ並ぶかではなく、アプリ全体の作業量を抑えて要件を満たせるかどうかです。

汎用のホスティング事業者は、ここでは追加のバックエンド代替候補に含めていません。サーバーを借りるだけでは、認証、ファイル権限、アプリケーションAPIは置き換わらないためです。データベースサービスについては、有用な移行先になる場合に含め、残るサービス移行の作業を明示しています。

避けたい選び方

保守できない重要な本番システムの移行先に、PocketBaseを選ばないでください。 提供元の注意事項は選定基準であり、軽く扱ってよい補足ではありません。

AWSサービスの設定に責任を持つ人がいないなら、Amplifyは避けましょう。 土台が自動生成されても、その背後にあるリソースを理解する必要はなくなりません。

既存のSQLを移すことだけを目的に、FirebaseのFirestore構成やConvexを選ばないでください。 どちらのプログラミングモデルにも選ぶ理由はありますが、SQLの書き換えが不要になるわけではありません。

機能が増えたNeonを、Supabaseとの互換性が保証されたバックエンドと考えないでください。 特にベータ版のリアルタイム機能がアプリに不可欠なら、置き換えるサービスを個別に検証しましょう。

そして、無料枠を追うだけのために、動いているSupabaseアプリを移すのは避けましょう。移行と継続運用の負担を上回る問題を解決できることを、先に確かめる必要があります。

よくある質問

Supabaseは良いサービスですか。それとも避けるべきですか？

Postgresに統合された認証、ファイル、サーバー側関数を求めるなら、Supabaseは適した選択です。アプリや運用の要件が別のモデルを必要とする場合には合いません。既存のSQLとアクセスポリシーがあるなら、移行の前に継続利用を検討する理由になります。

MongoDBの代替には何がありますか？

Supabaseの置き換えとは別の比較になります。アプリのデータをドキュメント指向で扱いたいならFirestoreやConvexを、リレーショナルなSQLへ移したいならPostgresの選択肢を調べてください。どちらも、既存のMongoDBアプリとの互換性を自動的に保証するものではありません。

Supabaseは無料で使えますか？

はい。現在のSupabaseのプランページには、リソースごとの利用枠を持つFreeプランがあります。アプリに合うかは、必要なサービスと利用量によります。無料で利用できることと、本番で無制限に使えることは別です。

SupabaseとFirebaseは同じものですか？

いいえ。どちらも一般的なバックエンド要件をカバーしますが、Supabaseの中心はPostgresです。FirebaseのFirestore構成はドキュメントとクライアント同期を使い、SQL ConnectはPostgreSQLを基盤とする別の構成です。実際に利用するアーキテクチャを比較してください。

Supabaseより良い選択肢はありますか？

特定の要件により合う選択肢はあります。セルフホストできる幅広い構成ならAppwrite、Postgresを軸にした移行ならNeon、GraphQLならNhost、Firestoreのモバイル向けワークフローならFirebase、リアクティブなデータ関数ならConvexです。具体的な要件がなければ、そのまま使い続けるほうがよい場合が多いでしょう。

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

GoogleはFirebase Studioを2027年3月22日に終了すると案内し、既存ワークスペースの利用者をGoogle AI StudioまたはGoogle Antigravityへ案内しています。Studioのお知らせは、それ以上の事業上の理由を示していません。また、Firebaseの主要製品とデプロイ済みアプリには影響しないと明記しています。

Google Firebaseの後継は何ですか？

上記のお知らせには、Firebaseのバックエンド全体を置き換える単一の後継サービスは示されていません。そこで挙げられた移行先は、Firebase Studioという開発環境に関するものです。データベース、ホスティング、アプリケーションモデルが自分の要件により合う場合に限り、別のバックエンドを選びましょう。

Firebaseを使うデメリットは何ですか？

Firestore構成では、既存のSQLアプリに別のデータモデルとクエリモデルが必要になります。本番サービスはGoogleのマネージドインフラに依存し、従量課金ではリソース単位の管理が必要です。また、Sparkにはバックエンド一式に必要なすべてのサービスが含まれているわけではありません。

Firebaseに何が起きているのですか？

Firebase Studioは終了予定ですが、GoogleはFirebaseの主要バックエンド製品には影響しないとしています。ワークスペース製品の終了と、Firestore、Authenticationなどのバックエンドサービスの提供状況を混同しないようにしてください。

移行を決める前に、AI業務ワークフロー監査チェックリストを使い、バックエンドが支えるべきワークフローを整理してください。