Supabase vs Firebase

Supabase et Firebase promettent la même chose : un backend clé en main, avec authentification, base de données, stockage et temps réel inclus. Ils vous amènent à une application fonctionnelle à une vitesse déconcertante, ce qui explique leur omniprésence dans les discussions autour du « backend-as-a-service ». Mais sous le capot, ils reposent sur des paris très différents, et celui que vous choisissez va façonner l'évolution de votre produit pour les années à venir. Voici comment nous tranchons.

La différence fondamentale : relationnel vs document

Tout le reste en découle. Firestore, la base de données de Firebase, est un store de documents NoSQL. Les données vivent dans des collections de documents imbriqués, et vous les modélisez autour des requêtes exactes que vos écrans effectuent. C'est libérateur au début, douloureux ensuite : tout ce qui est relationnel (jointures, agrégats, reporting, « montre-moi tous les X pour lesquels le Y associé est Z ») exige de la dénormalisation, des écritures en fan-out et une gestion rigoureuse pour maintenir la cohérence des données dupliquées. Vous échangez en substance la simplicité d'écriture et la flexibilité des requêtes contre de la vitesse de lecture sur des patterns d'accès définis à l'avance.

Supabase, c'est PostgreSQL avec une plateforme bien construite autour. Vous disposez d'un vrai schéma relationnel, de SQL, de clés étrangères, de jointures, de transactions, et de toutes les fonctionnalités Postgres — colonnes JSON, recherche plein texte, pgvector pour les embeddings IA, vues matérialisées — dès le premier jour. Pour la plupart des logiciels métier, qui sont par nature relationnels, c'est la fondation la plus pérenne. Notre analyse approfondie de ce sujet se trouve dans PostgreSQL pour les startups.

La version honnête : si vos données sont véritablement de forme documentaire et que vos patterns de requêtes sont simples et connus à l'avance, Firestore convient parfaitement. Dès que vous avez besoin de reporting, de requêtes ad hoc ou de relations complexes — et la plupart des produits y arrivent tôt ou tard — Postgres s'impose sans appel.

Vendor lock-in et portabilité

C'est le point de rupture silencieux pour beaucoup d'équipes, et il mérite bien plus de poids qu'on ne lui en accorde habituellement. Firebase est propriétaire et hébergé par Google ; il n'existe pas de Firestore en dehors de Google. En migrer signifie réécrire l'intégralité de votre couche de données contre une base différente, car rien d'autre ne parle le modèle ou l'API de Firestore.

Supabase est open source et repose uniquement sur Postgres en dessous. Vous pouvez faire un pg_dump de votre base et la déplacer vers n'importe quel hébergeur Postgres dans le monde — AWS RDS, un droplet, votre propre infrastructure —, auto-héberger l'intégralité de la plateforme Supabase, ou connecter directement vos outils SQL existants. Vos données ne sont pas otages de la roadmap ou de la tarification d'un seul fournisseur. Si éviter le vendor lock-in vous importe, la réponse de Supabase est simplement plus solide — et ce n'est pas serré.

Temps réel et authentification

Les deux couvrent les cas courants efficacement, avec des caractères différents :

• Temps réel : les listeners en direct de Firestore sont matures, éprouvés et profondément intégrés — c'était une fonctionnalité de premier plan dès le début. Supabase diffuse les changements Postgres via websockets, ce qui est excellent pour les workloads collaboratifs et de mise à jour en direct classiques, bien que les cas à très haute fréquence et fort fan-out nécessitent davantage de réflexion et de tuning.
• Auth : les deux vous offrent email, fournisseurs OAuth et gestion de sessions en quelques minutes. Le facteur différenciant, c'est que Supabase associe l'authentification à la row-level security de Postgres, de sorte que vos règles d'accès vivent dans la base de données elle-même sous forme de politiques déclaratives — un modèle propre, auditable et faisant office d'unique source de vérité. Firebase utilise un langage de règles de sécurité distinct, en surcouche de Firestore, ce qui fonctionne mais reste séparé de vos données.

SDKs mobile et persistance hors ligne

Un domaine où Firebase garde l'avantage : des SDKs mobiles natifs et matures, avec une persistance hors ligne et une synchronisation robustes intégrées. Si vous développez une application mobile qui doit fonctionner entièrement hors ligne et se réconcilier automatiquement à la reconnexion, la solution offline de Firebase est plus clé en main aujourd'hui. Le support mobile de Supabase est solide et s'améliore, mais la synchronisation offline-first est quelque chose que vous assemblerez plus délibérément. Si le mode mobile hors ligne est une exigence ferme dès maintenant, pesez sérieusement ce point — et consultez React Native vs Flutter pour le volet client de cette décision.

Tarification et comportement à l'échelle

La tarification à l'opération de Firebase (facturée par lecture, écriture et suppression de document) est avantageuse à très petite échelle, mais peut vous surprendre à mesure que l'usage croît — une requête mal structurée lisant des milliers de documents, ou un écran temps réel bavard, se traduit directement par une facture genuinement difficile à anticiper. Supabase facture davantage à la capacité de calcul et au stockage, sur des paliers prévisibles, ce qui tend à être plus lisible à mesure que vous grandissez, car le coût n'évolue pas linéairement avec chaque lecture. Aucun n'est universellement moins cher — modélisez votre pattern réel de lectures/écritures avant de vous engager, car la forme de vos accès dicte lequel reste abordable.

Sur la mise à l'échelle, Firestore autoscale de façon transparente et pratiquement illimitée, mais il y parvient en contraignant la manière dont vous êtes autorisé à interroger vos données — vous ne pouvez pas écrire une requête coûteuse, car le modèle ne vous le permet pas. Postgres vous offre toute la puissance des requêtes avec le compromis classique : vous devrez à terme tuner vos index, ajouter des réplicas de lecture et gérer le connection pooling vous-même (ou vous appuyer sur la couche managée de Supabase, son connection pooler et ses réplicas de lecture pour atténuer cela).

L'expérience développeur et la texture du quotidien

Les deux plateformes se vivent différemment, et cette texture compte sur des mois de développement. Avec Supabase, vous travaillez avec SQL et un schéma relationnel, ce qui signifie que vous pouvez exploiter tout l'univers de connaissances Postgres, l'outillage et les réponses Stack Overflow accumulés depuis des décennies. Les migrations sont des fichiers SQL versionnés, le dashboard vous offre un vrai éditeur de tables et un runner SQL, et les API auto-générées ainsi que les types TypeScript maintiennent le client en phase avec votre schéma. Si votre équipe connaît les bases de données, elle se sentira immédiatement à l'aise.

Avec Firebase, vous pensez en documents et collections, et vous structurez vos données autour des patterns d'accès plutôt qu'autour d'une vérité normalisée. L'outillage est soigné et les SDKs sont excellents, mais vous apprenez le modèle de Google et son langage de règles de sécurité, et la dénormalisation devient une discipline que vous maintenez à la main. Le démarrage est rapide et peut sembler magique pour des applications simples ; les frictions apparaissent plus tard, lorsqu'une exigence de reporting ou une nouvelle relation vous oblige à restructurer des données déjà dupliquées dans le store.

Un bilan réaliste sur la migration

Les équipes demandent souvent « peut-on changer plus tard ? ». La réponse honnête oriente la décision. Migrer vers Supabase depuis un Firestore à structure relationnelle est faisable, mais représente un vrai travail — vous mappez des documents vers des tables, reconstituez des relations qui étaient implicites, et réécrivez la couche de données. Quitter Firebase devient plus difficile à mesure que vous attendez, car de plus en plus de votre application présuppose son modèle et son API. Postgres, étant un standard ouvert, est plus facile à quitter : n'importe quel hébergeur, n'importe quel outil, un simple pg_dump. Cette asymétrie est elle-même un argument — partir d'une fondation plus portable garde vos options futures ouvertes, ce qui est exactement la perspective que nous adoptons pour choisir une stack technique.

Quand choisir Supabase

• Vos données sont relationnelles — ce que sont la plupart des données métier et SaaS.
• Vous avez besoin de reporting, d'analytique, de requêtes ad hoc ou de relations complexes.
• Éviter le vendor lock-in et maintenir la portabilité des données vous importe.
• Vous voulez la recherche IA/vectorielle (pgvector) aux côtés de vos données principales.
• Votre équipe connaît déjà SQL et souhaite en exploiter toute la puissance.

Quand choisir Firebase

• Vos données sont véritablement de forme documentaire avec des patterns de requêtes simples et connus à l'avance.
• Vous êtes déjà profondément intégré dans l'écosystème Google Cloud.
• Vous avez besoin de SDKs mobiles de premier ordre avec synchronisation hors ligne dès maintenant.
• Vous souhaitez un autoscaling maximal sans aucun tuning de requêtes.

Les erreurs fréquentes des équipes

Les décisions que l'on regrette partagent généralement une cause racine — optimiser pour la première semaine plutôt que pour les trois prochaines années :

• Choisir Firestore pour des données clairement relationnelles parce que le démarrage semblait plus rapide, puis se heurter à un mur dès que le reporting, les jointures ou l'analytique apparaissent sur la roadmap.
• Ignorer le modèle de tarification jusqu'à l'arrivée de la facture — construire des écrans gourmands en lectures sur la tarification à l'opération de Firestore et être surpris quand l'usage fait évoluer le coût de façon linéaire.
• Sous-estimer le lock-in jusqu'à ce qu'une replatformisation, une acquisition ou une exigence de conformité impose une migration que rend genuinement douloureuse un store propriétaire.
• Adopter Supabase sans jamais utiliser Postgres — le traiter comme un store de documents et passer à côté de la puissance relationnelle, de la row-level security et de pgvector qui en étaient tout l'intérêt.

Choisissez en fonction de la vraie forme de vos données et de la direction que prend le produit, pas en fonction du quickstart qui semblait le plus fluide.

Le verdict

Notre choix par défaut pour le SaaS est Supabase, et le raisonnement se renforce au fil du temps : données relationnelles, vrai reporting, row-level security, pgvector et absence de lock-in constituent ensemble une fondation dont vous ne ferez pas le tour. Firebase reste une rampe de lancement légitime et plus rapide lorsque vos données sont de forme documentaire, que vous vivez dans l'écosystème Google, ou que vous avez besoin d'une synchronisation mobile hors ligne clé en main dès maintenant.

Si vous avez un doute réel, choisissez l'option relationnelle. Il est bien plus facile d'ignorer les fonctionnalités Postgres dont vous n'avez pas encore besoin que de greffer des relations, des jointures et du reporting sur un store de documents après coup. C'est le même principe que nous appliquons lorsqu'il s'agit de choisir une stack technique en général — posez la fondation qui garde le plus de portes ouvertes.

Une dernière chose mérite d'être dite clairement : le démarrage rapide est un piège s'il vous oriente vers la mauvaise fondation. Les deux outils vous donnent une application fonctionnelle en une après-midi, donc la vitesse d'affichage du premier écran est un mauvais critère de décision — ils sont à peu près équivalents sur ce point. Jugez-les plutôt sur ce avec quoi vous vivrez réellement : la robustesse de votre modèle de données à mesure que le produit gagne en complexité, en dimension relationnelle et en exigences de reporting. Cette question a une réponse claire pour la plupart des logiciels métier, et c'est pourquoi nous penchons par défaut du côté relationnel.

Dans tous les cas, traitez le backend comme une fondation sur laquelle vous construirez pendant des années, pas comme un raccourci de démo. Si vous souhaitez de l'aide pour aligner l'un ou l'autre avec la vraie forme des données de votre produit, parlons-en.