Appwrite対Firebase（Flutter向け）：正直な比較（機能・コスト・運用）

2026年の年初、私は Flutter Lille にいて、Jean-Baptiste Dujardin による Appwrite を Flutter アプリのバックエンドとして使う という講演を見ました。 それでテーマをきちんと整理したくなりました：Appwrite は 2026 年に Firebase の信頼できる代替になり得るか？ ネタバレ：はい…ですが理由は同じではありません。

ここでの目的は技術を「売る」ことではありません。あなたのプロダクト、チーム、セルフホストに対する考え方に応じて選択を助けることです。

比較 "機能ごとに"

アイデア：コアバックエンド（両者が提供するもの）とプロダクトパッケージ（Firebase が明確に優位な領域）を分離すること。

1) コアバックエンド (Auth / DB / Storage / Realtime / Functions / Messaging)

2) プロダクトパッケージ / グロース

アプリが B2C で、体験改善 / ロールアウト / クラッシュ修正 を重視するなら、Firebase は打ち負かすのが非常に難しい「プロダクトモノリス」です。

認証

Firebase Auth：高速で統合されており…非常に「Google フレンドリー」

Firebase Auth は定番を提供します：メール/パスワード、電話（SMS）、匿名、カスタム認証、そしてフェデレーションプロバイダー。

プロバイダーに関しては、Firebase のドキュメントは Google、Apple、Facebook、Twitter/X、GitHub、およびプラットフォームによっては他（例：Android の Play Games）のフロー/エントリを列挙しています。

B2B / 企業向けの場合の重要点：SAML と OIDC は存在しますが、Firebase Authentication with Identity Platform へのアップグレードが必要です。

Appwrite Auth：より「プラットフォーム寄り」で、より多くの「パスワードレス」オプション

Appwrite は Magic URL、Email OTP、OAuth2（30+プロバイダー）、MFA、JWT、カスタムトークン などを前面に出しています。

ユーザーに複数の方法（例：Google + メール/パスワード）でログインを許可したい場合、Appwrite は Identities の概念を通じて「リンク」を管理します。

私の見解：

• Firebase は迅速にリリースするのに優れており、特に認証が「標準的なモバイル」ケースで強みを発揮します。
• Appwrite はパスワードレスを推進したい場合や、identities + permissions といったプラットフォーム的なロジックを自前で再発明せずに維持したい場合に非常に魅力的です。

データ

Firestore の明確な強みは オフライン永続化（キャッシュ + 同期 + last write wins）です。 FlutterFire 側ではキャッシュの挙動（サイズ、ガベージコレクション）まで設定できます。

Appwrite はリアルタイムにできるものの、「オフラインファースト」アプローチは一般的にクライアント側でより構築が必要になることが多いです（ユースケースと同期戦略による）。

もしアプリが地下鉄や工事現場、電波の届かない地域で動作する必要があるなら、この点を最優先でチェックリストに載せてください。

DX とワークフロー：ローカル、CI/CD、環境

Firebase：Emulator Suite は強力な武器

Firebase Local Emulator Suite により、専用 UI と CI 統合の可能性を備えて Firestore/Auth/Storage/Functions 等をローカルでテストできます。

Appwrite："infra en Docker" + CLI でプラットフォームをバージョン管理

Appwrite は Docker が動く環境であればどこでも動作することを想定しています。 ワークフロー面では、CLI によりリソース（例：DB スキーマ / テーブル）の pull/push が可能で、開発 → プレプロダクション → 本番の同期がしやすくなっています。

要するに：Firebase は素晴らしいローカルサンドボックスを提供し、Appwrite はより自然に「バージョン管理可能な」プラットフォームを提供します。

セキュリティ：Rules vs Permissions（よくある落とし穴）

Firebase：Security Rules（強力だが習得が必要）

Firebase Security Rules は Firestore / Realtime DB / Storage を保護し、表現力豊かな構文と条件を持ちます。 落とし穴は、ルールを緩くしすぎることや、エッジケースで本番が壊れてしまう「ギリギリ」なルールを書いてしまうことが容易だという点です。

Appwrite：リソースレベルの「ホワイトリスト」権限

Appwrite は非常に直接的な権限システムを採用しており、リソースに対して user / team / role に読み書き/削除を許可します。 理解しやすいことが多いですが、any を誤って置くなどしてミスを招く可能性は依然としてあります。

コスト

Firebase：従量課金（pay-as-you-go）、つまり「請求に注意」

Firebase は Blaze 計画向けの電卓を提供してコストを見積もるよう促します。 重要な点：予算アラートは請求自体を止めるわけではなく通知するだけです（ここは重要な差分）。

Appwrite：Cloud は「プラン別」+ セルフホストは「インフラ + 運用」

Appwrite Cloud はプランを表示し、超過に関するロジック（追加料金、予算上限）を説明しています。 価格モデルの変更（例：プロジェクト単位への移行、帯域調整）も行われています。

シンプルなルール：

• Firebase は使用量に応じて細かく課金される（うまく管理しないと急増する可能性あり）。
• Appwrite のセルフホストは「運用コスト」を支払うことになる：VPS、ストレージ、バックアップ、モニタリング…そしてあなたの時間。

Appwrite のセルフホスト

セルフホストで Appwrite を運用するなら、コントロールは取り戻せますが、責任も伴います。

• Installation : Appwrite vise une install Docker, avec des prérequis assez standards (2 CPU / 4GB RAM / Docker Compose).
• Updates : il y a une doc "updates & migrations" et un migration tool.
• Backups : c'est ton job (avec recommandations RPO/RTO + tests de restore).

カンファレンスでは「きちんと保守できる」（Docker + マイグレーション）という点が強調されていました。私も概ね同意です…ただしバックアップ/リストアを初日から真剣に扱う前提で。

Firebase → Appwrite の移行

移行前に、簡単なチェックリストを推奨します：

1. 認証：使用しているプロバイダー、匿名アカウント、リンク、SMS、SSO の有無。
2. データ：構造、インデックス、重要なクエリ、期待する「オフライン動作」。
3. セキュリティ：Firebase のルールと Appwrite の権限（メンタルモデルが異なる）。
4. 関数：トリガー、シークレット、ロールバック、デプロイのワークフロー。
5. プロダクトパッケージ：アナリティクス、クラッシュ報告、機能フラグ、A/B テスト：何で代替するか？

意思決定マトリクス

✅ Firebase を選ぶなら…

• 6つのサービスを組み合わせずに、完全なプロダクトパッケージ（analytics/クラッシュ/フラグ/AB/プッシュ/ホスティング）を望む。
• タイム・トゥ・マーケット とインフラの安心感を重視する。
• オフラインファーストが重要（Firestore が非常に得意）。

✅ Appwrite を検討するなら…

• コントロール/主権性/コストの理由で オープンソース + セルフホスト（または Cloud）を望む。
• コアのバックエンドで重いロックインなしに、オールインワンのプラットフォームを望む。
• バックアップ + アップグレード + 監視 を真剣に扱う覚悟がある。

結論

Firebase と Appwrite は完全に同じ土俵で戦っているわけではありません。

• Firebase は、リリース + 計測 + イテレーション を成熟したプロダクトツールで行いたい場合に有利です。
• Appwrite は、自分のバックエンドを取り戻したい場合や、「自分で BaaS を作る」状況に戻りたくない場合に有利です。