Alternative à Firebase : où partir et comment migrer sans rien casser

Pourquoi partir sur Supabase. C'est l'alternative la plus citée, et pour une bonne raison : elle reprend les briques de Firebase (authentification, base, stockage de fichiers, fonctions, temps réel) mais sur PostgreSQL. Tu retrouves les jointures, la recherche plein texte, les contraintes d'unicité, tout ce que Firestore t'obligeait à bricoler. Le code est libre, tu peux l'héberger toi-même, et la région Paris (eu-west-3) existe. Sur le plan Pro, un plafond de dépense est actif par défaut : la facture surprise disparaît. Nous lui donnons 4,3 sur 5 dans notre avis complet sur Supabase.

Pour qui. Les équipes qui ont des données relationnelles (utilisateurs, commandes, abonnements) et qui veulent garder une approche « backend prêt à l'emploi ».

Pour qui ce n'est pas fait. Une application qui vit hors ligne : le cache local de Firestore n'a pas d'équivalent direct. Un retour de terrain sur la migration de quatorze projets parle de trois semaines pour reconstruire une couche locale.

Sa limite. Le gratuit met un projet en pause après une semaine sans activité et se limite à deux projets actifs. Le calcul est facturé par projet, et les fonctions tournent sous Deno : tes fonctions Node sont à réécrire. Le nombre de connexions à la base est limité, il faut passer par le regroupeur de connexions.

Comment migrer. Supabase publie des outils dédiés : firestore2json puis json2supabase transforment chaque collection en table (les champs imbriqués passent en jsonb). Pour les comptes, firestoreusers2json puis import_users ; note les quatre paramètres de hachage de ton projet. Une couche intermédiaire peut vérifier l'ancien mot de passe à la première connexion, pour éviter la réinitialisation de masse.

Son prix. Gratuit : 50 000 utilisateurs actifs mensuels, 500 Mo de base, 1 Go de fichiers, 5 Go de trafic sortant. Pro dès 25 $ par mois et par organisation, avec 10 $ de crédit de calcul : 100 000 utilisateurs actifs puis 0,00325 $ chacun, 8 Go de disque puis 0,125 $ le Go, 100 Go de fichiers, 250 Go de trafic sortant.

Pourquoi partir sur Appwrite. Appwrite reprend presque une à une les briques de Firebase : authentification, base de documents, stockage, fonctions, temps réel. Ton modèle de données en documents peut donc rester proche de l'actuel. Surtout, son outil de migration intégré importe les comptes en gardant les mots de passe : tes utilisateurs ne voient rien. Le code est libre et s'installe avec Docker sur ton propre serveur.

Pour qui. Les équipes qui veulent sortir de Google sans refaire leur modèle de données, et celles qui veulent s'héberger elles-mêmes.

Pour qui ce n'est pas fait. Un projet qui tourne sur la Realtime Database, l'ancienne base de Firebase : l'outil de migration ne la prend pas en charge.

Sa limite. L'outil ne reprend que les documents de premier niveau de Firestore : tes sous-collections sont à déplacer à la main. Les fonctions sont à réécrire, et les utilisateurs connectés par Google ou Apple devront se reconnecter une fois. Sur le gratuit, un projet qui atteint sa limite est gelé, la console passe en lecture seule.

Comment migrer. Dans la console, onglet Migrations, choisis Firebase, donne la clé du compte de service, puis coche comptes, base et fichiers. Lance d'abord sur un projet d'essai et compare les nombres de documents.

Son prix. Un plan gratuit, puis un plan Pro facturé à l'usage, sur lequel tu fixes un plafond de budget ; Appwrite t'écrit à 75 % et à 100 % des limites. Une base dédiée démarre à 10 $ par mois, et 10 $ de crédit de calcul pour la base sont inclus chaque mois. Hébergé chez toi, le logiciel ne coûte que ton serveur.

Pourquoi partir sur Convex. Ce que les développeurs aiment dans Firestore, c'est l'écran qui se met à jour seul quand une donnée change. Convex pousse cette idée plus loin : une base réactive où tes requêtes et tes écritures sont des fonctions TypeScript, et où chaque client abonné reçoit les changements. Tu gardes la sensation de Firebase, avec du typage de bout en bout.

Pour qui. Les équipes TypeScript qui construisent une application collaborative, un tableau partagé, une messagerie, un jeu.

Pour qui ce n'est pas fait. Une équipe qui veut du SQL standard et pouvoir brancher n'importe quel outil d'analyse sur sa base.

Sa limite. Tout le code d'accès aux données est à réécrire : aucun outil ne convertit tes appels Firebase. Le plan Professional se paie par développeur, ce qui monte vite dans une équipe de dix. L'hébergement chez toi est possible, sous une licence qui ne devient libre (Apache 2.0) qu'au bout de deux ans.

Comment migrer. Exporte tes collections en JSON, réécris ton schéma en TypeScript, importe, puis remplace écran par écran les écoutes Firestore par des requêtes Convex. Garde Firebase en lecture pendant la bascule.

Son prix. Gratuit à l'usage : 1 million d'appels de fonctions puis 2,20 $ le million, 0,5 Go de base puis 0,22 $ le Go. Professional à 25 $ par développeur et par mois, avec 25 millions d'appels et 50 Go.

Pourquoi partir sur PocketBase. PocketBase tient dans un seul exécutable : base SQLite, authentification, fichiers, temps réel et console d'administration. Tu le poses sur un petit serveur et c'est fini. Le logiciel est gratuit et libre ; ta seule dépense est le serveur, à prix fixe. Plus de facture à la lecture : c'est la réponse la plus radicale à la peur de la facture surprise.

Pour qui. Les développeurs indépendants, les outils internes, les prototypes et les applications de taille modeste.

Pour qui ce n'est pas fait. Une application qui doit tenir une forte croissance sur plusieurs serveurs, ou une équipe qui ne veut pas gérer de serveur.

Sa limite. PocketBase ne grandit que verticalement : un serveur, que tu muscles. Il est encore en version 0.x, et l'éditeur prévient que la compatibilité n'est pas garantie d'une version à l'autre : lis les notes avant chaque mise à jour. Sauvegardes, sécurité et disponibilité sont à ta charge.

Comment migrer. Il n'existe pas d'outil officiel : tu exportes Firestore en JSON, puis un script pousse les enregistrements par l'API de PocketBase. Les comptes se recréent, et les utilisateurs redéfinissent leur mot de passe.

Son prix. Gratuit. L'éditeur annonce plus de 10 000 connexions temps réel sur un petit serveur virtuel à 4 $ par mois.

Pourquoi partir sur Nhost. Nhost associe PostgreSQL à Hasura, qui génère une API GraphQL à partir de tes tables, plus l'authentification et le stockage. Tu passes au relationnel sans écrire d'API. Le code est libre.

Pour qui. Les équipes front qui travaillent déjà en GraphQL et veulent une base SQL sans gérer de serveur.

Pour qui ce n'est pas fait. Une équipe qui n'a jamais touché à GraphQL : la marche est haute. Et une entreprise qui doit choisir sa région d'hébergement : la page de prix ne les affiche pas.

Sa limite. Le gratuit se limite à un projet, mis en pause après une semaine sans activité. La communauté est plus petite que celle de Supabase.

Comment migrer. Même chemin que vers Supabase : export JSON de Firestore, remodelage en tables, import dans PostgreSQL, puis comptes recréés.

Son prix. Starter gratuit : un projet, 1 Go de base, 1 Go de fichiers, 5 Go sortants. Pro dès 25 $ par mois avec 15 $ de calcul, 10 Go de base, 50 Go de fichiers, 50 Go sortants et des sauvegardes.

Pourquoi partir sur Amplify. Amplify assemble les services d'AWS (Cognito pour les comptes, AppSync, DynamoDB, Lambda, S3) derrière un même outil. Si ton entreprise a déjà un compte AWS, tes données rejoignent le reste de ton infrastructure et tes contrats.

Pour qui. Les équipes qui connaissent déjà AWS et veulent tout regrouper chez un seul fournisseur.

Pour qui ce n'est pas fait. Celui qui part de Firebase pour fuir la facturation à l'usage : DynamoDB et Lambda fonctionnent sur le même principe. Lis aussi notre page quitter AWS avant de t'engager.

Sa limite. La facture se lit service par service : l'hébergement Amplify d'un côté, chaque brique du backend de l'autre. La prise en main est plus lourde que Firebase.

Comment migrer. DynamoDB est aussi une base NoSQL : ton modèle en documents s'y transpose mieux qu'en SQL. Les comptes et les fichiers suivent le même chemin que vers les autres destinations.

Son prix. Hébergement gratuit douze mois (1 000 minutes de compilation, 5 Go stockés, 15 Go servis par mois), puis 0,01 $ la minute, 0,023 $ le Go stocké et 0,15 $ le Go servi. Le backend est facturé à part.

Pourquoi partir sur Back4App. Back4App héberge Parse Server, un backend libre bâti sur MongoDB, donc une base de documents comme Firestore. Ses plans ont un prix fixe par application : tu sais ce que tu paies avant la fin du mois.

Pour qui. Les petites applications mobiles qui veulent un budget prévisible sans changer de logique NoSQL.

Pour qui ce n'est pas fait. Un projet qui grandit vite : le saut entre les plans est grand.

Sa limite. Le gratuit est serré (25 000 requêtes par mois, 250 Mo de base), et l'écart entre le plan à 15 $ et le suivant, à 80 $, est brutal. Comme Parse est libre, tu peux toutefois repartir chez un autre hébergeur.

Comment migrer. L'éditeur annonce des outils d'import ; en pratique, exporte en JSON, adapte les champs, importe par collection, puis recrée les comptes.

Son prix. Gratuit : 25 000 requêtes par mois, 250 Mo, 1 Go de transfert, 1 Go de fichiers. MVP à 15 $ par application et par mois en annuel, puis un plan à 80 $ (5 millions de requêtes), et 400 $ en serveur dédié.

Pourquoi partir sur Xano. Si ton application Firebase est construite avec un outil visuel comme FlutterFlow et que tu n'écris pas de serveur, Xano te donne une base relationnelle et des API qu'on assemble à la souris. Nous lui donnons 4,1 sur 5 dans notre avis sur Xano, et notre comparatif FlutterFlow contre Xano explique comment les deux s'assemblent.

Pour qui. Les créateurs d'applications sans code dont le projet rapporte déjà, ou va rapporter.

Pour qui ce n'est pas fait. Un projet secondaire au budget serré.

Sa limite. Il n'existe aucun palier entre le gratuit et 85 $ par mois. Tu restes dépendant d'un éditeur, comme avec Firebase.

Comment migrer. Exporte tes collections en JSON ou CSV, recrée tes tables dans Xano, importe, puis rebranche ton interface sur ses API. Les comptes se recréent.

Son prix. Un plan gratuit pour le prototype, puis 85 $ par mois en paiement annuel (99 $ au mois).

Pourquoi l'envisager. Si ton seul grief est le NoSQL, tu n'es pas obligé de tout quitter. Data Connect branche une base PostgreSQL (sur Cloud SQL) à ton projet Firebase. Tu gardes l'authentification, l'hébergement et la console que tu connais.

Pour qui. Les équipes satisfaites de Firebase hors base de données, qui veulent des jointures sans migration complète. Le produit apparaît aussi sous le nom SQL Connect.

Pour qui ce n'est pas fait. Celui qui veut sortir de Google, ou héberger ses données en dehors d'un grand cloud américain.

Sa limite. Le verrouillage reste entier, et Cloud SQL ajoute un coût fixe mensuel, même quand personne n'utilise ton application.

Comment migrer. Firestore et Data Connect cohabitent : déplace une collection à la fois vers les tables PostgreSQL.

Son prix. Essai gratuit de trois mois pour un projet Spark, puis tarif Cloud SQL dès environ 9,37 $ par mois ; 250 000 opérations par mois incluses.