Appwrite vs Firebase pour Flutter : le comparatif honnête (features, coûts, ops)
Sommaire
En ce début d'année 2026, j'étais à Flutter Lille, où j'y ai vu une conf de Jean-Baptiste Dujardin sur Appwrite comme backend pour une app Flutter. Ça m'a donné envie de poser le sujet proprement : Appwrite est-il une alternative crédible à Firebase en 2026 ? Spoiler : oui… mais pas pour les mêmes raisons.
L'objectif ici n'est pas de "vendre" une techno. C'est de t'aider à choisir en fonction de ton produit, ton équipe et ton rapport au self-host.
Comparatif "feature par feature"
L'idée : séparer le core backend (ce que les deux font) du pack produit (là où Firebase a une avance nette).
1) Core backend (Auth / DB / Storage / Realtime / Functions / Messaging)
| Feature | Firebase | Appwrite | À savoir en prod |
|---|---|---|---|
| Auth | Email/mdp, téléphone, anonyme, providers "prêts" (Google, Facebook, Apple, Twitter/X, GitHub, etc.) (Firebase) | Email/mdp, SMS, Magic URL, Email OTP, OAuth2 (30+), anonyme, JWT, custom token, MFA (appwrite.io) | SSO entreprise (SAML/OIDC) côté Firebase passe par l'upgrade "Identity Platform". (Firebase) |
| DB | Cloud Firestore (NoSQL, realtime, offline) (Firebase) | Appwrite Databases (collections/documents + permissions) (appwrite.io) | Le modèle de données n'est pas identique : pense "requêtes + index + règles" avant de migrer. (Google Cloud Documentation) |
| Realtime | Listeners Firestore / sync (Firebase) | Realtime via WebSocket (channels/events) (appwrite.io) | Appwrite : les changements d'abonnements peuvent recréer la connexion → à gérer côté state management. (appwrite.io) |
| Storage | Cloud Storage for Firebase (appwrite.io) | Storage + previews/transformations images (Reddit) | Côté self-host : storage backend + backups = ton sujet. (appwrite.io) |
| Functions | Cloud Functions (infra gérée) (Stack Overflow) | Functions avec deployments + activation/rollback (appwrite.io) | Attention aux nuances Appwrite Cloud vs self-host (runtimes/quotas). (appwrite.io) |
| Messaging | FCM (push) (Firebase) | Push + Email + SMS unifiés (appwrite.io) | Firebase couvre très bien le push, Appwrite vise la "suite communication". (Firebase) |
2) Pack produit / growth
| Feature "produit" | Firebase | Appwrite |
|---|---|---|
| Analytics | Google Analytics for Firebase (Firebase) | À compléter via outil tiers |
| Crash reporting | Crashlytics (Firebase) | À compléter via outil tiers |
| Feature flags / rollouts | Remote Config (feature flags + rollouts) (Firebase) | À compléter via outil tiers |
| A/B Testing | Firebase A/B Testing (Firebase) | À compléter via outil tiers |
| Hosting | Firebase Hosting (CDN, SSL, pairing Functions/Cloud Run) (Firebase) | Appwrite Sites (hébergement web) (appwrite.io) |
Si ton app est B2C et que tu vis au rythme des expériences / rollouts / crash fixes, Firebase reste un "monolithe product" très dur à battre.
Auth
Firebase Auth : rapide, intégré, et… très "Google friendly"
Firebase Auth propose les classiques : email/mdp, téléphone (SMS), anonyme, custom auth, et des providers fédérés.
Côté providers, la doc Firebase liste les flows/entrées pour Google, Apple, Facebook, Twitter/X, GitHub, et d'autres selon plateformes (ex : Play Games côté Android).
Point important si tu fais du B2B / entreprise : SAML et OIDC existent, mais via Firebase Authentication with Identity Platform (upgrade).
Appwrite Auth : plus "plateforme", plus d'options "passwordless"
Appwrite met en avant : Magic URL, Email OTP, OAuth2 (30+ providers), MFA, JWT, custom token, etc.
Si tu veux permettre à un utilisateur de se connecter via plusieurs méthodes (Google + email/mdp, par exemple), Appwrite gère le "linking" via le concept d'Identities.
Mon take :
- Firebase est excellent pour ship vite, surtout si ton auth est "standard mobile".
- Appwrite devient très séduisant si tu veux pousser le passwordless et garder une logique plateforme (identities + permissions) sans te réinventer la roue.
Données
Firestore a un point fort très concret : offline persistence (cache + sync + last write wins). Côté FlutterFire, tu peux même configurer le comportement de cache (taille, garbage collection).
Appwrite peut être realtime, mais l'approche "offline-first" est généralement plus "à construire" côté client (selon ton use-case et ta stratégie de synchro).
Si ton app doit fonctionner dans le métro, sur un chantier, ou en zone blanche : mets ce point tout en haut de ta checklist.
DX & workflow : local, CI/CD, environnements
Firebase : l'Emulator Suite est une arme
Le Firebase Local Emulator Suite te permet de tester localement Firestore/Auth/Storage/Functions/etc, avec une UI dédiée et une intégration CI possible.
Appwrite : "infra en Docker" + CLI pour versionner la plateforme
Appwrite est pensé pour tourner partout où Docker tourne. Et côté workflow, la CLI permet de pull/push des ressources (ex : schémas DB/tables) pour synchroniser dev → preprod → prod.
En clair : Firebase te donne une super sandbox locale. Appwrite te donne une plateforme "versionnable" plus naturellement.
Sécurité : Rules vs Permissions (et les pièges classiques)
Firebase : Security Rules (puissantes, mais ça se mérite)
Les Firebase Security Rules sécurisent Firestore/Realtime DB/Storage, avec une syntaxe et des conditions très expressives. Le piège : c'est facile de faire une règle trop permissive, ou une règle "juste assez" qui casse en prod au premier edge case.
Appwrite : permissions "whitelist" au niveau ressource
Appwrite fonctionne avec un système de permissions très direct : tu autorises user / team / role à lire/écrire/supprimer une ressource.
C'est souvent plus simple à raisonner… mais tu peux quand même te tirer une balle dans le pied avec un any mal placé.
Coûts
Firebase : pay-as-you-go, donc "attention à la facture"
Firebase pousse un calculateur Blaze pour estimer les coûts. Et surtout : les alertes budget n'empêchent pas la facturation, elles alertent (nuance importante).
Appwrite : Cloud "par plan" + self-host "par infra + ops"
Appwrite Cloud affiche ses plans et explique la logique de dépassement (charges additionnelles, budget cap). Ils ont aussi fait évoluer le pricing (ex : passage à un modèle "par projet", ajustements de bande passante).
Règle simple :
- Firebase te fait payer l'usage finement (et ça peut monter vite si tu ne pilotes pas).
- Appwrite self-host te fait payer en "ops" : VPS, stockage, backups, monitoring… et ton temps.
Self-host Appwrite
Si tu self-host Appwrite, tu récupères le contrôle… et la responsabilité.
- 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).
La conf insistait sur le fait que "ça se maintient bien" (Docker + migrations). Je suis assez d'accord… tant que tu prends le backup/restore au sérieux dès le jour 1.
Migration Firebase → Appwrite
Avant de migrer, je recommande une checklist simple :
- Auth : providers utilisés, compte anonyme, linking, SMS, SSO éventuel.
- Données : structure, index, requêtes critiques, "offline behavior" attendu.
- Sécurité : règles Firebase vs permissions Appwrite (modèle mental différent).
- Fonctions : triggers, secrets, rollback, workflow de déploiement.
- Pack produit : analytics, crash reporting, feature flags, A/B tests : par quoi tu remplaces ?
Matrice de décision
✅ Je choisirais Firebase si…
- je veux un pack produit complet (analytics/crash/flags/AB/push/hosting) sans assembler 6 services.
- je privilégie le time-to-market et la tranquillité infra.
- l'offline-first est central (Firestore le fait très bien).
✅ Je regarderais Appwrite si…
- je veux open-source + self-host (ou Cloud) pour des raisons de contrôle/souveraineté/coût.
- je veux une plateforme backend "tout-en-un" côté core, sans lock-in lourd.
- je suis prêt à traiter sérieusement backups + upgrades + monitoring.
Conclusion
Firebase et Appwrite ne jouent pas exactement le même match.
- Firebase gagne quand tu veux ship + mesurer + itérer avec un outillage produit hyper mature.
- Appwrite gagne quand tu veux reprendre la main sur ton backend, sans retomber dans "je code mon BaaS maison".
Articles connexes
