Supabase vs Firebase : le vrai choix backend pour les devs indés

La réponse courte

Si on construit un SaaS classique en 2026, Supabase est le meilleur choix par défaut.

C'est direct, mais c'est ce qu'on pense. La plupart des fondateurs solo n'ont pas besoin d'une base de données documentaire magique. Ils ont besoin d'un backend qu'ils peuvent comprendre à 23h quand un bug remonte et que le problème vient d'une requête, d'une migration ou d'une règle de permissions. Postgres, c'est plus simple à vivre que Firestore dès que l'app n'est plus un prototype.

Firebase n'est pas mauvais. Loin de là. C'est encore le meilleur outil pour aller de zéro à "j'ai un truc qui marche" en un après-midi. Mais ce qui rend Firebase rapide au départ peut devenir une source de friction coûteuse après.

Pricing : une de ces factures est plus facile à comprendre

Le tier gratuit de Supabase donne 500 Mo de base, 1 Go de stockage et 50 000 utilisateurs actifs mensuels. Assez pour valider une idée, lancer une beta et même servir les premiers clients payants. Quand on passe au plan Pro à 25 $/mois, la facture est lisible. On surveille la taille de la base, la bande passante et le stockage, mais on comprend ce qu'on paie avant de payer.

Firebase commence gratuit aussi. C'est un peu le piège. Le plan Spark est généreux pour un prototype. Le problème, c'est quand le prototype commence à avoir du vrai trafic. Firestore facture à l'opération : environ 0,06 $ pour 100 000 lectures, 0,18 $ pour 100 000 écritures, plus la bande passante à 0,12 $/Go. Les Cloud Functions ajoutent leurs propres frais de compute. Une requête mal optimisée, ce n'est pas juste un bug de performance : c'est un bug de facturation.

Quand on est seul, débugger une facture inattendue c'est un travail pénible. On a déjà assez à faire sans ajouter "pourquoi cet écran a déclenché 8 000 lectures ?" sur la liste. Avec Supabase, on peut dépasser la taille de sa base. Avec Firebase, on peut dépasser sur six dimensions à la fois.

Modèle de données : SQL bat le documentaire pour la plupart des SaaS

C'est là que notre avis se durcit.

La plupart des produits deviennent relationnels, que le fondateur l'ait prévu ou non. Les utilisateurs appartiennent à des équipes. Les équipes ont des projets. Les projets ont des factures, des feature flags, des sièges, des events et des réglages. Dès qu'on a besoin de demander "montre-moi ça plus ça plus un count d'ailleurs", SQL devient vital.

Supabase donne ça dès le premier jour, parce que c'est Postgres. Les migrations sont ennuyeuses dans le bon sens du terme. Les ORM comprennent le schéma. Les outils de BI aussi. Si on a besoin de reporting custom plus tard, on n'invente pas un second langage pour obtenir des réponses basiques.

Firestore donne une impression géniale jusqu'au moment où le modèle de données commence à se tordre autour de la base au lieu du produit. On remarque les duplications. Les fan-out writes. Les limites de requêtes. Et soudain, l'app simple a une relation philosophique avec les collections et la dénormalisation.

Auth : les deux sont bons, mais l'architecture diffère

L'authentification, on veut la configurer une fois et l'oublier. Les deux plateformes tiennent cette promesse, mais avec des approches différentes.

Supabase Auth supporte email/password, login social (Google, GitHub, Apple, Discord et d'autres), OTP par téléphone et magic links. Surtout, l'auth est liée directement au Row Level Security de Postgres. Les règles d'accès aux données vivent dans le même système que l'auth. On écrit une policy, elle s'applique partout : appels API, souscriptions temps réel, requêtes directes. Pas de gymnastique middleware.

Firebase Auth couvre un terrain similaire : email, téléphone, providers sociaux, auth anonyme et multi-facteur. L'intégration Google est excellente. Les SDKs mobiles sont plus matures, surtout pour les flux de vérification par téléphone sur Android.

La différence est architecturale. Supabase traite l'auth comme une partie de la couche base de données. Firebase traite l'auth comme un service standalone consommé par les autres produits Firebase. Les deux marchent. Mais si on veut un modèle de permissions unifié, l'approche Supabase est plus propre.

Stockage : des modèles de sécurité différents

Supabase Storage donne un stockage objet compatible S3 avec des policies Row Level Security. On contrôle qui upload, télécharge ou supprime des fichiers avec les mêmes policies Postgres que pour les tables. C'est cohérent et prévisible si on connaît déjà le RLS.

Firebase Cloud Storage marche bien aussi, mais ses règles de sécurité utilisent un langage séparé. Les permissions de stockage sont définies dans un endroit différent, avec une syntaxe différente, des règles Firestore. Deux systèmes de règles pour deux services. C'est gérable, mais c'est plus de surface à maintenir.

Pour un SaaS multi-tenant avec des rôles et des uploads segmentés, l'approche unifiée RLS de Supabase est plus simple à raisonner.

L'argument open source

Celui-ci pèse plus que la plupart des pages de comparatif ne le laissent entendre.

Supabase est open source. Toute la plateforme -- auth, stockage, temps réel, edge functions -- est sur GitHub. On peut auto-héberger l'ensemble sur sa propre infra. Plusieurs équipes le font pour la conformité, le contrôle des coûts ou simplement l'indépendance. Même sans jamais auto-héberger, la base open source signifie que la communauté trouve et corrige les problèmes plus vite, et qu'on peut toujours inspecter ce que la plateforme fait.

Firebase est un produit propriétaire de Google. On ne peut pas l'auto-héberger. On ne peut pas le forker. Si Google change le pricing ou déprécie une feature, les options sont d'accepter ou de migrer. Et Google a un historique de fermeture de produits. Firebase ne va probablement nulle part bientôt, mais l'absence de porte de sortie mérite d'être pesée.

Migration : la porte de sortie compte

C'est une des différences les plus concrètes.

Quitter Supabase, c'est exporter un dump Postgres. On prend son schéma, ses données, ses migrations, et on les déplace vers n'importe quel hébergeur Postgres : AWS RDS, Neon, Railway, un VPS. Les requêtes marchent encore. L'ORM marche encore. Le code de l'application change à peine.

Quitter Firebase, c'est réécrire sa couche d'accès aux données. Le modèle documentaire de Firestore, ses conventions de requêtes, ses patterns SDK -- rien de tout ça ne se transfère vers une base relationnelle. On ne déplace pas juste des données. On réarchitecture la façon dont l'app parle à son backend.

Si le vendor lock-in est un sujet pour vous, cette asymétrie devrait peser lourd dans la décision.

Avec quoi ça s'intègre bien

Supabase se marie naturellement avec la stack web moderne. Next.js, Nuxt, SvelteKit, Remix -- tout marche bien. La lib client JavaScript est propre. Si on utilise TypeScript, Supabase peut auto-générer les types depuis le schéma Postgres, ce qui est un vrai gain au quotidien. Ça joue aussi bien avec Prisma, Drizzle et tout ORM qui parle Postgres.

Firebase se marie mieux avec les stacks mobile-first et les outils Google. Flutter + Firebase, c'est un combo solide. React Native avec Firebase marche mais demande plus de câblage. Sur le web, le SDK Firebase est plus lourd que le client Supabase et le modèle mental est plus opiniâtre.

Si on construit une app Next.js avec une couche API typée, Supabase s'intègre comme s'il avait été conçu pour ce workflow. Parce que c'est à peu près le cas.

Là où Firebase fait encore mieux

Firebase a de vrais atouts, et prétendre le contraire serait malhonnête.

L'expérience mobile est meilleure. Les SDKs client sont matures. La persistance offline est excellente. Les listeners temps réel sont encore plus agréables à utiliser que la plupart des alternatives. Si le produit doit bien fonctionner sur une connexion instable dans le métro, Firebase reprend beaucoup de points.

L'écosystème Google compte aussi. Si l'équipe vit déjà dans Google Cloud, Firebase s'intègre naturellement. On peut passer des fonctionnalités hébergées simples vers le cloud plus large sans changer de fournisseur.

Firebase gagne aussi en largeur de services intégrés. Crashlytics, Analytics, Remote Config, A/B testing, App Distribution -- la console Firebase est un guichet unique pour les équipes mobiles. Supabase ne cherche pas à concurrencer sur ce terrain.

Et surtout : le time to value. Firebase est ridiculement rapide à mettre en route. Ça compte quand l'objectif est de valider une idée, pas d'écrire le backend le plus élégant de sa vie.

Quand choisir Supabase

• Le produit est web-first et clairement relationnel.
• On veut du SQL, des migrations et un outillage qui ne va pas nous coincer plus tard.
• On veut éviter un lock-in profond.
• On veut garder la possibilité d'auto-héberger ou de contrôler son infra plus tard.
• On connaît déjà Postgres et on veut avancer vite sans apprendre une nouvelle religion de base de données.
• On veut que l'auth et le stockage partagent le même système de permissions.
• On utilise Next.js, SvelteKit, Nuxt ou un autre framework web moderne.

Quand choisir Firebase

• Le produit est mobile-first et le comportement offline compte.
• Le temps réel doit être impeccable dès le premier jour.
• On veut le chemin le plus court entre l'idée et l'app qui fonctionne.
• L'équipe est déjà à l'aise avec la stack Google.
• On a besoin des services mobiles Firebase (Crashlytics, Remote Config, Analytics).
• On construit avec Flutter et on veut l'intégration la plus serrée.
• On optimise pour la première version, pas pour l'architecture la plus durable.

Verdict

Supabase est le choix qu'on recommanderait à la plupart des fondateurs indés sans hésiter. Un socle plus durable, une facture plus calme, et un backend qui continue de faire sens à mesure que le produit grossit. La base open source et la porte de sortie Postgres ne sont pas que des arguments idéologiques -- c'est une assurance concrète.

Firebase mérite toujours le respect. Si l'app est massivement mobile et qu'on a besoin des SDKs, du offline et du temps réel tout de suite, c'est un choix qui se défend parfaitement. L'outillage mobile est réellement excellent, et la vitesse de démarrage reste inégalée.

Mais on y va les yeux ouverts. La facilité est réelle. Le lock-in aussi. Et quand la facture arrive, on s'assure de comprendre chaque ligne avant que ça ne devienne un pattern.