Supabase vs Firebase vs PocketBase : quel backend no-code pour une app MVP

Pourquoi le choix du backend conditionne la réussite d un MVP

Quand un client me demande de construire un MVP, la première question technique n est jamais le front. C est toujours le backend. Où stocker les données utilisateurs ? Comment gérer l authentification ? Quel service ne va pas me coûter une fortune si le produit décolle ?

J ai livré une quinzaine de MVPs depuis 2020, et le backend est systématiquement le poste qui fait ou défait le budget. Un mauvais choix initial, c est une migration forcée six mois plus tard, avec tout le coût humain et technique que ça implique.

Les trois solutions que je compare ici, Firebase, Supabase et PocketBase, couvrent 90 % des cas d usage que je rencontre en freelance. Elles sont toutes utilisables sans écrire de backend custom, mais leurs philosophies sont radicalement différentes.

Firebase, c est Google. Supabase, c est PostgreSQL en mode managé open source. PocketBase, c est un binaire Go autonome. Trois approches, trois modèles économiques, trois niveaux de contrôle. Et le bon choix dépend entièrement de votre contexte : budget, compétences techniques, ambition de scaling.

Si vous construisez aussi vos workflows d automatisation autour de votre MVP, j ai détaillé les options dans mon comparatif n8n vs Make vs Zapier pour les workflows client.

Firebase en 2026 : forces, limites et vrais coûts

Firebase existe depuis 2011 et appartient à Google depuis 2014. C est le vétéran du Backend-as-a-Service (BaaS). En 2026, la plateforme propose plus de 20 services intégrés : Firestore, Realtime Database, Authentication, Cloud Functions, Hosting, Storage, Analytics, Crashlytics, Remote Config, et bien d autres.

La force de Firebase, c est son écosystème. Tout est intégré, documenté, et supporté par Google Cloud. L authentification prend en charge une dizaine de providers (Google, Apple, GitHub, email, téléphone). Les Cloud Functions permettent d exécuter du code serveur sans gérer d infrastructure. Le SDK est disponible pour iOS, Android, Web, Flutter, Unity.

Mais Firebase a un problème structurel : Firestore est une base NoSQL orientée document. Ça veut dire pas de jointures, pas de requêtes SQL complexes, et une modélisation des données qui oblige à dénormaliser. Pour un MVP simple (une app de to-do, un chat, un formulaire), c est parfait. Pour une app métier avec des relations complexes entre entités, ça devient vite un cauchemar.

Côté tarification, le free tier Spark est généreux en apparence : 1 Go de stockage Firestore, 50 000 lectures par jour, 20 000 écritures par jour. Mais attention : chaque lecture de document compte. Une liste de 50 éléments affichée dans une page, c est 50 lectures. Un utilisateur qui rafraîchit 10 fois, c est 500 lectures. Un MVP avec 200 utilisateurs actifs quotidiens peut atteindre le plafond en moins d une semaine.

Au-delà du free tier, le plan Blaze facture à l usage. D après la grille tarifaire officielle de Firebase, le coût de Firestore est de 0,06 $ pour 100 000 lectures. Ça semble dérisoire, mais j ai vu des factures mensuelles dépasser 150 € sur des MVPs qui n avaient même pas encore de revenus.

L autre limite majeure : le vendor lock-in. Vos données sont dans Firestore, vos fonctions dans Cloud Functions, votre auth dans Firebase Auth. Migrer vers autre chose, c est réécrire une bonne partie du backend. J ai accompagné deux clients dans cette migration, et à chaque fois, ça a pris plus de trois semaines de dev.

Supabase : l alternative open source qui monte

Supabase se présente comme « the open source Firebase alternative » et c est devenu bien plus qu un slogan. Fondé en 2020, le projet a levé plus de 116 millions de dollars et compte plus de 75 000 étoiles sur GitHub en 2026.

La différence fondamentale avec Firebase : Supabase repose sur PostgreSQL. Pas une base propriétaire, pas du NoSQL. Du vrai PostgreSQL, avec des jointures, des vues, des triggers, des fonctions stockées, des index, du full-text search natif. Si vous connaissez SQL, vous êtes chez vous.

Le free tier de Supabase est compétitif : 500 Mo de base de données, 1 Go de stockage fichiers, 2 Go de bande passante, 50 000 utilisateurs actifs mensuels sur l authentification, et surtout, pas de limite de lectures comme sur Firestore. Vous payez le stockage, pas les requêtes.

Supabase inclut aussi un système d authentification complet (email, magic link, OAuth, SSO), un stockage de fichiers compatible S3, des Edge Functions en Deno, et surtout un système de Row Level Security (RLS) qui permet de définir des règles d accès directement au niveau de la base de données. C est puissant, mais ça demande de comprendre les policies PostgreSQL.

Le dashboard est l un des meilleurs que j ai utilisés. On peut créer des tables, écrire des requêtes SQL, gérer les utilisateurs, configurer le stockage, tout depuis l interface web. Pour un freelance qui livre un MVP à un client non-technique, c est un vrai argument : le client peut voir et comprendre ses données sans outil tiers.

Le point faible ? Les Edge Functions sont encore jeunes comparées aux Cloud Functions de Firebase. Et la documentation, bien que bonne, suppose une familiarité avec PostgreSQL et les concepts relationnels. Si votre client ne connaît que des outils comme Notion ou ClickUp pour gérer ses projets, il faudra prévoir un temps d accompagnement.

PocketBase : le backend self-hosted minimaliste

PocketBase est le petit nouveau, et c est aussi le plus radical dans son approche. Créé par Gani Georgiev, c est un seul exécutable Go qui embarque tout : base de données SQLite, API REST, authentification, stockage de fichiers, dashboard admin, et realtime via SSE.

L installation prend littéralement 30 secondes. On télécharge le binaire, on lance ./pocketbase serve, et on a un backend complet accessible sur le port 8090. Pas de Docker, pas de dépendances, pas de configuration. Le binaire fait environ 30 Mo et consomme moins de 50 Mo de RAM au repos.

Pour un freelance, l avantage économique est immédiat. Un VPS chez Hetzner à 3,49 € par mois suffit pour héberger PocketBase avec des performances excellentes pour un MVP. Pas de facturation à l usage, pas de surprise en fin de mois. Vous payez votre serveur, point.

Le dashboard admin est clean et fonctionnel. On crée des collections (l équivalent des tables), on définit des champs typés, on configure les règles d accès avec une syntaxe de filtres simple. L API REST est générée automatiquement pour chaque collection. Le SDK JavaScript est léger et bien documenté.

Les limites sont réelles. PocketBase utilise SQLite, pas PostgreSQL. Pas de réplication native, pas de connexions concurrentes illimitées, pas de full-text search avancé. Pour un MVP avec moins de 10 000 utilisateurs, ça ne pose aucun problème. Au-delà, il faudra migrer.

L autre point de vigilance : vous êtes responsable de votre infrastructure. Backups, mises à jour, monitoring, sécurité du serveur. Si vous êtes développeur, c est trivial. Si vous livrez à un client qui ne sait pas ce qu est un VPS, prévoyez un contrat de maintenance. J en parle en détail dans mon article sur les clauses essentielles des contrats freelance.

PocketBase est aussi 100 % open source sous licence MIT. Pas de plan payant, pas de version « Pro », pas de features bloquées. Tout est dans le binaire. D après la documentation officielle de PocketBase, le projet est maintenu activement avec des mises à jour régulières.

Tableau comparatif détaillé : Firebase vs Supabase vs PocketBase

Ce tableau résume les différences structurelles. Mais les chiffres seuls ne racontent pas toute l histoire. Le choix dépend aussi de qui va maintenir le projet après la livraison, un point que je détaille dans la section suivante.

Quel backend choisir selon votre profil et votre projet

Après avoir utilisé les trois sur des projets réels, voici ma grille de décision. Elle n est pas universelle, mais elle reflète ce qui fonctionne en contexte freelance français.

Choisissez Firebase si :

• Votre MVP est une app mobile native (iOS/Android) et vous utilisez Flutter ou Swift
• Vous avez besoin de notifications push, analytics, et crashlytics intégrés
• Votre modèle de données est simple (peu de relations entre entités)
• Le client a déjà un compte Google Cloud ou un historique Firebase
• Le budget marketing est plus important que le budget infra : vous ne voulez zéro friction au démarrage

Choisissez Supabase si :

• Votre MVP a un modèle de données relationnel (utilisateurs, commandes, produits, relations N-N)
• Vous voulez pouvoir écrire des requêtes SQL pour des rapports ou des dashboards
• Le client veut visualiser ses données facilement via le dashboard
• Vous anticipez une migration future vers un PostgreSQL dédié
• Vous travaillez avec des outils no-code qui supportent Supabase nativement

Choisissez PocketBase si :

• Vous êtes développeur et vous voulez tout contrôler
• Le budget est serré (moins de 50 € par mois pour l ensemble de l infra)
• Les données sont sensibles et doivent rester sur un serveur européen que vous maîtrisez
• Le MVP est un outil interne avec moins de 1 000 utilisateurs
• Vous voulez éviter tout vendor lock-in et toute dépendance cloud

Le point crucial que beaucoup de comparatifs oublient : qui maintient le backend après vous ? Si vous livrez un MVP à une startup qui n a pas de CTO, Firebase ou Supabase en mode managé sont plus sûrs. Si vous restez en maintenance, PocketBase vous donne la marge la plus large.

Et n oubliez pas de facturer correctement ce travail. Si vous débutez, mon guide sur le TJM freelance en 2026 vous aidera à ne pas sous-estimer le poste backend.

Intégration avec les outils no-code : Bubble, FlutterFlow, Webflow

Le choix du backend ne se fait pas dans le vide. En 2026, la majorité des MVPs que je livre utilisent au moins un outil no-code ou low-code pour le front. Et tous les backends ne s intègrent pas aussi bien avec chaque plateforme.

Firebase + FlutterFlow : c est le couple le plus mature. FlutterFlow a été construit autour de Firebase, et l intégration est native. Création de collections Firestore, configuration de l auth, liaison des widgets aux données : tout se fait dans l interface visuelle. C est la combinaison que je recommande pour les apps mobiles MVP quand le client veut aller vite.

Supabase + Bubble : Bubble permet de connecter Supabase via l API REST ou via des plugins communautaires. L avantage, c est que Bubble gère déjà sa propre base de données, mais en connectant Supabase en backend principal, on garde la portabilité des données. J ai détaillé les forces et faiblesses de Bubble dans mon article Bubble en 2026 face à Framer et Webflow.

Supabase + Webflow : Webflow n a pas d intégration native avec Supabase, mais via Make ou n8n, on peut synchroniser les soumissions de formulaires Webflow vers Supabase, déclencher des workflows, et même alimenter des pages dynamiques via l API. C est plus technique, mais ça fonctionne très bien pour des sites vitrines avec une couche applicative.

PocketBase + n importe quel front : PocketBase expose une API REST standard et un SDK JavaScript. Il s intègre avec tout ce qui peut faire des appels HTTP. Pas d intégration visuelle native dans les outils no-code, mais c est le plus flexible pour les développeurs qui construisent des fronts custom en React, Vue, ou Svelte.

Un point souvent négligé : la gestion des fichiers. Firebase Storage et Supabase Storage gèrent le stockage de fichiers (images, PDF, vidéos) avec des URLs signées et des règles d accès. PocketBase stocke les fichiers sur le disque du serveur. Pour un MVP, les trois fonctionnent. Pour un produit avec des milliers de fichiers uploadés par les utilisateurs, Firebase et Supabase sont plus adaptés grâce au CDN intégré.

Migration et scaling : que se passe-t-il après le MVP

Un MVP qui fonctionne, c est un MVP qui doit scaler. Et c est là que le choix initial du backend montre ses vraies conséquences.

Firebase scale automatiquement, c est son argument principal. Firestore gère des millions de documents sans configuration. Le problème, c est que le coût scale aussi. J ai vu un client passer de 0 à 340 € par mois en trois semaines après un article viral sur LinkedIn qui a généré 15 000 inscriptions. Le produit n avait pas encore de revenus.

Supabase propose un scaling progressif. Le plan Pro à 25 $ par mois donne 8 Go de stockage, des backups quotidiens, et un support email sous 24 heures. Pour aller plus loin, le plan Team à 599 $ par mois inclut la réplication, le support prioritaire, et des capacités de compute plus importantes. Mais surtout, comme c est du PostgreSQL standard, vous pouvez migrer vers n importe quel hébergeur PostgreSQL (Neon, Railway, un serveur dédié) sans réécrire votre code.

PocketBase ne scale pas horizontalement. Un seul binaire, une seule base SQLite, un seul serveur. Pour dépasser les limites, il faut soit migrer vers Supabase ou PostgreSQL en gardant la même structure de données (les schémas sont compatibles), soit réécrire le backend. La migration d un schéma PocketBase vers Supabase prend environ 2 à 4 jours de dev sur un MVP standard.

D après la documentation officielle de Supabase sur la gestion de plateforme, la migration depuis d autres backends est documentée avec des guides pas à pas. C est un bon indicateur de maturité.

Mon conseil : si votre MVP a une probabilité réaliste de dépasser 10 000 utilisateurs dans les 12 mois, partez sur Supabase. Le coût initial est légèrement plus élevé que PocketBase, mais vous évitez une migration forcée. Si vous êtes en phase d exploration et que vous ne savez pas encore si le produit va trouver son marché, PocketBase vous coûte 21 € sur 6 mois au lieu de potentiellement 150 € sur Firebase.

Mon retour d expérience sur 3 projets clients réels

Projet 1 : app de réservation pour un réseau de salles de sport (Firebase)

Le client voulait une app mobile Flutter avec réservation de créneaux, paiement Stripe, et notifications push. FlutterFlow + Firebase était le choix évident. Le prototype a été livré en 8 jours. Le coût Firebase sur les 3 premiers mois : 0 € (free tier). Après le lancement avec 800 utilisateurs actifs, la facture est montée à 45 € par mois, principalement à cause des lectures Firestore sur la page d accueil qui affiche les créneaux disponibles en temps réel.

Projet 2 : plateforme de mise en relation freelances/clients (Supabase)

Modèle de données relationnel complexe : profils, compétences, missions, candidatures, messages, évaluations. Impossible en NoSQL sans dénormalisation massive. Supabase + Next.js, livré en 14 jours. Le Row Level Security a pris 2 jours à configurer correctement, mais une fois en place, la sécurité des données est béton. Coût Supabase : 0 € pendant 4 mois, puis passage au plan Pro à 25 $ quand le stockage a dépassé 500 Mo. Pour la gestion du projet, j ai utilisé les méthodes décrites dans mon article sur Linear vs Jira vs GitHub Projects.

Projet 3 : outil interne de suivi de chantier pour un artisan (PocketBase)

Le client voulait un outil simple : liste de chantiers, photos avant/après, statut d avancement, export PDF. Budget total : 2 000 €. J ai déployé PocketBase sur un VPS Hetzner à 3,49 € par mois avec un front en SvelteKit. Livré en 6 jours. Le client utilise l outil depuis 8 mois sans aucun incident. Coût total d infrastructure : 27,92 €. C est le genre de projet où Firebase ou Supabase seraient du surdimensionnement.

Ces trois cas illustrent la même chose : il n y a pas de meilleur backend universel. Il y a le bon backend pour votre contexte précis. Et si vous facturez correctement, pensez à utiliser un outil adapté ; j ai comparé les options dans mon article Freebe vs Abby vs Indy pour la facturation.

Un dernier point pratique : quel que soit le backend choisi, documentez votre architecture. Un schéma de base de données, les variables d environnement, les endpoints API, les règles d accès. Si le client change de dev dans 6 mois, il ne doit pas repartir de zéro. C est ce genre de rigueur qui fait la différence entre un freelance à qui on confie un MVP et un freelance à qui on confie la suite. Pour organiser cette documentation, j ai détaillé mes outils préférés dans Notion vs Obsidian vs Logseq pour un dev freelance.