Migrer de Firebase à Supabase sans tout casser

En bref

• On migre de Firebase à Supabase pour retrouver du SQL standard, éviter l'enfermement et rendre les coûts prévisibles à l'échelle.
• Trois chantiers : données (Firestore → PostgreSQL relationnel), authentification, stockage. Le plus délicat est la modélisation des données.
• On ne coupe jamais le service : migration par étapes, avec une phase de double-écriture.
• Firebase reste un excellent choix pour démarrer vite : on migre quand ses limites (requêtes, coûts, relations) deviennent un frein réel, pas par principe.

Le problème, concrètement

Firebase est parfait pour lancer un produit : temps réel, auth en quelques lignes, zéro serveur à gérer. Puis le produit grandit, et trois douleurs apparaissent : des requêtes qu'on n'arrive pas à faire (Firestore n'est pas relationnel), une facture qui devient imprévisible, et le sentiment d'être enfermé. C'est là qu'on regarde Supabase, qui pose PostgreSQL au cœur.

Pourquoi Supabase (et ses limites)

• PostgreSQL standard : requêtes SQL, relations, jointures, vues. Pas d'enfermement : votre base est portable.
• Auth, stockage, base et recherche vectorielle (pgvector) au même endroit, avec RLS multi-tenant (voir isolation par tenant).
• Coûts plus lisibles à l'échelle.

Nuance honnête : Firestore garde des atouts (temps réel ultra-simple, mode hors-ligne mobile mûr, scaling sans réfléchir). Si votre app est surtout du temps réel mobile sans relations complexes, la migration n'est pas forcément justifiée. On migre pour de vraies raisons, pas par mode.

Les 3 chantiers

1. Les données (le plus délicat)

Firestore stocke des documents imbriqués ; PostgreSQL est relationnel. La valeur (et le risque) est dans la remodélisation : transformer des collections de documents en tables liées propres. C'est là qu'un œil expérimenté évite de reproduire les mauvais schémas.

2. L'authentification

Migration des comptes vers Supabase Auth, en préservant les identifiants pour que vos utilisateurs n'aient pas à recréer de compte.

3. Le stockage

Transfert des fichiers vers Supabase Storage (ou un stockage objet), avec réécriture des références.

Sans casser l'existant : la double-écriture

La clé d'une migration sans interruption : une phase de double-écriture, où l'app écrit dans Firebase ET dans Supabase pendant qu'on migre l'historique en arrière-plan. On bascule la lecture quand tout est synchronisé et vérifié, puis on coupe Firebase. Zéro coupure, retour arrière toujours possible.

En pratique

C'est une demande fréquente que je traite au forfait après un audit : je cartographie votre modèle Firestore, je conçois le schéma PostgreSQL cible, et j'orchestre la migration par étapes avec double-écriture.

Sources

• Supabase · migrer l'authentification Firebase
• Supabase · migrer les données Firestore