Firebase vs Supabase en 2026 : Le Vrai Comparatif d'un Dev Indie
Pourquoi ce comparatif existe
Chez Doved Studio, on a utilise Firebase pendant 3 ans. Glean, Kupola, Qibla, les premieres versions de Titan's Grip : tout tournait sur Firebase. Puis on a migre vers Supabase pour les nouveaux projets. Ce n'etait pas une decision ideologique. C'etait une question de couts et de controle.
Ce comparatif n'est pas un benchmark synthetique. C'est un retour d'experience concret, avec des chiffres reels de nos apps en production.
Le resume en 30 secondes
| Critere | Firebase | Supabase | Verdict |
|---|---|---|---|
| Setup initial | 5 min | 10 min | Firebase |
| Base de donnees | NoSQL (Firestore) | PostgreSQL | Supabase |
| Auth | Excellent | Tres bon | Egalite |
| Temps reel | Natif, transparent | Bon (Realtime via websockets) | Firebase |
| Prix a l'echelle | Impredictible | Predictible | Supabase |
| Vendor lock-in | Fort | Faible (Postgres) | Supabase |
| Edge Functions | Cloud Functions (Node) | Deno Edge Functions | Egalite |
| Storage | Cloud Storage | S3-compatible | Egalite |
| SDK Flutter | Mature | Correct | Firebase |
| SDK Swift | Bon | En progres | Firebase |
Base de donnees : NoSQL vs SQL
C'est LA difference fondamentale. Firebase utilise Firestore (NoSQL document store). Supabase utilise PostgreSQL.
Firestore est fantastique pour le prototypage. Tu definis un schema en ecrivant des donnees, pas en creant des tables. Pour un hackathon ou un MVP, c'est imbattable.
Le probleme arrive quand ton app grandit. Chez Titan's Grip, on avait besoin de requetes du type "tous les utilisateurs qui ont fait plus de 10 sessions de boxing ce mois avec un score moyen superieur a 70". En Firestore, cette requete necessite soit une denormalisation massive (dupliquer les donnees), soit plusieurs requetes successives. En PostgreSQL, c'est un SELECT avec un JOIN et un WHERE.
Firestore facture a la lecture. Chaque document lu coute. Une requete qui scanne 1 000 documents pour en retourner 10 coute 1 000 lectures. PostgreSQL ne facture pas a la requete. Tu paies le serveur, pas l'usage.
Notre migration Titan's Grip analytics de Firestore vers Supabase a reduit les couts backend de 340 USD/mois a 25 USD/mois. Meme donnees, meme volume. La difference : on est passe de 4 millions de lectures Firestore par jour a des requetes SQL optimisees sur un Postgres indexe.
Authentification
Firebase Auth est le gold standard. Google, Apple, email/password, phone, anonymous : tout marche out of the box. Le SDK Flutter (firebase_auth) est rock-solid. Le SDK iOS (FirebaseAuth) est mature. Les tokens se rafraichissent automatiquement. C'est le truc que Firebase fait le mieux.
Supabase Auth est tres bon mais un cran en dessous. GoTrue (le service auth de Supabase) gere les memes providers. Le flow fonctionne. Mais le SDK est moins mature. On a eu des edge cases avec le refresh token sur iOS en arriere-plan qui ne se reproduisaient pas sur Firebase.
Pour un dev indie qui veut la tranquillite d'esprit sur l'auth : Firebase. Pour quelqu'un qui veut garder le controle total sur les sessions (Row Level Security integree) : Supabase.
Row Level Security : le game changer
C'est la ou Supabase brille. Row Level Security (RLS) est une fonctionnalite native de PostgreSQL. Tu definis des politiques de securite directement sur les tables :
-- Un utilisateur ne peut lire que ses propres donnees
CREATE POLICY "Users can read own data" ON profiles
FOR SELECT USING (auth.uid() = user_id);
-- Un utilisateur peut modifier uniquement son profil
CREATE POLICY "Users can update own profile" ON profiles
FOR UPDATE USING (auth.uid() = user_id);
Avec Firebase, la securite se fait via des Security Rules declaratives. Le concept est similaire mais l'implementation est moins puissante. Les Security Rules ne supportent pas les JOINs, les sous-requetes, ou les fonctions PostgreSQL. Pour des politiques complexes ("un admin peut voir les donnees de son organisation, un membre ne voit que les siennes"), RLS est nettement plus expressif.
Chez Doved Studio, chaque table a des politiques RLS. Pas d'exception. C'est la regle numero un de notre architecture Supabase.
Prix reels : nos chiffres
Voici ce qu'on paie reellement en production (avril 2026) :
| App | Backend | Utilisateurs actifs/mois | Cout mensuel |
|---|---|---|---|
| Glean (Flutter) | Firebase | 2 400 | 87 USD |
| Titan's Grip (23 apps) | Supabase | 1 800 | 25 USD |
| Kupola (iOS) | Firebase | 800 | 12 USD |
| Magnu Imperiu | SQLite local | 500 | 0 USD |
Firebase Blaze (pay-as-you-go) est impredictible. On a eu un pic a 340 USD sur Titan's Grip quand une feature d'analytics a genere des lectures Firestore non optimisees. Supabase Pro a 25 USD/mois est fixe. Tu sais ce que tu paies.
Le plan gratuit Supabase (500 MB de stockage, 2 projets) est suffisant pour prototyper. Le plan gratuit Firebase (Spark) est plus genereux pour les petits projets mais les couts explosent des que tu depasses les seuils.
Developer Experience
Firebase a une meilleure DX pour le prototypage rapide. Le Firebase CLI, l'emulateur local, la console web, le SDK Flutter : tout est poli. Tu peux aller de zero a une app fonctionnelle avec auth + database + storage en 30 minutes.
Supabase a une meilleure DX pour le developpement serieux. Le SQL editor dans le dashboard, les migrations versionables, l'API auto-generee depuis le schema PostgreSQL, et surtout : la possibilite de faire un pg_dump et de restaurer localement. Essaie de faire ca avec Firestore.
Le CLI Supabase (supabase start, supabase db reset, supabase functions serve) est excellent pour le dev local. Docker requis, mais une fois configure, tu as un environnement local identique a la production.
Quand choisir Firebase
- Ton app est temps reel par nature (chat, collaboration live, jeux multijoueur)
- Tu veux le setup le plus rapide possible pour un MVP
- Tu utilises Flutter et tu veux le SDK le plus mature
- Tu as besoin de Firebase Cloud Messaging (push notifications)
- Tu n'as pas besoin de requetes SQL complexes
- Ton modele de donnees est simple (quelques collections, peu de relations)
Quand choisir Supabase
- Tes donnees sont relationnelles (utilisateurs, commandes, produits, relations N:N)
- Tu veux des couts predictibles
- Tu veux eviter le vendor lock-in (PostgreSQL est universel)
- Tu as besoin de RLS pour une securite fine
- Tu fais de l'analytics ou du reporting (SQL > NoSQL pour l'analytique)
- Tu prevois de grandir et tu veux garder le controle sur ta base de donnees
Notre decision
Les nouveaux projets de Doved Studio partent sur Supabase. Les projets existants sur Firebase restent sur Firebase (la migration n'est pas gratuite en temps). C'est une decision pragmatique, pas un manifeste.
Si tu debutes un projet indie en 2026 et que tu hesites : commence par la question "mes donnees sont-elles relationnelles ?". Si oui : Supabase. Si tes donnees sont des documents libres sans relations fortes : Firebase.
Pour voir nos apps en action, consulte notre portfolio. Pour en savoir plus sur l'IA dans le coaching sportif, lis notre article sur Unity vs Godot.