Firebaseの代替: 必要なバックエンドに合わせて選ぶ

置き換える必要があるFirebaseのサービスに応じて、Firebaseの代替を選びましょう。 PostgreSQLベースのバックエンドなら、SupabaseとNhostは候補の短いリストに入ります。Appwriteは統合型のバックエンド製品を提供しています。PocketBaseは小規模なセルフホストのプロジェクトに向いている場合があります。Lizardで自前のAPIをホスティングするのも別のアプローチですが、Firebase Authentication、セキュリティルール、リアルタイムのクライアント動作を自動的に置き換えるわけではありません。

この比較はLizardによるものです。リンク先のドキュメントは2026年9月9日に確認しました。まずアーキテクチャと移行工数から始めて、その後で料金を比較してください。

Firebaseはデータベース以上のものです

アプリはFirestore、Realtime Database、Authentication、Storage、Functions、Hosting、メッセージングをさまざまな組み合わせで使っていることがあります。それぞれに独自のAPIと料金モデルがあります。Firebase の料金では、それらの製品が個別に一覧化されています。

ドキュメントのエクスポートで解決できるのは、移行の一部にすぎません。クライアントは、リアルタイムリスナー、オフライン動作、セキュリティルールに依存している場合があり、新しいシステムではそれらの表現方法が異なることがあります。Authenticationには、単なるusersテーブルだけでなく、IDプロバイダ、アカウント復旧、セッションも含まれます。

アプリケーション内のSDK呼び出しを一覧化してください。それを使って、ベンダーを選ぶ前に置き換え先の契約を定義しましょう。

バックエンドモデル別の候補一覧

機能ラベルを同等の動作と見なす前に、Supabase、Appwrite、Convex、Nhost、Amplifyの一次ドキュメントを確認してください。

PostgreSQLが移行理由である場合

リレーショナルデータベースは、結合、トランザクション、明示的な制約の恩恵を受けるデータに適しています。一方で、Firestore向けに設計されたドキュメントのモデリング方法やクエリ方法は変わります。

まず、アプリが答える必要のあるクエリから始めてください。コレクション、ネストした値、識別子をスキーマに対応付け、そのうえで実データを使って読み取りと書き込みを確認します。すべてのドキュメントを機械的に変換すれば有用なリレーショナルモデルになる、と考えないでください。

自前のAPIを選ぶなら、Managed PostgresがLizard上でデータベースを提供します。アプリケーション側では、引き続きエンドポイントとアクセスチェックを実装する必要があります。自分で構築するよりも統合されたバックエンドAPIが欲しい場合は、SupabaseやNhostのほうが適しているかもしれません。

セルフホストが移行理由である場合

セルフホストでは、デプロイとデータ配置を自分で制御できます。その一方で、バックアップ、アップグレード、監視、復旧が運用計画の一部になります。

PocketBaseは、組み込みSQLiteデータベースにauth、ファイル処理、リアルタイム機能を組み合わせています。公式ドキュメントでは、version 1.0以前は後方互換性が保証されないと警告しており、本番クリティカルなアプリケーションでは慎重な判断を勧めています。この明示された制限を自分のプロジェクトに照らして評価してください。小さなバイナリだからといって、自動的に本番向けの代替になると見なすべきではありません。PocketBase documentation。

どのセルフホストバックエンドでも、依存する前にバックアップからの復元とアップグレード経路をテストしてください。プロセスが正常に起動しただけでは、データ復旧が実証されたことにはなりません。

総合的な料金モデルを比較する

Firestoreの課金には、ドキュメント操作、ストレージ、ネットワーク利用が含まれることがあります。別の製品では、データベースのコンピュート、ユーザー数、function利用量、または基本プランで課金される場合があります。これらの単位は測っているものが異なります。Firestore の課金ドキュメント。

各選択肢について同じワークロードを記録してください。アクティブユーザー、読み取り、書き込み、保存データ量、ファイルダウンロード、function実行、必要な環境を含めます。バックアップやその他の必須機能に必要なプランも加えてください。必要に応じて、Firebase、Supabase、Appwrite、Lizard pricingを使ってください。

データベースのエントリープランとFirebase全体の請求額を比較して、節約額を計算するのは避けてください。開発作業も含める必要があります。クライアントSDKの呼び出しやセキュリティルールの置き換えは、小さな月額ホスティング差額より高くつくことがあります。

権限を検証する移行計画

1. 使用中のFirebase製品、SDK呼び出し、セキュリティルール、IDプロバイダを棚卸しする。
2. 置き換え先のデータモデルと、各ユーザーロールに対するアクセスルールを設計する。
3. テスト用データセットをインポートする。件数、識別子、タイムスタンプ、代表的なアプリケーションクエリを確認する。
4. 匿名ユーザー、通常ユーザー、管理者としてアクセスをテストする。拒否される読み取りと書き込みも含める。
5. 使用している場合は、サインイン、サインアウト、パスワード復旧、ファイルアクセス、リアルタイム更新をテストする。
6. 最終的な書き込み切り替え、クライアントリリース、ロールバックを計画する。古いモバイルまたはブラウザクライアントが引き続き古いAPIを呼び出す可能性がある。

Lizardでは、カスタムバックエンドは必要に応じてManaged Redisを使え、ファイルにはManaged Object Storageを使えます。ストレージのアクセスポリシーは、それらのファイルの機密性に見合っていなければなりません。新しく作成したbucketが非公開だと決めつけないでください。

FAQ

LizardはFirebaseの直接的な代替ですか？ Lizardはバックエンドとデータサービスをホストできます。FirebaseのクライアントAPI、authフロー、セキュリティルールを自動的に提供するわけではありません。そうしたサーバーサイドアプリケーションを動かしたい場合に選んでください。

Firebaseに最も近い代替はどれですか？ どのFirebase製品を使っているかによります。機能数で選ぶのではなく、実際のAPI、auth、ファイルアクセス、リアルタイム動作を比較してください。

Firebase Authenticationを維持したまま、データベースだけ移行できますか？ 既存のIDトークンを検証するバックエンドを設計することはできます。トークン検証と認可は慎重に確認してください。IDを受け入れることは、すべてのレコードへのアクセスを許可することと同じではありません。

PostgreSQLにすれば、すべての従量課金はなくなりますか？ いいえ。ホスト側では引き続き、自身のプランに基づいてコンピュート、ストレージ、トラフィック、その他のサービスに対して課金します。メーターが変わるだけで、ワークロードを見積もる必要は残ります。

最も重要な移行テストは何ですか？ ユーザーがアクセスすべきレコードとファイルに正確にアクセスでき、それ以外にはアクセスできないことを確認することです。データのインポート成功だけでは、権限が正しいことの証明にはなりません。