J’ai utilisé Firebase pendant cinq ans, sur une dizaine de projets. Je suis passé à Supabase il y a deux ans, et 80 % de mes nouveaux projets backend partent dessus. Voilà mon retour, sans tomber dans le débat religieux.
Ce que les deux font
Firebase et Supabase sont des plateformes BaaS (Backend as a Service). Vous ne gérez pas de serveur. Vous obtenez une base de données, une authentification, un stockage de fichiers, des fonctions serverless, et une API automatique pour interagir avec tout ça depuis votre app web ou mobile.
Pour un freelance, c’est une économie de temps massive. Plus de configuration de serveur, plus de gestion d’auth manuelle, plus de mise en place d’API. Tout est intégré, tout marche en quelques heures.
Le débat Firebase vs Supabase, c’est le débat entre deux philosophies différentes pour faire la même chose.
La grande différence : SQL contre NoSQL
Firebase utilise Firestore, une base NoSQL (orientée documents). Supabase utilise PostgreSQL, une base SQL classique.
Cette différence est plus importante qu’elle n’en a l’air. Sur des projets simples, les deux marchent. Sur des projets qui grossissent, qui demandent des requêtes complexes, qui ont des relations entre données, PostgreSQL prend l’avantage.
J’ai eu un projet sous Firebase qui devait afficher « tous les messages d’un utilisateur reçus dans les 30 derniers jours, regroupés par expéditeur, avec le nombre de messages non lus, ordonnés par date du dernier message ». En SQL, c’est une requête. En Firestore, c’est un cauchemar : il faut dénormaliser les données, faire trois requêtes, agréger côté client. Un mois de dev gaspillé à cause de ça.
L’écosystème Google contre l’open source
Firebase est un produit Google. Bien intégré, fiable, mais propriétaire. Si vous quittez Firebase, vous repartez de zéro.
Supabase est open source. Vous pouvez l’auto-héberger si vous voulez (j’ai un client qui l’a fait pour des raisons de souveraineté de données). Vous pouvez exporter vos données à tout moment. Vous gardez votre code et votre data sous contrôle.
Pour des clients dans le secteur public ou la santé en France, cette différence est devenue un argument décisif.
Les fonctionnalités qui font la différence
Trois fonctionnalités où Supabase écrase Firebase pour mes usages.
Realtime sur les requêtes SQL. Vous pouvez vous abonner aux changements d’une table avec une simple ligne de code. Sur Firebase, le realtime est natif aussi, mais limité aux structures de documents.
Edge Functions en Deno. Plus modernes que les Cloud Functions Firebase à mes yeux, plus rapides à déployer, mieux intégrées au reste.
Le studio web. L’interface d’admin Supabase est bluffante. Vous voyez vos tables, vous lancez des requêtes SQL, vous voyez les logs, vous configurez l’auth, le tout dans un seul endroit propre.
À l’inverse, Firebase a un avantage que Supabase n’a pas encore complètement comblé : la maturité globale. Sur des cas d’usage très spécifiques (Firebase Cloud Messaging pour les notifs push avancées, Firebase Analytics intégré, Firebase Test Lab pour les tests Android), Firebase reste plus complet.
Le vrai différenciateur en 2026 : Row Level Security
Supabase profite de toute la puissance PostgreSQL, dont Row Level Security (RLS). C’est une fonctionnalité qui permet de définir, au niveau de la base, qui peut lire ou écrire chaque ligne.
Concrètement : vous écrivez une politique qui dit « un utilisateur ne peut voir que ses propres commandes ». Ensuite, peu importe d’où vient la requête, peu importe qui code l’app frontale, la base elle-même refuse l’accès aux données d’autrui.
C’est une sécurité de niveau industriel, qu’il est très compliqué de répliquer correctement avec Firebase. Pour des projets sensibles (santé, RH, données personnelles), c’est un argument fort.
Les limites de Supabase à connaître
Supabase n’est pas parfait. Trois choses à savoir.
Le stockage de fichiers est correct mais moins puissant que Firebase Storage sur certains aspects (CDN intégré, transformation d’images automatique).
Les Edge Functions sont en Deno, ce qui peut surprendre si vous venez du monde Node. La courbe d’apprentissage est faible mais réelle.
L’écosystème de bibliothèques mobiles est moins riche que celui de Firebase. Les SDK existent, ils marchent, mais Firebase a parfois plus d’outils prêts à l’emploi pour des cas spécifiques.
Mon usage en 2026
Pour les nouveaux projets web ou mobile que je commence en 2026, je pars sur Supabase par défaut. Le bilan d’usage des deux dernières années est trop net : développement plus rapide, code plus lisible, plus facile à transmettre à un autre dev, et un coût mensuel souvent inférieur sur des volumes équivalents.
Je continue à utiliser Firebase sur des projets existants en maintenance, sans envie de migrer pour le plaisir de migrer. Quand on a un projet qui marche, on ne le casse pas.
Pour un nouveau projet en 2026, Supabase est mon choix par défaut, sauf besoin spécifique qui justifie Firebase. C’est un changement de paradigme dans mon stack, et je ne suis pas le seul à l’avoir fait.