Appwrite vs Firebase for Flutter: the honest comparison (features, costs, ops)
Sommaire
At the start of 2026, I was at Flutter Lille, where I saw a talk by Jean-Baptiste Dujardin on Appwrite as a backend for a Flutter app. It made me want to address the topic properly: Is Appwrite a credible alternative to Firebase in 2026? Spoiler: yes… but not for the same reasons.
The goal here is not to "sell" a technology. It's to help you choose based on your product, your team, and your stance on self-hosting.
Comparison "feature by feature"
The idea: separate the core backend (what both provide) from the product pack (where Firebase has a clear lead).
1) Core backend (Auth / DB / Storage / Realtime / Functions / Messaging)
| Feature | Firebase | Appwrite | Notes for production |
|---|---|---|---|
| Auth | Email/password, phone, anonymous, "ready" providers (Google, Facebook, Apple, Twitter/X, GitHub, etc.) (Firebase) | Email/password, SMS, Magic URL, Email OTP, OAuth2 (30+), anonymous, JWT, custom token, MFA (appwrite.io) | Enterprise SSO (SAML/OIDC) on the Firebase side requires upgrading to "Identity Platform". (Firebase) |
| DB | Cloud Firestore (NoSQL, realtime, offline) (Firebase) | Appwrite Databases (collections/documents + permissions) (appwrite.io) | The data model is not identical: think "queries + indexes + rules" before migrating. (Google Cloud Documentation) |
| Realtime | Listeners Firestore / sync (Firebase) | Realtime via WebSocket (channels/events) (appwrite.io) | Appwrite: subscription changes can recreate the connection → to be handled on the state management side. (appwrite.io) |
| Storage | Cloud Storage for Firebase (appwrite.io) | Storage + previews/transformations images (Reddit) | On the self-host side: storage backend + backups = your responsibility. (appwrite.io) |
| Functions | Cloud Functions (managed infra) (Stack Overflow) | Functions with deployments + activation/rollback (appwrite.io) | Be aware of the differences between Appwrite Cloud and self-host (runtimes/quotas). (appwrite.io) |
| Messaging | FCM (push) (Firebase) | Push + Email + SMS unified (appwrite.io) | Firebase covers push very well; Appwrite aims at the "communication suite". (Firebase) |
2) Product feature / growth
| Feature "product" | Firebase | Appwrite |
|---|---|---|
| Analytics | Google Analytics for Firebase (Firebase) | Needs third-party tool |
| Crash reporting | Crashlytics (Firebase) | Needs third-party tool |
| Feature flags / rollouts | Remote Config (feature flags + rollouts) (Firebase) | Needs third-party tool |
| A/B Testing | Firebase A/B Testing (Firebase) | Needs third-party tool |
| Hosting | Firebase Hosting (CDN, SSL, pairing Functions/Cloud Run) (Firebase) | Appwrite Sites (web hosting) (appwrite.io) |
If your app is B2C and you live at the pace of experiments / rollouts / crash fixes, Firebase remains a very hard-to-beat "product monolith".
Auth
Firebase Auth: fast, integrated, and… very "Google friendly"
Firebase Auth offers the classics: email/password, phone (SMS), anonymous, custom auth, and federated providers.
On the providers side, the Firebase docs list flows/entries for Google, Apple, Facebook, Twitter/X, GitHub, and others depending on platforms (e.g., Play Games on Android).
Important point if you do B2B / enterprise: SAML and OIDC exist, but via Firebase Authentication with Identity Platform (upgrade).
Appwrite Auth: more "platform" oriented, more passwordless options
Appwrite highlights: Magic URL, Email OTP, OAuth2 (30+ providers), MFA, JWT, custom token, etc.
If you want to allow a user to sign in via multiple methods (Google + email/password, for example), Appwrite handles "linking" via the concept of Identities.
My take :
- Firebase is excellent for shipping fast, especially if your auth is "standard mobile".
- Appwrite becomes very attractive if you want to push passwordless and keep a platform logic (identities + permissions) without reinventing the wheel.
Data
Firestore has a very concrete strength: offline persistence (cache + sync + last write wins). On the FlutterFire side, you can even configure cache behavior (size, garbage collection).
Appwrite can be realtime, but the "offline-first" approach is generally more "to be built" on the client side (depending on your use-case and sync strategy).
If your app must work in the subway, on a construction site, or in a dead zone: put this point at the top of your checklist.
DX & workflow : local, CI/CD, environments
Firebase : the Emulator Suite is a weapon
The Firebase Local Emulator Suite allows you to test Firestore/Auth/Storage/Functions/etc locally, with a dedicated UI and possible CI integration.
Appwrite : "infra in Docker" + CLI to version the platform
Appwrite is designed to run anywhere Docker runs. And on the workflow side, the CLI allows pull/push of resources (e.g., DB schemas/tables) to sync dev → preprod → prod.
In short: Firebase gives you a great local sandbox. Appwrite gives you a platform that is more naturally "versionable".
Security : Rules vs Permissions (and common pitfalls)
Firebase : Security Rules (powerful, but earned)
Firebase Security Rules secure Firestore/Realtime DB/Storage, with an expressive syntax and conditions. The trap: it's easy to make a rule too permissive, or a rule that is "just enough" and breaks in production at the first edge case.
Appwrite : "whitelist" permissions at the resource level
Appwrite works with a very direct permissions system: you authorize user / team / role to read/write/delete a resource.
It's often easier to reason about… but you can still shoot yourself in the foot with a misplaced any.
Costs
Firebase : pay-as-you-go, so "watch the bill"
Firebase provides a Blaze calculator to estimate costs. And importantly: budget alerts do not stop billing, they alert (important nuance).
Appwrite : Cloud "by plan" + self-host "by infra + ops"
Appwrite Cloud displays its plans and explains the overage logic (additional charges, budget cap). They have also evolved pricing (e.g., moving to a "per project" model, bandwidth adjustments).
Simple rule:
- Firebase charges you finely for usage (and it can rise quickly if you don't manage it).
- Appwrite self-host makes you pay in "ops": VPS, storage, backups, monitoring… and your time.
Self-host Appwrite
If you self-host Appwrite, you regain control… and responsibility.
- Installation: Appwrite targets a Docker install, with fairly standard prerequisites (2 CPU / 4GB RAM / Docker Compose).
- Updates: there is an "updates & migrations" doc and a migration tool.
- Backups: that's your job (with RPO/RTO recommendations + restore tests).
The talk insisted that "it is maintainable" (Docker + migrations). I mostly agree… as long as you take backup/restore seriously from day one.
Migration Firebase → Appwrite
Before migrating, I recommend a simple checklist:
- Auth: providers used, anonymous account, linking, SMS, possible SSO.
- Data: structure, indexes, critical queries, expected "offline behavior".
- Security: Firebase rules vs Appwrite permissions (different mental model).
- Functions: triggers, secrets, rollback, deployment workflow.
- Product pack: analytics, crash reporting, feature flags, A/B tests: what will you replace them with?
Decision matrix
✅ I would choose Firebase if…
- I want a complete product pack (analytics/crash/flags/AB/push/hosting) without assembling 6 services.
- I prioritize time-to-market and infra peace of mind.
- offline-first is central (Firestore does it very well).
✅ I would consider Appwrite if…
- I want open-source + self-host (or Cloud) for control/sovereignty/cost reasons.
- I want an "all-in-one" backend platform for core features, without heavy lock-in.
- I am ready to take backups + upgrades + monitoring seriously.
Conclusion
Firebase and Appwrite are not exactly playing the same match.
- Firebase wins when you want to ship + measure + iterate with a very mature product tooling.
- Appwrite wins when you want to regain control over your backend, without falling back to "I build my own BaaS".
Comments
Loading...