Supabase : pourquoi nous l'avons choisi à la place de Firebase

Firebase est la référence historique pour les développeurs qui veulent un backend clé en main rapidement. En 2016-2020, c'était difficile de faire mieux pour un prototype ou une application mobile : authentification, base de données temps réel, stockage de fichiers, tout en un, déployé en quelques heures. Mais en 2026, les alternatives ont mûri. Supabase en particulier a changé la donne — et voici pourquoi nous l'utilisons sur tous nos nouveaux projets.

Le constat — Firebase est puissant mais verrouillant#

Firebase est un produit Google. C'est à la fois sa force et son principal risque : vous êtes entièrement dépendant d'une plateforme propriétaire dont les prix, les règles et l'existence dépendent des décisions d'une entreprise tierce.

Ce verrouillage propriétaire (le "vendor lock-in") se manifeste de plusieurs façons concrètes :

La base de données Firestore n'est pas SQL. C'est une base de données NoSQL orientée documents. Pour de nombreux cas d'usage métier — relations entre entités, requêtes complexes, agrégations, jointures — le modèle relationnel est structurellement supérieur. Faire des jointures en Firestore nécessite soit de dénormaliser les données (les dupliquer), soit de faire plusieurs requêtes côté client, soit d'utiliser des Cloud Functions. C'est de la complexité accidentelle.

Les coûts escaladent rapidement à l'échelle. Firebase facture à la lecture, à l'écriture et au stockage. Sur une application avec un trafic modéré mais des lectures fréquentes (tableau de bord, données temps réel), la facture mensuelle peut dépasser les projections initiales de façon significative. La transparence sur les coûts futurs est difficile à établir.

La migration est coûteuse. Quitter Firebase, c'est réécrire toutes les requêtes Firestore, l'authentification, les règles de sécurité et le stockage. Le coût de sortie est élevé par design.

L'open source n'existe pas vraiment. Firebase ne peut pas être auto-hébergé. Vous ne contrôlez pas où vos données sont stockées, comment elles sont sécurisées au niveau infrastructure, ni ce qu'il adviendrait en cas de changement de politique Google.

La solution — Supabase, l'alternative open source qui tient ses promesses#

Supabase se présente comme "l'alternative open source à Firebase". Ce n'est pas un simple slogan marketing — c'est une réalité technique.

PostgreSQL comme fondation#

Supabase repose sur PostgreSQL, la base de données relationnelle open source la plus robuste du marché. Ça signifie concrètement :

• Des jointures, des vues, des fonctions stockées, des triggers — tout ce que SQL offre nativement
• Des requêtes complexes sans contournements
• Une migration vers n'importe quelle autre base PostgreSQL à tout moment, sans réécriture
• Un écosystème d'outils matures : pgAdmin, DBeaver, Metabase pour le reporting

Pour nos logiciels sur mesure — CRM, outils de gestion, plateformes métier — le modèle relationnel n'est pas optionnel. La donnée métier est intrinsèquement relationnelle : un client a plusieurs devis, un devis est lié à des produits, des produits sont associés à des fournisseurs. Firestore force à contourner cette réalité.

Temps réel natif#

Supabase propose un système de souscriptions temps réel basé sur les canaux de PostgreSQL (LISTEN/NOTIFY) et les Replication Slots. Concrètement, votre application frontend peut s'abonner à des changements dans une table et recevoir les mises à jour en temps réel, exactement comme avec Firebase Realtime Database — mais avec la puissance de SQL derrière.

const channel = supabase
  .channel('commandes')
  .on('postgres_changes', {
    event: 'INSERT',
    schema: 'public',
    table: 'commandes'
  }, (payload) => {
    console.log('Nouvelle commande :', payload.new)
  })
  .subscribe()

Authentification complète#

Supabase Auth gère les flux d'authentification courants : email/mot de passe, magic link, OAuth (Google, GitHub, Apple...), SSO SAML pour les entreprises. Le système de Row Level Security (RLS) de PostgreSQL permet de définir des règles d'accès aux données directement au niveau de la base — chaque utilisateur ne voit que ce qu'il est autorisé à voir, sans que cette logique soit dispersée dans le code applicatif.

Storage, Edge Functions et auto-génération d'API#

Supabase propose également :

• Storage : stockage de fichiers avec règles d'accès intégrées, compatible S3
• Edge Functions : fonctions serverless basées sur Deno pour la logique métier côté serveur
• Auto-generated API : une API REST et GraphQL générée automatiquement depuis le schéma PostgreSQL — ce qui accélère considérablement le développement

Notre approche chez Webomax — Pourquoi nous l'adoptons par défaut#

Nous avons fait le choix de Supabase comme backend par défaut pour nos projets applicatifs pour des raisons qui dépassent la technique.

La pérennité du projet client. Supabase est open source (MIT). Même si la société derrière disparaissait demain, le code tourne en auto-hébergé sur n'importe quel VPS. Nos clients sont propriétaires de leur infrastructure et de leurs données.

La lisibilité de la donnée. PostgreSQL est un standard industriel depuis 30 ans. Tout développeur qui reprend un projet Supabase peut lire, comprendre et modifier le schéma de données sans formation spécifique. Ce n'est pas le cas de Firestore, qui nécessite une compréhension du modèle de données spécifique à Firebase.

Le coût prévisible. Supabase Pro commence à 25 $/mois pour un projet avec des ressources généreuses. L'auto-hébergement est une option gratuite. Les coûts ne sont pas indexés sur le nombre de lectures ou d'écritures — ce qui rend les projections financières sur 3 ans beaucoup plus fiables.

L'intégration Next.js. La bibliothèque @supabase/ssr a été conçue pour fonctionner avec l'App Router de Next.js, avec gestion des sessions côté serveur et côté client, ce qui correspond exactement à notre stack standard pour les sites web et applications.

Sur des projets récents, nous avons remplacé des architectures Firebase existantes par Supabase et constaté :

• Une réduction de 40 à 60 % du nombre de requêtes côté client grâce aux jointures SQL
• Une simplification significative de la logique d'autorisation (RLS vs règles Firestore)
• Des économies de 30 à 50 % sur les coûts d'infrastructure à partir de 6 mois d'utilisation

Ce qu'il faut retenir#

Firebase reste pertinent pour des prototypes rapides, des applications mobiles sans requêtes relationnelles complexes, et des équipes déjà formées à l'écosystème Google. Pour tout projet avec une logique métier réelle, des données relationnelles et un horizon de vie supérieur à 2 ans, Supabase est structurellement supérieur.

L'open source, PostgreSQL et l'absence de vendor lock-in ne sont pas des arguments idéologiques : ce sont des garanties de pérennité et de contrôle que nous estimons devoir à nos clients.

Vous avez un projet d'application ou de logiciel sur mesure ? Découvrez notre approche pour les logiciels métier ou contactez-nous pour discuter de votre architecture.