Vos factures Firebase explosent et vous ne contrôlez plus vos données ?
Firebase démarre à zéro euro, puis la note grimpe sans prévenir : 300 euros, 1500 euros, parfois plus dès que le trafic décolle. Le modèle NoSQL vous enferme et la moindre requête un peu complexe tourne au casse-tête. Migrer vers Supabase, la base PostgreSQL open source, vous redonne le contrôle sur vos coûts comme sur vos données.
Dans cet article, vous allez découvrir :
- •Pourquoi Firebase finit par coûter cher et pourquoi le lock-in NoSQL freine votre produit
- •Ce qui change vraiment entre Firestore et PostgreSQL, entre Firebase Auth et Supabase Auth
- •La méthode ONDEV en 6 étapes pour migrer sans perdre une donnée ni un utilisateur
- •Les pièges classiques, le temps à prévoir et la façon dont on vous accompagne
Sur Wiloq, notre SaaS événementiel en production, Supabase et PostgreSQL font tourner plus de 12 fonctionnalités avec des coûts prévisibles au centime près.
Pourquoi migrer de Firebase vers Supabase
Des coûts imprévisibles qui explosent avec le trafic
Firebase facture chaque lecture, écriture et suppression de document. À 100 utilisateurs, tout va bien. À 10 000, le moindre écran qui charge une liste déclenche des centaines de lectures facturées. La note devient impossible à anticiper.
Supabase repose sur des forfaits lisibles : vous payez une base PostgreSQL avec des paliers clairs, pas un compteur qui tourne à chaque requête. Pour comparer les deux modèles ligne par ligne, lisez notre comparatif des tarifs Supabase.
Le lock-in qui vous emprisonne
Firebase est un produit propriétaire Google. Vos données vivent dans un format Firestore que vous ne pouvez pas simplement exporter vers un autre hébergeur. Le jour où vous voulez partir, tout est à reconstruire.
Supabase est open source et bâti sur PostgreSQL, le standard de l'industrie depuis plus de 30 ans. Vous pouvez héberger ailleurs, exporter votre base entière, la brancher sur n'importe quel outil. Aucun enfermement. Nous détaillons ce point dans notre comparatif Supabase contre Firebase.
Le NoSQL qui bride vos requêtes
Firestore est une base NoSQL orientée documents. Pas de jointures, pas de requêtes relationnelles simples, un index à déclarer pour chaque tri. Dès que votre produit grandit, vous dupliquez des données partout pour compenser.
PostgreSQL vous rend les jointures, les vues, les transactions et le SQL complet. Une seule requête remplace parfois cinq allers-retours Firestore.
Ce qui change concrètement entre Firebase et Supabase
Avant de planifier la migration, il faut visualiser les équivalences. Voici la correspondance des briques principales.
| Firebase | Supabase | Ce que ça change |
|---|---|---|
| Firestore (NoSQL documents) | PostgreSQL (relationnel) | Schéma, jointures, SQL |
| Firebase Auth | Supabase Auth | JWT compatibles, providers OAuth |
| Security Rules | Row Level Security (RLS) | Règles en SQL côté base |
| Cloud Functions | Edge Functions (Deno) | TypeScript, déploiement simple |
| Firebase Storage | Supabase Storage | Compatible S3, policies RLS |
| Realtime Database | Realtime (Postgres) | Abonnements sur des tables |
Côté sécurité, les Security Rules Firebase deviennent des politiques Row Level Security écrites directement en SQL. La logique se rapproche de vos données, ce qui réduit les failles.
La méthode ONDEV en 6 étapes pour migrer
Étape 1 : exporter les données Firebase
On commence par un export complet de Firestore, en général au format JSON via l'outil firebase export ou un script d'extraction sur mesure. On sauvegarde aussi les comptes Firebase Auth, qui s'exportent avec leurs hash de mots de passe (bcrypt ou scrypt).
Étape 2 : modéliser le schéma PostgreSQL
C'est l'étape la plus importante. On analyse vos collections Firestore et on les traduit en tables relationnelles : quelles entités, quelles relations, quelles clés étrangères. Les objets imbriqués deviennent souvent des tables filles.
Un bon modèle évite les doublons et prépare des requêtes rapides. Cette phase de conception fait partie de ce que nous couvrons dans notre guide complet sur Supabase.
Étape 3 : importer et transformer les données
On écrit un script d'import qui lit le JSON Firestore et remplit les tables PostgreSQL. C'est le moment de nettoyer : normaliser les dates, dédupliquer, convertir les références de documents en clés étrangères.
Étape 4 : migrer l'authentification
Supabase Auth peut importer les utilisateurs Firebase avec leurs mots de passe hachés, ce qui évite de forcer une réinitialisation pour tout le monde. On recrée les providers OAuth (Google, Apple) et on adapte les jetons de session.
Étape 5 : écrire les politiques RLS
Chaque Security Rule Firebase est retranscrite en politique Row Level Security. Un utilisateur ne voit que ses lignes, un admin voit tout, et ainsi de suite. La sécurité devient testable directement en SQL.
Étape 6 : réécrire les requêtes côté application
Enfin, on remplace les appels firestore.collection(...).get() par des requêtes Supabase (supabase.from(...).select()). Dans un projet Next.js, Supabase s'intègre nativement côté serveur comme côté client.
Les pièges à éviter pendant la migration
- •Modéliser trop vite : un schéma PostgreSQL bâclé vous poursuit pendant des années. On prend le temps de la conception.
- •Oublier les mots de passe : sans import des hash, tous vos utilisateurs doivent réinitialiser. Mauvaise expérience, perte d'utilisateurs.
- •Négliger le temps réel : les abonnements Firestore ne se transposent pas à l'identique. On revoit la logique realtime.
- •Basculer d'un coup en production : on procède par une bascule progressive, avec une période de double écriture si le service ne peut pas s'arrêter.
- •Sauter les tests RLS : une politique mal écrite expose les données. Chaque règle se teste.
Pour les cas où vous hésitez encore, notre article sur Firebase comme alternative à Supabase pose les critères de décision.
Combien de temps prévoir et comment ONDEV vous accompagne
La durée dépend surtout du volume de données et du nombre de requêtes à réécrire. Voici des ordres de grandeur observés sur nos projets.
| Type de projet | Volume | Durée estimée |
|---|---|---|
| MVP / petit SaaS | Quelques milliers de docs | 1 à 2 semaines |
| SaaS en croissance | Dizaines de milliers | 3 à 5 semaines |
| Application établie | Centaines de milliers | 6 à 10 semaines |
Notre agence Supabase prend en charge la migration de bout en bout : audit, modélisation, scripts d'import, RLS, réécriture des requêtes et mise en production. Vous gardez votre produit en ligne pendant toute l'opération.
FAQ : migration Firebase vers Supabase
Peut-on migrer de Firebase vers Supabase sans couper le service ?
Les utilisateurs devront-ils recréer leur mot de passe ?
Firestore est NoSQL, PostgreSQL est relationnel : est-ce risqué ?
Combien coûte une migration Firebase vers Supabase ?
Supabase est-il vraiment moins cher que Firebase ?
Conclusion : reprenez le contrôle de votre backend
Migrer de Firebase vers Supabase, ce n'est pas juste changer d'outil. C'est passer d'un modèle propriétaire, imprévisible et NoSQL à une base PostgreSQL open source, prévisible et relationnelle. Le gain : des coûts maîtrisés, des données libres et un produit qui peut grandir sans plafond technique.
La réussite tient à la méthode : exporter proprement, bien modéliser, migrer l'authentification sans casser les comptes, écrire des politiques RLS solides et réécrire les requêtes. C'est exactement ce que nous faisons au quotidien.
Vous envisagez de quitter Firebase ? Demandez votre devis de migration gratuit et on établit ensemble le plan le plus sûr pour votre application.
