Lovable + Supabase
le duo fullstack qui change tout

Techniquement oui, mais je ne le recommande pas pour la plupart des cas. Lovable est très bien intégré avec Supabase et la plupart des features (auth, storage, realtime) tirent profit de cette intégration native. Si vous partez sur une autre base comme Firebase, MongoDB, PlanetScale, ou votre propre instance Postgres hébergée ailleurs, vous devez écrire plus de code côté client pour gérer la connexion, l’authentification et les requêtes, et vous perdez l’automatisation naturelle que Lovable offre avec Supabase.

Dans quelques cas particuliers, utiliser une autre base peut se justifier. Par exemple, si votre entreprise a déjà un serveur Postgres interne sur lequel toute l’architecture est alignée, vous pouvez connecter ce Postgres à Lovable en passant par les edge functions Supabase ou en construisant une couche API intermédiaire. Pour des besoins très spécifiques (NoSQL lourd, graphe, séries temporelles), la question se pose différemment et la réponse dépend vraiment de votre stack globale.

Ma recommandation pragmatique : pour 95% des projets, restez sur Supabase avec Lovable, c’est la stack la plus productive et la plus éprouvée sur cette plateforme. Gardez les alternatives pour les cas vraiment spécifiques où Supabase serait insuffisant, mais ces cas sont rares et vous les reconnaîtrez clairement quand vous y serez confronté. Dans le doute, Supabase suffit pour aller très loin, y compris à très grande échelle.

Pour démarrer et valider votre idée, oui, largement. Le plan gratuit offre 500 MB de base de données, 1 GB de storage, 50 000 utilisateurs authentifiés par mois, et 5 GB de bandwidth. Ça permet de faire tourner un MVP avec plusieurs dizaines voire centaines d’utilisateurs actifs sans payer un centime, ce qui est incroyable pour un backend complet.

Les limites commencent à se faire sentir quand votre app grossit et qu’elle génère beaucoup de données ou de fichiers uploadés. Le passage au plan Pro à 25 dollars par mois débloque 8 GB de DB, 100 GB de storage, et des limites beaucoup plus confortables sur l’auth et le bandwidth. C’est un excellent rapport qualité-prix pour une app en croissance qui démarre à générer du chiffre.

Un piège à éviter : le plan gratuit Supabase met votre projet en pause après une semaine d’inactivité. Si votre app n’a pas de trafic régulier, elle peut être « endormie » et redémarrer avec un délai de quelques secondes quand un utilisateur revient. Pour un projet en production, passer au plan Pro dès que le projet est lancé évite ces petits désagréments et vous donne une vraie tranquillité. Je recommande généralement de rester gratuit pendant toute la phase de prototypage et de validation, puis de passer Pro dès le premier utilisateur payant ou la première tracktion sérieuse.

Les policies RLS (Row Level Security) sont le cœur de la sécurité d’une app Lovable + Supabase, et il faut absolument les maîtriser avant de passer en production. Par défaut, une table Supabase est ouverte à tout le monde si aucune policy n’est définie, et une table avec RLS activé mais sans policy bloque tout le monde. Entre les deux, vous devez écrire des règles claires qui définissent qui peut lire, écrire, modifier ou supprimer quoi.

Lovable génère des policies raisonnables par défaut, typiquement « un utilisateur peut lire et modifier ses propres données », mais il faut toujours les auditer manuellement, surtout avant un passage en production. L’erreur classique que je vois : oublier de filtrer sur user_id et se retrouver avec des données accessibles à tous les utilisateurs connectés. Sur une app sensible, c’est une fuite de données garantie.

Ma routine : après chaque session de prompt avec Lovable qui touche au schéma, je vais dans Supabase Studio, onglet Authentication > Policies, et je passe en revue chaque policy sur chaque table pour vérifier qu’elle fait bien ce que je veux. Je teste ensuite avec deux comptes utilisateurs différents pour vérifier que l’isolation est bien réelle. Cette discipline, c’est 15 minutes de check par sprint, et c’est le prix de la tranquillité. Beaucoup de projets échouent en sécurité faute d’avoir pris cette précaution de base.

Oui, et c’est même une migration que je conseille fortement si votre projet actuel tourne sur Firebase et que vous voulez profiter de Lovable. La migration technique n’est pas totalement triviale parce que Firestore (NoSQL) et Postgres (SQL) ont des modèles de données différents, mais Supabase propose des outils d’import et la communauté a développé plusieurs scripts open-source pour faciliter le process.

Les étapes classiques : vous exportez vos données Firestore au format JSON, vous modélisez votre schéma Postgres côté Supabase en vous inspirant de votre structure Firestore mais en profitant de la richesse des relations SQL, vous transformez les données JSON vers ce schéma avec un script de migration, et enfin vous migrez les utilisateurs en gardant les UIDs pour ne pas casser les logs ou les références existantes.

Pour une app de taille moyenne, comptez entre une semaine et un mois de travail sérieux pour migrer proprement, avec une phase de tests en staging avant de basculer la production. Ce n’est pas anodin mais l’investissement est rentabilisé très vite si vous passez ensuite sur Lovable, parce que vous gagnez en productivité sur toutes vos évolutions futures. Supabase a aussi l’avantage de coûter beaucoup moins cher que Firebase à volume équivalent, ce qui est un argument budgétaire fort pour justifier le projet de migration en interne.

Quelques limites honnêtes à connaître avant de vous lancer. Premièrement, Lovable génère parfois des requêtes Supabase non optimales sur des relations complexes, avec des N+1 queries ou des jointures mal faites. Pour une app simple, vous ne verrez pas la différence, mais dès que votre base atteint quelques milliers de lignes, ça peut peser sur les performances. Il faut alors parfois demander à Lovable de retravailler les queries, ou le faire à la main dans le code généré.

Deuxièmement, les edge functions de Supabase (fonctions serverless en TypeScript/Deno) sont supportées mais pas toujours aussi bien que le reste. Pour des logiques côté serveur plus poussées comme des webhooks, des traitements asynchrones, des intégrations avec des API externes, il faut parfois coder vous-même dans le projet au lieu de laisser Lovable tout générer, ce qui demande un minimum de compétences techniques.

Troisièmement, le realtime Supabase (événements push via websocket) fonctionne bien mais reste parfois à configurer finement selon votre cas d’usage. Pour une feature chat, par exemple, Lovable génère un setup correct mais vous devrez peut-être l’ajuster selon vos besoins précis de performance et de scalabilité.

Dernier point : la taille du schéma supportée par Lovable a des limites, au-delà de trente ou quarante tables il devient moins performant pour comprendre votre structure globale. Prévoyez de structurer votre app par modules si elle est grosse, pour garder Lovable efficace dans ses générations.

Supabase Auth est puissant et permet plusieurs approches selon votre besoin. Le plus simple pour commencer : vous ajoutez une table profiles liée à auth.users par l’uid, et vous stockez dans cette table le rôle de chaque utilisateur (admin, user, editor, etc.). Vous demandez à Lovable « crée une table profiles avec id lié à auth.users, nom, rôle, et génère une policy RLS qui permet à chaque user de lire/modifier son profil uniquement ».

Pour des besoins plus sophistiqués avec plusieurs rôles et permissions fines, vous pouvez utiliser les custom claims de Supabase Auth. Vous définissez dans le JWT de l’utilisateur son rôle et ses permissions, puis vous créez des policies RLS qui s’appuient sur ces claims pour autoriser ou non chaque action. C’est plus robuste et plus performant que de relire la table profiles à chaque requête, surtout à volume élevé.

Sur un projet avec invitations (typiquement SaaS avec équipes et collaborateurs), Supabase Auth gère tout ça nativement via Magic Link ou OTP. Vous demandez à Lovable « ajoute une feature invitation d’utilisateurs par email avec rôle », et vous obtenez les écrans d’invitation, l’email envoyé automatiquement, et la bascule du nouvel utilisateur dans votre app avec les bonnes permissions. Ça économise des jours de développement backend classique.

Mon conseil : commencez simple avec une table profiles et un rôle en string, puis complexifiez seulement si votre produit le demande vraiment. Beaucoup de projets n’ont besoin que de deux rôles (admin / user) et ça suffit très longtemps.

Oui, et Supabase propose même un système de cron jobs natif via pg_cron, l’extension Postgres dédiée. Vous pouvez planifier l’exécution de fonctions SQL ou d’edge functions à intervalles réguliers (toutes les minutes, heures, jours), ce qui couvre la plupart des besoins de tâches récurrentes : envoi d’emails résumés, nettoyage de données anciennes, calcul de statistiques, réactivation d’utilisateurs inactifs, synchronisation avec des API externes.

La configuration se fait en SQL, mais c’est accessible. Vous créez un job pg_cron qui pointe vers une edge function Supabase, et vous gérez la logique de votre tâche dans cette edge function en TypeScript. Lovable peut vous aider à générer tout ça en prompt, même si sur cette partie il faut parfois un peu de connaissance technique pour comprendre ce qui se passe et bien configurer.

Pour des tâches très complexes, très longues ou qui demandent plus de RAM que ce que les edge functions offrent, il est parfois préférable de passer par un service externe comme Inngest, Trigger.dev ou Temporal, qui sont spécialisés dans l’orchestration de workflows et s’intègrent bien avec Supabase. Mais pour 90% des besoins courants, pg_cron suffit largement et évite d’ajouter une dépendance supplémentaire dans votre stack globale.

Mon conseil : ne sursimplifiez pas, mais ne surcompliquez pas non plus. Pour un premier projet, pg_cron et les edge functions suffisent, et vous pourrez toujours migrer vers un orchestrateur dédié le jour où vous en aurez vraiment besoin.

Oui, Supabase propose plusieurs régions européennes (Paris, Francfort, Londres, Dublin, Amsterdam, Stockholm) et vous choisissez la région au moment de la création de votre projet. Pour un projet à destination d’utilisateurs français ou européens, je recommande vivement de choisir Paris ou Francfort, à la fois pour les performances (latence plus basse pour vos utilisateurs) et pour la conformité RGPD (données qui restent en UE).

C’est un vrai avantage compétitif de Supabase face à d’autres services moins européens comme Firebase, qui reste principalement hébergé aux États-Unis. Pour les clients professionnels en France qui doivent répondre à des exigences RGPD strictes, notamment dans le secteur public, la santé, la banque, ou l’éducation, Supabase en région européenne est une réponse rassurante qui coche la case souveraineté.

Une nuance toutefois : Supabase est une entreprise américaine, ce qui signifie que même si vos données vivent physiquement en Europe, l’entreprise elle-même est sous juridiction américaine et théoriquement soumise au Cloud Act. Pour des projets qui ont des exigences de souveraineté absolue (secteur militaire ou renseignement), il peut être pertinent d’envisager une alternative européenne comme Scalingo Postgres ou un hébergement Postgres propre en France. Pour la plupart des projets commerciaux standards, Supabase Europe est un très bon compromis qui couvre parfaitement les exigences RGPD classiques sans complexité opérationnelle supplémentaire.

Les backups font partie des sujets qu’il ne faut surtout pas oublier avant de mettre une app en production sérieuse. Sur le plan gratuit Supabase, aucun backup automatique n’est inclus, ce qui est un vrai risque si votre projet a déjà des utilisateurs et de la data importante. Sur le plan Pro, vous avez des backups quotidiens automatiques conservés pendant 7 jours, ce qui couvre la plupart des incidents courants.

Pour aller plus loin, je recommande toujours de mettre en place un backup externe en complément, qui ne dépend pas de Supabase. Vous pouvez utiliser pg_dump via un cron planifié qui sauvegarde votre base dans un bucket S3 AWS ou chez OVH Object Storage, par exemple. Cette approche vous protège même en cas de problème majeur chez Supabase lui-même, qui resterait rarissime mais reste théoriquement possible.

Pour le storage (fichiers uploadés), pensez aussi à synchroniser régulièrement vers un stockage externe. Sinon, en cas de problème, vous perdrez tous les fichiers uploadés par vos utilisateurs, ce qui peut être critique sur une marketplace ou une app de partage de documents.

Mon setup minimum pour une app en production : plan Pro Supabase pour les backups automatiques, plus un script nightly qui dump la base et les fichiers vers un bucket S3 en région différente. C’est quelques heures de config au départ, et ça couvre 99,9% des scénarios de désastre. La tranquillité qu’apporte cette redondance vaut largement l’investissement initial, surtout si votre app monte en charge et que perdre les données devient une question de survie économique.

Oui, et c’est un vrai différentiateur important face aux alternatives propriétaires comme Firebase ou AWS Amplify. Tout le stack Supabase est open-source sous licence Apache 2.0, et vous pouvez techniquement déployer votre propre instance Supabase sur vos serveurs ou dans votre cloud privé. Il existe des images Docker officielles et un guide d’auto-hébergement sur la documentation Supabase.

En pratique, l’auto-hébergement est une option qui mérite réflexion selon votre profil. Pour une startup ou un freelance, c’est probablement overkill et le service managé Supabase offre un bien meilleur rapport qualité-prix à la fois en temps et en coût global. Pour une entreprise plus grande qui a déjà une équipe DevOps solide et des exigences très strictes de souveraineté, l’auto-hébergement peut valoir le coup, en gardant à l’esprit qu’il demande de gérer soi-même la haute disponibilité, les mises à jour, la sécurité et les sauvegardes au quotidien.

Une option hybride intéressante que j’ai vue dans quelques projets : utiliser le Supabase managé pour démarrer, valider le produit et atteindre une taille intéressante, puis migrer vers du self-hosted seulement si le besoin stratégique devient vraiment fort. La portabilité est garantie par l’open-source, donc vous pouvez basculer quand vous voulez sans réécrire votre application, seulement en changeant l’URL du backend.

Mon conseil : restez sur Supabase managé tant que possible. L’auto-hébergement est une liberté précieuse mais coûteuse, à n’activer que si vous en avez un besoin clair et un budget dédié pour la maintenance au quotidien.