Alternatives à Firebase que vous pouvez auto-héberger et vraiment contrôler

Pourquoi les fondateurs cherchent des alternatives à Firebase

Firebase fait beaucoup de choses bien. L'onboarding est rapide, les SDK sont soignés, et vous pouvez passer de zéro à une app fonctionnelle avec auth, base de données et hébergement en un après-midi. Pour les hackathons et les MVPs, c'est difficile à battre.

Les problèmes commencent quand votre projet dépasse le stade du prototype.

Les surprises de facturation. Firebase facture par lecture, écriture et suppression de document dans Firestore. Ça semble raisonnable jusqu'à ce que vous réalisiez que charger une liste de 50 éléments coûte 50 lectures. Un dashboard qui se rafraîchit toutes les 30 secondes peut épuiser votre free tier en quelques heures. Le modèle de tarification pénalise exactement les patterns d'usage des vraies apps — lectures fréquentes de multiples documents. Des fondateurs partagent régulièrement des histoires de factures inattendues de centaines ou milliers de dollars.

Le vendor lock-in. Le modèle de données et le langage de requête de Firestore sont propriétaires. Les Cloud Functions tournent sur Google Cloud. Les tokens Firebase Auth sont liés à l'écosystème Firebase. Migrer signifie réécrire votre couche de données, votre système d'auth et vos fonctions serverless. C'est un effort d'ingénierie majeur pour un fondateur solo.

Les limitations du NoSQL. Firestore est une base de données document. Elle fonctionne parfaitement pour les données simples — profils utilisateurs, messages de chat, paramètres. Mais dès que vous avez besoin de jointures, d'agrégations ou de requêtes complexes entre collections, vous luttez contre le modèle de données. Vous finissez par dénormaliser (dupliquer les données entre collections) ou faire de multiples requêtes qui font grimper vos coûts de lecture.

Pas de SQL signifie pas d'écosystème. Tout l'univers des outils SQL — outils de BI, analyse de données, frameworks de migration, ORM — ne fonctionne pas avec Firestore. Vous êtes limité à la console et au SDK Firebase pour tout.

Ce sont les raisons pour lesquelles les alternatives existent. Pas parce que Firebase est mauvais, mais parce qu'il optimise pour un démarrage rapide au détriment de la flexibilité à long terme.

Comment nous avons évalué ces alternatives

Pour chaque outil, nous avons regardé ce qui compte pour un fondateur solo bootstrapé qui shippe un vrai produit :

• Temps jusqu'au premier déploiement : Quelle vitesse pour passer de zéro à une API fonctionnelle avec auth ?
• Prévisibilité des coûts : Pouvez-vous estimer votre facture mensuelle avant qu'elle n'arrive ?
• Portabilité des données : Si vous devez partir, quelle douleur pour la migration ?
• Option d'auto-hébergement : Pouvez-vous le faire tourner sur votre propre infra ?
• Maturité en production : Est-ce testé en conditions réelles ou encore en bêta ?

Nous avons aussi considéré la taille de l'écosystème — qualité de la documentation, support communautaire et disponibilité de tutoriels et exemples. Un outil techniquement supérieur sans docs est pire qu'un outil correct avec de bonnes docs quand vous construisez seul.

Analyse détaillée : ce que chaque alternative fait de mieux

Supabase — le remplacement par défaut de Firebase

Supabase s'est positionné comme « l'alternative open source à Firebase », et honnêtement, ce positionnement est juste. Il vous offre une base de données Postgres, l'auth, des abonnements temps réel, des edge functions et du stockage de fichiers — les mêmes catégories de fonctionnalités que Firebase, mais construites sur des standards ouverts.

La fondation Postgres est la plus grande différence. Au lieu des requêtes document de Firestore, vous écrivez du SQL. Au lieu de dénormaliser les données entre collections, vous utilisez des jointures relationnelles classiques. Au lieu des Firestore security rules (un DSL que seul Firebase comprend), vous utilisez des politiques Row Level Security en SQL. Si vous avez déjà utilisé Postgres, la courbe d'apprentissage est minimale.

Le dashboard est étonnamment bon pour un projet open source. Vous obtenez un éditeur de tables, un éditeur SQL, la gestion des utilisateurs auth, un navigateur de stockage et un inspecteur temps réel. Ça ressemble à un vrai produit, pas à un outil développeur bricolé à partir de composants open source.

Les abonnements temps réel passent par la réplication logique Postgres. Vous pouvez vous abonner aux changements de n'importe quelle table, filtrés par conditions. Ça fonctionne, mais ce n'est pas aussi transparent que les listeners temps réel de Firestore, qui gèrent le cache hors ligne et la résolution de conflits automatiquement. Si votre app est fortement temps réel (comme un éditeur collaboratif), ça compte.

Les Edge Functions tournent sur Deno, pas Node.js. La plupart des packages npm fonctionnent, mais certains non. Vérifiez la compatibilité avant de supposer que votre code serverless existant se portera. Supabase propose aussi des fonctions base de données (PL/pgSQL) pour la logique côté serveur qui s'exécute dans la base — souvent plus rapide qu'un appel à une edge function.

Le free tier est généreux mais a un piège : les projets sont mis en pause après une semaine d'inactivité. Pour une app en production, il vous faut le plan Pro à 25 $/mois minimum. Ça vous donne 8 Go de base de données, 100 Go de bande passante et pas de mise en pause.

Quand choisir Supabase : Vous construisez une app web avec des données relationnelles, vous connaissez le SQL et vous voulez un service géré que vous pourriez auto-héberger plus tard si nécessaire.

Appwrite — le champion de l'auto-hébergement

Appwrite est ce qu'il vous faut si votre premier critère est « je dois posséder toute la stack ». C'est un BaaS basé sur Docker que vous déployez sur votre propre serveur. Une seule commande docker compose up vous donne auth, bases de données, stockage, fonctions et un dashboard.

Le système d'auth est complet — plus de 30 fournisseurs OAuth, email/mot de passe, liens magiques, auth par téléphone et sessions anonymes. Pour la plupart des apps, l'auth est la partie la plus pénible à construire soi-même, et Appwrite l'élimine entièrement.

Les fonctions supportent de multiples runtimes : Node.js, Python, PHP, Ruby, Dart, Swift et d'autres. Cette flexibilité est inhabituelle — la plupart des BaaS vous enferment dans un seul langage. Si votre équipe a un dev Python qui veut écrire la logique backend pendant que vous gérez le frontend TypeScript, Appwrite s'adapte.

La base de données utilise MariaDB sous le capot mais expose une API orientée documents. C'est un compromis — vous avez des collections structurées avec des attributs définis (plus structuré que Firestore), mais pas d'accès SQL brut. Pour les fondateurs qui veulent toute la puissance du SQL, Supabase est un meilleur choix. Pour ceux qui préfèrent un modèle document avec un typage plus fort, Appwrite convient bien.

L'offre cloud gérée commence à 15 $/mois pour le plan Pro, ce qui est moins cher que la plupart des concurrents. Mais la vraie proposition de valeur est l'auto-hébergement. Faites tourner Appwrite sur un VPS Hetzner à 10 $/mois et vous avez un BaaS complet pour votre app sans frais de plateforme récurrents.

Quand choisir Appwrite : Vous voulez un contrôle complet de votre infrastructure backend et êtes à l'aise avec la gestion de conteneurs Docker en production.

PocketBase — le simplificateur radical

PocketBase adopte une approche différente de tout le reste de cette liste. Au lieu d'une plateforme avec microservices, conteneurs et dashboards cloud, c'est un seul binaire Go. Vous téléchargez un fichier, vous le lancez, et vous avez un backend avec base de données, auth, abonnements temps réel, stockage de fichiers et une interface admin.

La base de données est SQLite, ce qui signifie que toute votre base est un seul fichier sur le disque. Les sauvegardes consistent littéralement à copier ce fichier. Pas de serveur de base de données à gérer, pas de pools de connexion à régler, pas de réplication à configurer. Pour la grande majorité des projets indie, SQLite gère la charge sans broncher.

Le dashboard admin est intégré au binaire. Ouvrez votre navigateur sur l'URL admin et vous obtenez une interface propre pour gérer les collections (tables), consulter les données, gérer les utilisateurs auth et explorer l'API REST. Il génère même du code SDK client pour vos collections.

PocketBase supporte aussi l'extension du backend avec du code Go si vous avez besoin de logique personnalisée. Vous pouvez ajouter des routes API custom, des hooks qui s'exécutent avant ou après les opérations en base, et du middleware. Ça transforme PocketBase d'un simple BaaS en un framework applicatif léger.

La limitation fondamentale est la scalabilité. SQLite tourne sur un seul serveur. Pas de clustering intégré, pas de réplication, pas de sharding. Si votre app doit gérer des milliers d'opérations d'écriture concurrentes ou que vous avez besoin d'un déploiement multi-régions, PocketBase n'est pas le bon outil. Mais pour un SaaS servant quelques centaines d'utilisateurs, une API pour une app mobile ou un outil interne, c'est amplement suffisant.

L'autre préoccupation est le bus factor. PocketBase est maintenu principalement par un seul développeur. Le projet est populaire (30k+ étoiles GitHub), mais le rythme de développement dépend d'une seule personne. Pour un système critique en production, c'est à prendre en compte. Pour un side project ou une startup early-stage, le bénéfice de la simplicité l'emporte sur le risque.

Quand choisir PocketBase : Vous voulez le backend le plus simple possible que vous pouvez déployer sur un seul serveur et oublier. Parfait pour les MVPs, side projects et apps avec des besoins de scalabilité modestes.

Convex — le natif du temps réel

Convex adopte une approche fondamentalement différente du développement backend. Au lieu d'une base de données que vous interrogez, Convex vous donne une base réactive où chaque requête est automatiquement un abonnement temps réel. Quand les données changent, chaque client qui les affiche se met à jour instantanément.

Ce n'est pas une fonctionnalité rajoutée. Toute la plateforme est conçue autour de la réactivité. Vous écrivez des fonctions de requête en TypeScript, et les résultats sont automatiquement mis en cache et invalidés quand les données sous-jacentes changent. Pas de gestion d'abonnements manuelle, pas de polling, pas de plomberie WebSocket.

Le typage de bout en bout est convaincant. Vous définissez votre schéma en TypeScript, et les types circulent de la base de données à travers vos requêtes et mutations jusqu'à vos composants React (ou autre framework). Un changement de schéma fait apparaître des erreurs de type dans votre code UI immédiatement. Pour les développeurs solo, ça attrape les bugs avant qu'ils n'arrivent en production.

Convex fournit aussi de vraies transactions ACID, ce que Firestore ne fait pas. Si vous devez mettre à jour plusieurs documents atomiquement (débiter des crédits ET enregistrer une transaction ET mettre à jour le solde d'un utilisateur), Convex gère ça correctement sans contournements.

L'inconvénient, c'est le lock-in. Convex est une plateforme gérée sans option d'auto-hébergement. Vos données vivent sur leur infrastructure, et votre logique backend utilise leurs patterns propriétaires. Si Convex change ses prix, pivote ou ferme, vous migrez tout. Pour un side project, ce risque est acceptable. Pour votre produit principal générateur de revenus, pesez-le soigneusement face aux bénéfices de productivité.

Quand choisir Convex : Vous construisez une app collaborative temps réel et voulez des données réactives et typées sans gérer l'infrastructure WebSocket.

Nhost — le backend GraphQL

Nhost regroupe Hasura (moteur GraphQL), Postgres, auth, stockage et fonctions serverless dans une seule plateforme. Si vous êtes déjà convaincu par GraphQL pour votre couche API, Nhost supprime le fardeau d'infrastructure lié à faire tourner Hasura vous-même.

Hasura auto-génère une API GraphQL depuis votre schéma Postgres. Créez une table, et vous obtenez immédiatement des queries, mutations, subscriptions et filtrage — le tout avec des types corrects. Pas de code resolver à écrire. C'est un gain de productivité massif pour les fondateurs à l'aise avec GraphQL.

Le système d'auth supporte email/mot de passe, liens magiques et les fournisseurs OAuth courants. Il s'intègre au système de permissions de Hasura, vous pouvez donc définir le contrôle d'accès au niveau des lignes via la console Hasura plutôt que d'écrire du middleware custom.

L'auto-hébergement est supporté via Docker Compose, faisant de Nhost une option viable pour les fondateurs qui veulent le contrôle des données. La plateforme gérée commence à 25 $/mois pour le plan Pro avec des ressources incluses raisonnables.

Le compromis, c'est la complexité. GraphQL ajoute une couche d'abstraction dont tout le monde n'a pas besoin. Si votre API est principalement du CRUD, les endpoints REST (comme ceux de Supabase) sont plus simples. Si vous n'êtes pas déjà familier avec les concepts GraphQL — schémas, resolvers, subscriptions, fragments — il y a une courbe d'apprentissage significative en plus de l'apprentissage de la plateforme Nhost elle-même.

Quand choisir Nhost : Vous voulez une API GraphQL auto-générée depuis votre schéma Postgres sans gérer Hasura, Postgres et l'auth séparément.

AWS Amplify — la rampe d'accès entreprise

AWS Amplify est la réponse d'Amazon à Firebase. Il encapsule les services AWS principaux — DynamoDB, Cognito, S3, Lambda, AppSync — derrière un CLI et des bibliothèques client qui masquent la complexité AWS.

La proposition de valeur est claire : vous obtenez la fiabilité et la scalabilité d'AWS sans avoir besoin de configurer des politiques IAM, des VPC et des templates CloudFormation. Le CLI Amplify génère l'infrastructure, et les bibliothèques client gèrent les flux d'auth, appels API et uploads de fichiers.

Amplify Hosting est un ajout appréciable — pipeline CI/CD pour votre frontend avec des déploiements de prévisualisation sur les pull requests. Si vous déployez déjà une app Next.js ou React, Amplify Hosting est compétitif avec Vercel.

Les problèmes portent la marque AWS. La tarification est à l'usage à travers de multiples services, ce qui rend votre facture mensuelle imprévisible. Le pattern de design single-table de DynamoDB a une courbe d'apprentissage raide. Les flux d'auth de Cognito sont fonctionnels mais la DX est rude comparée à Firebase Auth ou Supabase Auth. Et quand les abstractions Amplify ne couvrent pas votre cas d'usage, vous tombez sur de l'AWS brut — puissant mais compliqué.

Pour les fondateurs qui font déjà tourner de l'infrastructure sur AWS, Amplify a du sens comme moyen de tout garder dans un seul écosystème. Pour tous les autres, les autres options de cette liste offrent une meilleure expérience développeur.

Quand choisir AWS Amplify : Vous êtes déjà engagé chez AWS, avez besoin de garanties de scalabilité entreprise, et acceptez de troquer la DX contre la cohérence de l'écosystème.

Quand rester sur Firebase

Firebase reste le bon choix dans des situations précises :

• Apps mobile offline-first. Les SDK clients Firestore gèrent le cache hors ligne, la résolution de conflits et la synchronisation mieux que n'importe quelle alternative listée ici.
• Vous êtes ancré dans l'écosystème Google. Si vous utilisez Google Analytics, Google Ads, BigQuery et Google Cloud, Firebase s'intègre de manière transparente.
• Prototypage rapide. Rien n'égale la vitesse de Firebase pour passer de zéro à une app fonctionnelle avec auth et persistance des données.
• Votre app est majoritairement en lecture avec des données simples. Firestore excelle quand les données s'organisent naturellement en documents et que vous lisez principalement des documents individuels ou de petites collections.

Le time to value avec Firebase est véritablement excellent. Si votre objectif est de valider une idée le plus vite possible et que vous pouvez vous permettre de migrer plus tard, Firebase est un choix raisonnable pour le prototype.

Stratégies de migration pour les fondateurs

Quitter Firebase n'est pas trivial, mais c'est faisable :

1. Commencez par l'auth. Mettez en place l'auth sur la nouvelle plateforme d'abord. Faites tourner les deux systèmes d'auth en parallèle pendant la migration.
2. Exportez les données Firestore. Utilisez le SDK Firebase Admin pour exporter les collections en JSON ou utilisez gcloud firestore export pour les jeux de données plus gros.
3. Transformez votre modèle de données. Si vous passez à Postgres (Supabase/Nhost), vous devrez convertir votre structure de documents en tables relationnelles. Mappez les sous-collections vers des relations par clé étrangère.
4. Migrez le stockage. Les fichiers Firebase Storage peuvent être téléchargés et re-uploadés sur le stockage de la nouvelle plateforme. Scriptez ça — ne le faites pas manuellement.
5. Mettez à jour le code client progressivement. Remplacez les appels au SDK Firebase par le SDK de la nouvelle plateforme, une fonctionnalité à la fois. Auth d'abord, puis les données, puis le stockage, puis les fonctions.
6. Gardez Firebase en fonctionnement pendant la transition. Ne basculez pas tout d'un coup. Faites tourner les deux systèmes pendant au moins deux semaines pour attraper les cas limites.

Comptez 2 à 4 semaines pour un projet de taille moyenne. La partie la plus difficile est généralement la transformation du modèle de données de NoSQL vers relationnel. Tout le reste est du remplacement de SDK assez direct.