Firebase vs Supabase: quel backend choisir ?

Comme d’habitude, voici les conclusions pour ceux qui n’ont pas le temps de toute lire 🚀

Si tu as plus de temps, je t’invite bien évidemment à tout lire, où à te rendre directement à la partie conclusion pour un peu plus de détails.

Introduction

Avant de comparer Firebase et Supabase, posons les bases. Parce que si tu débutes dans le développement mobile, il y a de fortes chances pour que tu te demandes: c’est quoi, exactement, un backend ?

Un backend, c'est quoi ?

Imagine ton application mobile comme un restaurant. Ce que l’utilisateur voit, c’est la salle du restaurant : jolie, accueillante, où tout se passe. C’est ce qu’on appelle le frontend.

Mais derrière, il y a la cuisine : là où on prépare les plats, où on stocke les ingrédients, où on gère les commandes. C’est le backend. L’utilisateur ne le voit jamais, mais sans lui, le restaurant ne peut pas fonctionner.

Concrètement, le backend gère :

• Le stockage des données: tous les profils utilisateurs, les contenus, les paramètres de ton app
• L'authentification: vérifier qui se connecte, gérer les mots de passe, les sessions
• La logique métier: calculer des stats, traiter des paiements, envoyer des notifications
• La synchronisation: faire en sorte que tes données soient à jour sur tous les appareils

Traditionnellement, créer un backend, c’était monter un serveur : louer une machine, installer une base de données, coder des APIs, gérer la sécurité, s’occuper des backups, surveiller les performances… Bref, un boulot à temps plein.

BaaS: Backend-as-a-Service

C’est là qu’interviennent les BaaS (Backend-as-a-Service) comme Firebase et Supabase. L’idée ? Quelqu’un d’autre gère toute la complexité du backend pour toi.

Tu n’as pas besoin de :

• Configurer et maintenir des serveurs
• Gérer la scalabilité (si demain tu passes de 100 à 10 000 utilisateurs)
• Coder des systèmes d'authentification from scratch
• Te préoccuper de la sécurité des données et des backups
• Surveiller les performances et gérer les pannes

À la place, tu utilises des SDKs (des librairies de code) qui te permettent d’accéder à toutes ces fonctionnalités en quelques lignes. C’est plug-and-play.

Pourquoi je me pose la question Firebase vs Supabase

Quand j’ai démarré mes projets (Organizer et Habit Saga), j’ai, je l’avoue, foncé un peu tête baissée vers la première solution que j’ai trouvée. Et Firebase a répondu parfaitement à mes attentes: relativement facile à prendre en main, la référence utilisée partout, beaucoup de docs et de tutos.

Mais au fil des mois, j’ai commencé à me poser des questions.

Les requêtes complexes dans Firestore deviennent vite un casse-tête. Le pricing basé sur l’usage me rend pas mal nerveuse. Et je me demande si je ne suis pas entrain de m’enfermer dans l’écosystème Google sans vraie porte de sortie.

Supabase, de son côté, promet du SQL classique (ce que je connais déjà, ça a un côté rassurant), des prix plus prévisibles, et la possibilité de self-host si besoin.

Mais est-ce vraiment mieux ? Est-ce que ça vaut le coup de migrer ? C’est ce qu’on va décortiquer ensemble.

Tour d'horizon des deux solutions

Firebase: le vétéran de Google

Firebase, c’est le mastodonte du backend-as-a-service. Lancé en 2011 puis racheté par Google en 2014, c’est devenu LA référence pour les développeurs mobile qui ne veulent pas se prendre la tête avec un backend.

L’idée de Firebase, c’est simple : tu te concentres sur ton app, et Google gère toute l’infrastructure. Authentification, base de données temps réel, storage de fichiers, notifications push, analytics, crash reporting… bref, c’est une suite complète d’outils intégrés.

Le gros avantage, c’est que tout est pensé pour fonctionner ensemble. Tu configures l’auth Firebase, et automatiquement ta base de données Firestore peut utiliser ces infos d’authentification pour gérer les permissions. Tu intègres Firebase Analytics, et hop, tu peux cibler tes notifications push selon le comportement utilisateur. C’est un écosystème cohérent et mature.

Côté technologie, Firebase repose sur des bases de données NoSQL : Firestore pour les données structurées et Realtime Database pour le temps réel old school. Si tu viens du monde SQL avec tes belles tables et tes jointures, prépare-toi à un changement de paradigme.

Supabase: le challenger open-source

Supabase, c’est le petit nouveau qui fait du bruit. Lancé en 2020, il se positionne clairement comme l’alternative open-source à Firebase. D’ailleurs, il ne s’en cachent absolument pas, comme le démontre leur tagline: “The open source Firebase alternative”.

La philosophie de Supabase est différente : plutôt que de réinventer la roue, ils utilisent des technologies éprouvées et les assemblent intelligemment. Au cœur de Supabase, il y a PostgreSQL - une vraie base de données relationnelle que tu peux interroger en SQL. Pour l’auth, ils utilisent GoTrue. Pour le storage, ils ont leur propre solution built on top de S3.

Le truc cool avec Supabase, c’est que c’est open-source. Si demain tu n’es pas content de leur hébergement, tu peux self-host l’intégralité de ta stack. Avec Firebase, tu es marié avec Google pour le meilleur et pour le pire.

Différence fondamentale d'approche

La vraie différence entre les deux, c’est la philosophie de la base de données.

Firebase, c’est du NoSQL. Tes données sont organisées en collections et documents, un peu comme du JSON. C’est flexible, c’est rapide pour certaines opérations, mais dès que tu veux faire des requêtes complexes avec des relations entre plusieurs collections, ça devient vite le bordel. Et les jointures ? Oublie. Tu dois soit dénormaliser tes données (dupliquer l’info à plusieurs endroits), soit faire plusieurs requêtes et joindre côté client.

Supabase, c’est du SQL classique avec PostgreSQL. Tables, relations, contraintes d’intégrité, transactions, jointures… tout ce que tu connais déjà si tu as fait du dev backend. C’est plus rigide au départ, mais pour des structures de données complexes avec plein de relations, c’est infiniment plus puissant.

Set up initial et prise en main

Bon, assez de théorie. Mettons les mains dans le cambouis et voyons ce que ça donne concrètement de démarrer un projet avec Firebase puis avec Supabase. Parce que la facilité de setup, c’est quand même un critère important quand tu veux avancer vite et/ou que tu n’as pas beaucoup de temps.

Configuration du projet Firebase

Firebase, c’est pensé pour que tu sois opérationnel rapidement. Le setup se fait en plusieurs étapes, mais Google a bien balisé le chemin.

Étape 1 : Créer le projet dans la console Firebase

Tu vas sur console.firebase.google.com, tu cliques sur “Ajouter un projet”, tu choisis un nom. Firebase te demande si tu veux activer Google Analytics (dis-oui, c’est gratuit et utile). Quelques clics, et ton projet existe.

Étape 2 : Ajouter ton app Flutter

Dans la console Firebase, tu ajoutes une app (iOS et/ou Android). Firebase te génère des fichiers de configuration :

• google-services.json pour Android
• GoogleService-Info.plist pour iOS

Tu télécharges ces fichiers et tu les colles dans ton projet Flutteraux bons endroits (on part toujours du principe que tu codes comme moi en Flutter, mais sinon c’est certainement très similaire), respectivement dans android/app/ et ios/Runner/.

Étape 3 : Installer les packages Flutter

Dans ton pubspec.yaml, tu ajoutes les packages Firebase dont tu as besoin, un petit flutter pub get, et c’est installé.

Étape 4 : Initialiser Firebase dans ton app

Dans ton main.dart, tu initialises Firebase avant de lancer l’app :

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await Firebase.initializeApp();
  runApp(MyApp());
}

Et voilà, techniquement, tu es prêt. Tu peux commencer à utiliser Firebase Auth, Firestore, etc. Le petit piège iOS : Sur iOS, il faut aussi configurer les capabilities dans Xcode (Push Notifications, Background Modes, etc.) et parfois jouer avec les certificates Apple.

Configuration du projet Supabase

Supabase, c’est un setup différent, plus orienté backend traditionnel. Mais eux aussi ont fait des efforts pour simplifier le process.

Étape 1 : Créer le projet sur Supabase

Tu vas sur supabase.com, tu créés un compte (ou tu te connectes avec GitHub), et tu crées un nouveau projet. Tu choisis un nom, un mot de passe pour ta base de données, et une région (prends celle la plus proche de tes utilisateurs).

Supabase met environ 2 minutes à provisionner ton projet. Pendant ce temps, il crée ta base PostgreSQL, configure l’auth, le storage, génère les APIs…

Étape 2 : Récupérer tes credentials

Une fois le projet créé, tu vas dans Settings > API. Tu y trouves deux infos cruciales :

• L'URL du projet (genre https://xxxxx.supabase.co)
• La clé API anonyme (anon key) pour accéder aux APIs depuis ton app

Tu notes ça précieusement (ou mieux, tu les mets dans un fichier .env que tu ne commit surtout pas).

Étape 3 : Installer le package Flutter

Dans ton pubspec.yaml, tu rajoutes le package supabase_flutter. Un seul package pour tout (auth, database, storage, realtime). C’est plus simple que Firebase qui a un package par fonctionnalité.

Étape 4 : Initialiser Supabase dans ton app

Dans ton main.dart :

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  
  await Supabase.initialize(
    url: 'https://ton-projet.supabase.co',
    anonKey: 'ta-cle-anon-super-longue',
  );
  
  runApp(MyApp());
}

Et c’est tout. Pas de fichiers de config à télécharger, pas de différence iOS/Android. Juste ton URL et ta clé.

Premier contact : ce qui change

Firebase te force à penser “mobile first”. Tout est pensé pour des apps mobiles qui appellent directement la base de données. C’est intuitif si tu viens de ce monde-là.

Supabase te met dans une logique plus “web/backend”. Tu as une vraie base de données PostgreSQL que tu peux interroger en SQL directement depuis l’interface. C’est plus flexible, mais ça demande de connaître un minimum SQL.

Authentification

L’authentification, c’est la porte d’entrée de ton app. Si ça bug, tes utilisateurs ne vont même pas passer la première étape. Alors voyons comment Firebase et Supabase gèrent ça en pratique.

Firebase authentification

Firebase Auth, c’est vraiment son point fort. C’est simple, c’est robuste, et ça marche du premier coup (ou presque).

Les points forts

• Les erreurs sont bien gérées et documentées
• La vérification d'email est intégrée
• Tu peux forcer la mise à jour du mot de passe
• La gestion des sessions est automatique (tokens refresh, etc.)
• Intégration parfaite avec Firestore pour les règles de sécurité

Les points faibles

• La personnalisation des emails est limités via des templates pré-définis
• Pas de contrôle sur les règles de validation du mot de passe (Firebase impose son minimum)
• Si tu veux ajouter des données custom au profil utilisateur, tu dois les stocker dans Firestore à côté

Supabase authentification

Côté Supabase, l’authentification est basée sur GoTrue (un système d’auth open-source). C’est très bien fait, et étonnamment similaire à Firebase dans l’utilisation.

Les points forts

• Customisation complète des emails (templates HTML)
• Règles de mot de passe configurables dans les settings
• Tu peux stocker des métadonnées custom directement dans le profil auth, pas besoin d'une table séparée
• L'auth est automatiquement liée à PostgreSQL via Row Level Security

Les points faibles

• Les messages d'erreur sont moins structurés que Firebase
• Moins de ressources communautaires si tu bloques

Providers disponibles

Bon soyons francs, personne n’a encore envie de créer un énième compte avec mot de passe. Donc vraiment, ajouter la possibilité de te connecter à ton app via des providers externes, c’est une nécessité.

Les plus connus, à savoir Google, Apple, et Facebook, sont tous supportés par Firebase et Supabase. Et tu as encore d’autres options si tu le souhaites.

Mention spéciale: tu es obligé d’ajouter le sign-in with Apple du moment où tu ajoutes un quelconque provider externe. C’est pas une obligation technique, mais juste une règle de l’App Store.

Si ça t’intéresse, je pourrai te faire un tuto complet sur la mise en place du provider Google, qui nécessite de configurer un OAuth dans la Google Cloud Console. J’ai franchement galéré la première fois… Et pourquoi pas également sur la mise en place du provider Apple, qui lui nécessite de créer un ServiceID dans le portail développeur Apple. Néanmoins, ces deux passages obligatoires n’ont rien à voir avec le backend et sont nécessaires si tu implémentes le provider Google/Apple sur Firebase comme sur Supabase, donc passons.

Base de donneés

Bon, on arrive au cœur du sujet : la base de données. C’est là que Firebase et Supabase divergent vraiment, et c’est aussi là que ton choix va avoir le plus d’impact sur ton quotidien de dev.

Firestore vs PostgreSQL : philosophies opposées

Firestore, c’est du NoSQL. Tes données sont organisées en collections (comme des dossiers) contenant des documents (comme des fichiers JSON). Pas de schéma fixe, pas de relations explicites, juste des objets imbriqués.

Exemple : tu peux créer une collection users avec des documents qui ressemblent à ça :

{
  "uid": "abc123",
  "name": "Lydia",
  "email": "lydia@example.com",
  "premium": true
}

Maintenant allons plus loin. Prends mon app Organizer. Chaque utilisateur peut créer des tâches. Alors, deux options: soit je les imbriques directement dans le document user (mais ça devient vite le bordel), soit je crée une collection séparée tasks avec un champ userId pour faire le lien (c’est ce que j’ai fait).

PostgreSQL avec Supabase, c’est du SQL classique. Tes données sont organisées en tables avec des colonnes typées et des relations explicites.

Reprenons le même exemple, d’abord pour l’utilisateur. On crée une table users :

CREATE TABLE users (
  id UUID PRIMARY KEY,
  name TEXT NOT NULL,
  email TEXT UNIQUE NOT NULL,
  premium BOOLEAN DEFAULT false
);

Et une table tasks reliée :

CREATE TABLE tasks (
  id UUID PRIMARY KEY,
  user_id UUID REFERENCES users(id),
  title TEXT NOT NULL,
  completed BOOLEAN DEFAULT false
);

La relation entre tasks et users est explicite via la foreign key UUID de l’user_id.

Requêtes simples : lecture/écriture

Je trouve que regarder directement quelques requêtes aide à avoir une vue un peu plus directe et “intuitive” de ce qui nous attend. Alors voici quelques exemples.

Firestore

Créer un document :

await FirebaseFirestore.instance.collection('tasks').add({
  'userId': currentUser.uid,
  'title': 'Acheter du lait',
  'completed': false,
  'createdAt': FieldValue.serverTimestamp(),
});

Lire des documents :

final snapshot = await FirebaseFirestore.instance
    .collection('tasks')
    .where('userId', isEqualTo: currentUser.uid)
    .get();

final tasks = snapshot.docs.map((doc) => doc.data()).toList();

Mettre à jour :

await FirebaseFirestore.instance
    .collection('tasks')
    .doc(taskId)
    .update({'completed': true});

C’est intuitif, ça ressemble à manipuler des objets JSON. Par contre, chaque opération (read, write) te coûte de l’argent. On y reviendra dans le pricing.

Supabase

Créer une ligne :

await Supabase.instance.client.from('tasks').insert({
  'user_id': currentUser.id,
  'title': 'Acheter du lait',
  'completed': false,
});

Lire des lignes :

final response = await Supabase.instance.client
    .from('tasks')
    .select()
    .eq('user_id', currentUser.id);
final tasks = response as List<dynamic>;

Mettre à jour :

await Supabase.instance.client
    .from('tasks')
    .update({'completed': true})
    .eq('id', taskId);

C’est aussi simple que Firestore, mais avec une syntaxe qui rappelle SQL (.select(), .eq(), .update()). Si tu connais SQL, tu te sens tout de suite à l’aise.

Bon honnêtement, les deux restent clairement accessibles.

Requêtes complexes : filtres, jointures, agrégations

Augmentons la complexité, histoire de voir une différence.

Firestore

Imaginons que tu veux récupérer toutes les tâches d’un utilisateur qui sont non complétées et créées après une certaine date.

final snapshot = await FirebaseFirestore.instance
    .collection('tasks')
    .where('userId', isEqualTo: currentUser.uid)
    .where('completed', isEqualTo: false)
    .where('createdAt', isGreaterThan: lastWeek)
    .get();

Ça marche… mais seulement si tu as créé un index composite dans la console Firebase. Sinon, erreur. Et ces index, tu dois les créer manuellement pour chaque combinaison de filtres que tu veux utiliser.

Maintenant, imagine que tu veux faire une jointure. Genre récupérer toutes les tâches avec les infos de l’utilisateur qui les a créées. Impossible en une requête. Tu dois faire :

// 1. Récupérer les tâches
final tasksSnapshot = await FirebaseFirestore.instance
    .collection('tasks')
    .get();

// 2. Pour chaque tâche, récupérer l'utilisateur
for (var taskDoc in tasksSnapshot.docs) {
  final userId = taskDoc.data()['userId'];
  final userDoc = await FirebaseFirestore.instance
      .collection('users')
      .doc(userId)
      .get();
  // Joindre manuellement côté client
}

C’est lent, c’est moche, et ça te coûte plein de lectures. La solution ? Dénormaliser : dupliquer les infos de l’utilisateur directement dans chaque document task. Mais maintenant, si l’utilisateur change de nom, tu dois mettre à jour toutes ses tâches… Et puis la dénormalisation, on essaie d’éviter, ou a minima de limiter.

Et les agrégations (compter, faire des sommes, des moyennes) ? Firestore n’en a presque pas. Tu dois tout ramener côté client et calculer toi-même. Si tu as 10 000 tâches, tu télécharges les 10 000 juste pour en compter quelques-unes.

Supabase

Avec PostgreSQL, tout devient simple. Jointure ? Facile :

final response = await Supabase.instance.client
    .from('tasks')
    .select('*, users(*)')  // Récupère la task ET l'utilisateur
    .eq('user_id', currentUser.id);

Agrégation ? No problem :

final response = await Supabase.instance.client
    .from('tasks')
    .select('id', const FetchOptions(count: CountOption.exact))
    .eq('completed', false);

final count = response.count;  // Nombre de tâches non complétées

Tu peux même faire des requêtes SQL complexes directement :

final response = await Supabase.instance.client.rpc('get_user_stats', 
  params: {'user_id': currentUser.id}
);

Où get_user_stats est une fonction SQL que tu crées dans Supabase :

CREATE FUNCTION get_user_stats(user_id UUID)
RETURNS TABLE(total_tasks INT, completed_tasks INT, completion_rate FLOAT)
AS $$
  SELECT 
    COUNT(*) as total_tasks,
    SUM(CASE WHEN completed THEN 1 ELSE 0 END) as completed_tasks,
    AVG(CASE WHEN completed THEN 1.0 ELSE 0.0 END) as completion_rate
  FROM tasks
  WHERE tasks.user_id = $1;
$$ LANGUAGE SQL;

Enfaite le terrain de jeu est beaucoup plus vaste.

Verdict sur les requêtes complexes : Supabase gagne haut la main. Si ton app a des besoins simples (CRUD basique), Firestore fait le job. Mais dès que tu veux des relations, des jointures, des stats… PostgreSQL n’a pas de concurrence.

Temps réel et synchronisation

Le temps réel, c’est quand ta base de données te notifie instantanément dès qu’une donnée change. Super pratique pour des apps collaboratives, des chats, ou juste pour rafraîchir l’UI sans recharger.

Firestore

Le temps réel, c’est dans son ADN. C’était même sa feature principale à la base.

FirebaseFirestore.instance
    .collection('tasks')
    .where('userId', isEqualTo: currentUser.uid)
    .snapshots()
    .listen((snapshot) {
      // Cette fonction est appelée à chaque changement
      final tasks = snapshot.docs.map((doc) => doc.data()).toList();
      updateUI(tasks);
    });

C’est fluide, c’est instantané, ça marche impeccablement. Par contre, attention : chaque fois que tu écoutes un snapshot, tu paies pour chaque document lu, même si c’est juste une mise à jour. Si tu as 100 tâches et qu’une seule change, tu paies quand même pour 100 lectures.

Supabase

Supabase a ajouté le temps réel avec PostgreSQL (via des extensions comme pg_notify). C’est plus récent, mais ça marche bien.

final subscription = Supabase.instance.client
    .from('tasks')
    .stream(primaryKey: ['id'])
    .eq('user_id', currentUser.id)
    .listen((data) {
      // Appelé à chaque changement
      updateUI(data);
    });

Le truc cool : Supabase te dit quel type de changement a eu lieu (INSERT, UPDATE, DELETE). Avec Firestore, tu dois déduire ça toi-même en comparant les snapshots.

Par contre, le temps réel de Supabase est encore un peu moins mature que Firestore. Parfois il y a des petits délais, et la reconnexion après une perte de réseau n’est pas toujours aussi smooth.

Stockage de fichiers

Au-delà des données structurées, tu as souvent besoin de stocker des fichiers : photos de profil, documents, images uploadées par les utilisateurs. Les deux plateformes proposent une solution de storage, mais avec des approches différentes.

Firebase Storage

Firebase Storage, c’est du stockage de fichiers basé sur Google Cloud Storage. C’est robuste, c’est rapide, et ça s’intègre parfaitement avec le reste de l’écosystème Firebase.

Le truc, c’est que Firebase Storage est assez basique. Tu peux upload, download, delete, et c’est à peu près tout.

Pas de redimensionnement automatique d’images. Si un utilisateur upload une photo de 10 MB, elle reste à 10 MB. Tu dois gérer ça côté client ou utiliser Firebase Cloud Functions (qui coûtent plus cher).

Pas de transformation d’images à la volée. Tu veux des thumbnails ? Tu dois les créer et les stocker manuellement. Tu veux servir l’image en webp plutôt qu’en jpg ? Pareil, à faire toi-même.

La gestion des métadonnées est limitée. Tu peux définir le content-type, des custom metadata, mais c’est assez basique. Et niveau pricing, Firebase Storage te facture pour :

• Le stockage (Go/mois)
• Le bandwidth de download (Go téléchargés)
• Les opérations (nombre d'uploads, downloads, deletes)

Si ton app devient populaire et que les users téléchargent beaucoup d’images, la facture peut grimper vite.

Supabase Storage

Supabase Storage est built on top de S3-compatible storage, mais avec des features modernes en plus. C’est assez similaire à Firebase. La syntaxe change un peu, mais le concept est le même.

Par contre tu peux cette fois faire des transformation d’images à la volée. Supabase génère automatiquement le thumbnail et le met en cache. Pas besoin de stocker plusieurs versions de l’image, c’est géré pour toi.

Avec Firebase, tout est dans un seul grand bucket. Avec Supabase, tu crées des buckets séparés (avatars, documents, images_posts, etc.). C’est plus organisé et tu peux définir des règles de sécurité différentes par bucket.

Par contre, c’est plus récent que Firebase Storage, donc l’écosystème est moins mature. Moins de tutos, moins de retours d’expérience.

Gestion des permissions

La sécurité du storage, c’est critique. Tu ne veux pas que n’importe qui puisse télécharger les photos privées de tes utilisateurs.

Firebase Storage Security Rules

Avec Firebase, tu définis des règles de sécurité basées sur l’authentification. C’est plutôt robuste. Tu peux vérifier l’auth, la taille du fichier, le content-type, et même faire des requêtes à Firestore pour vérifier des permissions complexes.

Par contre, debugger ces règles, c’est parfois un enfer. Firebase a un simulateur dans la console, mais c’est pas toujours évident de comprendre pourquoi une règle bloque.

Supabase Storage Policies (RLS)

Supabase utilise les Row Level Security policies de PostgreSQL, mais appliquées au storage.

C’est du SQL, donc si tu es à l’aise avec, c’est très clair. Et tu as accès à toute la puissance de PostgreSQL pour définir des règles complexes basées sur des données dans d’autres tables.

L’avantage de Supabase, c’est que les permissions du storage et de la database utilisent le même système (RLS). Une fois que tu as compris, tu appliques la même logique partout.

En résumé sur le storage

Firebase Storage fait le job pour du stockage basique, mais manque de features modernes (ça peut quand même largement suffir suivant le type d’applications que tu construis). Supabase Storage est plus moderne avec les transformations à la volée et une meilleure organisation (buckets), mais c’est plus récent donc moins de retours d’expérience. Pour les permissions, les deux sont puissants, juste avec des approches différentes.

Pricing : le nerf de la guerre

Bon, on arrive au sujet qui personnellement, m’aide souvent à faire mon choix: le princing.

Tarifs Firebase

Firebase fonctionne sur un modèle pay-as-you-go : tu paies ce que tu consommes. Ça semble fair au début, mais ça peut vite devenir stressant parce que tu ne sais jamais exactement combien tu vas payer.

Avec le plan gratuit (Spark), tu as:

• Firestore : 50 000 lectures/jour, 20 000 écritures/jour, 1 GB de stockage
• Firebase Auth : Illimité (c'est gratuit !)
• Storage : 5 GB de stockage, 1 GB/jour de download
• Cloud Functions : Pas disponible sur le plan gratuit

C'est parfait pour démarrer ou pour un side project avec peu d'utilisateurs. Mais dès que tu dépasses ces quotas, tu passes automatiquement au plan payant.

Avec le plan payant (Blaze), les tarifs deviennent:

Firestore:
• Lectures : 0,036 $ / 100 000 lectures
• Écritures : 0,108 $ / 100 000 écritures
• Suppressions : 0,012 $ / 100 000 suppressions
• Stockage : 0,18 $ / GB / mois

Firebase Storage :
• Stockage : 0,026 $ / GB / mois
• Download : 0,12 $ / GB
• Upload : gratuit

Cloud Functions :
• 2 millions d'invocations gratuites, puis 0,40 $ / million
• Temps de calcul facturé selon les ressources utilisées

Le piège, c’est que chaque opération compte. Tu écoutes un snapshot Firestore en temps réel avec 100 documents ? Chaque fois qu’un document change, Firebase te facture 100 lectures (tous les documents, pas juste celui qui a changé).

Tarifs Supabase

Supabase fonctionne sur un modèle à paliers fixes avec des quotas. C’est plus prévisible, mais moins flexible. Avec le plan gratuit (Free), tu as accès à:

• 500 MB de database
• 1 GB de file storage
• 2 GB de bandwidth / mois
• 50 000 monthly active users
• Projets mis en pause après 7 jours d'inactivité (relancés automatiquement à l'utilisation)

C’est généreux pour démarrer. Le truc des projets mis en pause peut être vraiment pénible pour une app en prod, mais pour tester ou un petit side project, c’est top.

Avec le plan Pro (25 $ / mois), tu as accès à:

• 8 GB de database
• 100 GB de file storage
• 250 GB de bandwidth / mois
• 100 000 monthly active users
• Pas de mise en pause
• Support email
• Daily backups (7 jours de rétention)

Et au-delà, tu paies des add-ons :

• Database : 0,125 $ / GB supplémentaire / mois
• Storage : 0,021 $ / GB supplémentaire / mois
• Bandwidth : 0,09 $ / GB supplémentaire

Et sinon tu as encore le plan Team (599 $ / mois) pour les grosses apps qui ont besoin de plus de ressources, de meilleurs SLAs, et de support prioritaire (on se souhaite d’arriver un jour à ça n’est-ce pas !).

Où ça peut exploser

Firebase : les pièges à éviter

Tu l’as compris, avec Firebase, tu paies selon l’utilisation. Imagine toujours tes deux collections users et tasks. Piège numéro 1: les snapshots en temps réel mal optimisés

// DANGEREUX : écoute toutes les tâches en temps réel
FirebaseFirestore.instance
    .collection('tasks')
    .snapshots()
    .listen((snapshot) {
      // Tu paies pour TOUTES les tâches à CHAQUE changement
    });

// BON : limite et filtre
FirebaseFirestore.instance
    .collection('tasks')
    .where('userId', isEqualTo: currentUser.uid)
    .where('completed', isEqualTo: false)
    .limit(50)
    .snapshots()
    .listen((snapshot) {
      // Tu paies seulement pour 50 documents max
    });

Piège numéro 2: les downloads d’images non optimisées. Si tu ne redimensionnes pas les images, un user qui upload une photo de 10 MB et 1 000 personnes qui la voient = 10 GB de bandwidth = ~1,20 $. Multiplie ça par des milliers d’images, et bonjour la facture. Solution : utilise Firebase Extensions (Image Resizing) ou redimensionne côté client avant l’upload.

Piège numéro 3: les requêtes inutiles. Enfaite il faut un peu switcher de point de vue, laisser un peu son côté purement dev et basculer du côté entrepreneur: on épure, on simplifie là où c’est possible, et on ne lance pas des requêtes à tout va juste parce que c’est possible technologiquement.

Supabase : les pièges à éviter

Bon côté Supabase, le pricing est beaucoup plus prévisible, mais voici quand même quelques pièges à éviter.

D’abord, Le bandwidth qui explose Si ton app sert beaucoup d’images ou de vidéos, ça peut aller très vite. 250 GB inclus dans le plan Pro, ça peut s’envoler comme de rien. Solution : utilise un CDN devant Supabase Storage, ou compress tes images avec les transformations Supabase.

Piège numéro 2: la database qui grossit trop vite. 8 GB de database dans le plan Pro, ça semble beaucoup, mais si tu stockes des logs, des analytics, ou des données non nettoyées, ça se remplit vite. Solution : mets en place des politiques de rétention (supprimer les vieux logs automatiquement avec des CRON jobs Postgres).

Et pour finir: oublier de passer au plan Pro en prod. Le plan gratuit met ton projet en pause après 7 jours d’inactivité. Imagine que ton app soit down parce que le projet Supabase s’est mis en pause… Pas ouf pour ta réputation. Solution : passe au plan Pro dès que tu lances en prod, même avec peu d’users. 25 $/mois, c’est le prix de la tranquillité.

Mon verdict pricing

• Pour démarrer (< 1K users) : Firebase est moins cher si tu optimises bien, mais Supabase est plus prévisible.
• Pour scaler (10K - 100K users) : Supabase devient nettement moins cher.
• Pour les grosses apps (> 100K users) : ça dépend vraiment de ton usage (lectures/écritures, storage, bandwidth), mais généralement Supabase reste plus avantageux.

Le vrai avantage de Firebase : tu paies vraiment ce que tu utilises, donc si ton app a peu de trafic, c’est quasi gratuit.

Le vrai avantage de Supabase : le prix est prévisible, tu peux budgéter sans stress.

Conclusion : lequel choisir en 2026 ?

Alors, après ce tour d’horizon complet, Firebase ou Supabase ? Bon comme souvent, il n’y a pas de réponse universelle. Ça dépend vraiment de ton contexte, de tes compétences, et de ce que tu veux construire.

Quand choisir Firebase

Tu démarres dans le dev mobile et tu veux du plug-and-play. Firebase, c’est la solution “ça marche out of the box”. La doc est partout, les tutos YouTube foisonnent, et si tu bloques, il y a 99% de chances que quelqu’un ait déjà eu ton problème sur Stack Overflow. Pour un premier projet, cette tranquillité d’esprit vaut de l’or.

Ton app a des besoins simples en base de données. Si tu fais du CRUD basique (créer, lire, modifier, supprimer) sans relations complexes entre tes données, Firestore est parfait. Une app de notes, un tracker d’habitudes, une todo list… Firebase fait ça les yeux fermés.

Le temps réel est critique pour ton app. Si tu développes un chat, une app collaborative en temps réel, ou n’importe quoi où la synchronisation instantanée est essentielle, Firebase est clairement plus mature sur cet aspect. Firestore snapshots, c’est du béton.

Tu veux un écosystème tout intégré. Firebase, c’est pas juste une base de données. C’est aussi Analytics, Crashlytics, Performance Monitoring, A/B Testing, Remote Config, Cloud Messaging… Tout est pensé pour fonctionner ensemble. Si tu veux une suite complète sans réfléchir, Firebase est ton ami.

Tu as un budget très limité au début. Avec Firebase, tant que tu as peu d’utilisateurs, tu paies presque rien (voire rien si tu restes dans les quotas gratuits). C’est parfait pour valider une idée sans investir. Par contre, attention à bien optimiser pour éviter que la facture explose si tu décollés.

Tu développes pour Google Home, Android Auto, ou l’écosystème Google. Si ton app s’intègre profondément avec les services Google, Firebase est le choix évident. L’intégration est native et tout fonctionne en harmonie.

Quand choisir Supabase

Tu viens du monde backend/web et tu connais SQL. Si tu as déjà fait du PostgreSQL, du MySQL, ou n’importe quelle base relationnelle, Supabase sera immédiatement familier. Tu retrouves tes jointures, tes transactions, tes triggers… Pas besoin de réapprendre un nouveau paradigme NoSQL.

Ton app a des besoins complexes en données. Dès que tu as des relations entre entités (users ↔ posts ↔ comments ↔ likes), des agrégations (stats, dashboards), ou des requêtes complexes, PostgreSQL explose Firestore. Tu peux faire en une seule requête SQL ce qui demanderait 10 requêtes et du code client avec Firestore.

Tu veux un pricing prévisible. 25 $/mois avec Supabase, tu sais exactement ce que tu paies. Pas de surprise en fin de mois. Pour quelqu’un qui lance un business, cette prévisibilité est rassurante. Tu peux budgéter sereinement.

L’open-source et la portabilité comptent pour toi. Avec Supabase, tu n’es pas enfermé. Si demain tu veux self-host, tu peux. Si tu veux migrer vers un autre provider PostgreSQL, c’est possible. Avec Firebase, tu es marié à Google pour le meilleur et pour le pire.

Tu veux des features modernes (transformation d’images, etc.). Les transformations d’images à la volée, les upload resumables, les buckets organisés… Supabase Storage est plus moderne que Firebase Storage. Si ton app manipule beaucoup de médias, c’est un vrai plus.

Tu anticipes une croissance rapide. Si tu vises 10K+ utilisateurs rapidement, Supabase sera probablement moins cher à terme. Le pricing fixe avec add-ons devient vite plus avantageux que le pay-per-operation de Firebase.

Tu veux avoir le contrôle total. Avec Supabase, tu peux écrire du SQL brut, créer des fonctions, des triggers, des vues… Tu as accès à toute la puissance de PostgreSQL. C’est plus de responsabilité, mais aussi plus de flexibilité.

Mon choix personnel

Bon, et moi, concrètement, qu’est-ce que je fais ?

Quand je démarrerai un nouveau projet une fois qu’Organizer sera lancé, je choisirai probablement Supabase. Pourquoi ? Parce que je connais déjà SQL, que le pricing prévisible me rassure, et que j’aime l’idée d’être sur une stack open-source. Il y aussi un peu de curiosité de ma part, j’aime bien découvrir de nouvelle chose et tester concrètement par moi-même pour me faire une idée.

Mais est-ce que je migrerais Organizer et Habit Saga de Firebase vers Supabase ? Honnêtement, non. Pas pour l’instant. Pourquoi ?

Parce que mes apps tournent bien sur Firebase. Elles ont des besoins simples (pas de requêtes complexes) et le temps réel fonctionne parfaitement (important avec la fonctionnalité famille dans Organizer). Migrer prendrait du temps (plusieurs jours de dev minimum), avec des risques de bugs, de perte de données, de downtime… ça me semble cher payer.

Bon bien sûr, si ma facture Firebase commençait à monter (> 100 $/mois), je reconsidérerais sérieusement la migration. Et tu sais quoi ? C’est tout ce que je me souhaite, ça voudrait dire que mes apps attirent beaucoup d’utilisateurs !

Le mot de la fin : Firebase et Supabase sont tous les deux excellents. Ton choix doit dépendre de :

• Ton niveau de confort avec SQL vs NoSQL
• La complexité de tes besoins en données
• Ton budget et ta préférence pour du pricing fixe ou variable
• Ton attachement (ou pas) à l'open-source

Et surtout, rappelle-toi : le meilleur backend, c’est celui qui te permet de shipper vite et de te concentrer sur ton produit, pas sur l’infrastructure. Alors choisis, lance-toi, et arrête de procrastiner en comparant des technologies (je sais, c’est tentant, mais faut se bouger 😉).

Voilà, j’espère que ça t’aide à y voir plus clair. N’hésite pas à m’écrire si tu n’es pas d’accord sur un point ou si tu veux simplement discuter.

À la prochaine !