Le développement d’applications a profondément évolué ces dernières années. Entre l’essor des IA génératives, du vibecoding, des environnements comme Lovable, Cursor ou Claude, et la recherche croissante de souveraineté des données, les développeurs veulent aller vite… sans perdre le contrôle.
C’est précisément dans ce contexte que Supabase s’est imposé comme une solution majeure : un backend open-source, basé sur PostgreSQL, capable d’être utilisé en version Cloud ou auto-hébergée, et parfaitement adapté aux nouveaux workflows IA.
Supabase, c’est quoi exactement ?
Supabase est une plateforme backend open-source construite autour de PostgreSQL.
Son objectif : offrir une alternative moderne à Firebase, tout en restant open-source et portable.
Concrètement, Supabase fournit :
🗄️ Base de données PostgreSQL complète
🔐 Authentification (email, OAuth, magic links, etc.)
🔄 API REST et Realtime générées automatiquement
📦 Stockage de fichiers
⚡ Edge Functions
🧠 Extensions PostgreSQL avancées (RLS, pgvector, etc.)
Contrairement à Firebase, Supabase ne repose pas sur une base propriétaire. Tout repose sur PostgreSQL.
Résultat : pas de vendor lock-in, et une compatibilité totale avec l’écosystème SQL.
Une alternative open-source crédible
On présente souvent Supabase comme une alternative à Firebase, mais la réalité est plus nuancée.
Critères
Open-source
Code public et modifiable
Base de données
Type d’architecture utilisée
Auto-hébergement
Déploiement possible sur son propre serveur
Vendor lock-in
Niveau de dépendance à la plateforme
Supabase permet :
d’héberger son propre backend
de migrer facilement ses données
d’avoir un contrôle total sur son infrastructure
Dans un contexte où la souveraineté numérique devient stratégique, c’est un avantage majeur.
Pourquoi Supabase explose avec le Vibecoding ?
Le vibecoding consiste à construire des applications rapidement, souvent assisté par l’IA, en privilégiant la fluidité créative plutôt que la complexité technique.
Des outils comme Lovable ont largement contribué à populariser Supabase, car ils l’intègrent nativement comme backend par défaut.
Pourquoi ?
PostgreSQL est robuste et universel
Les APIs sont générées automatiquement
L’auth est prête à l’emploi
Les migrations sont simples
Les IA comprennent parfaitement le SQL
Dans un workflow vibecoding :
L’IA génère le schéma SQL
Supabase expose immédiatement l’API
L’interface front se connecte instantanément
En résultat, le prototypage devient extrêmement rapide, avec une mise en production possible en quelques jours seulement. Les itérations sont simplifiées, les ajustements peuvent être réalisés en temps réel, et le passage de l’idée au produit fonctionnel devient beaucoup plus court qu’avec une architecture backend traditionnelle.
MCP Supabase : l’intégration avec Cursor, Claude et l’IA
Le concept de Model Context Protocol (MCP) permet aux IA comme Cursor ou Claude d’interagir directement avec une base de données ou un backend.
Avec Supabase, cela permet :
d’interroger la base en langage naturel
de générer des migrations SQL
d’inspecter la structure des tables
de modifier le schéma automatiquement
de créer des policies RLS via l’IA
Le backend devient littéralement “conversationnel”.
C’est une réelle révolution dans la manière de développer, permettant aux personnes moins techniques de créer des applications de manière simplifiée sans avoir à exécuter des migrations SQL manuellement.
Supabase Cloud vs Auto-hébergé
Supabase propose 2 approches
En résumé, Supabase Cloud convient parfaitement aux projets nécessitant rapidité de déploiement et simplicité opérationnelle, notamment pour lancer un MVP ou tester un marché. À l’inverse, la version auto-hébergée s’adresse aux équipes recherchant un contrôle total de leur infrastructure, une maîtrise complète des données et une indépendance vis-à-vis d’un fournisseur tiers.
Cloud
Avantages :
Mise en place en 2 minutes
Maintenance gérée
Scaling automatique
Idéal pour MVP
Inconvénients :
Dépendance à l’infrastructure Supabase
Coûts croissants
Moins de contrôle réseau
Selfhosted
Avantages :
Contrôle total
Données sur votre serveur
Personnalisation complète
Idéal pour homelab ou production maîtrisée
Inconvénients :
Maintenance à gérer
Configuration initiale plus complexe
Comment passer du Cloud au Self-Hosted ?
Migrer un projet Supabase depuis la version Cloud gérée vers une version auto-hébergée implique essentiellement de sauvegarder votre base de données existante puis de la restaurer sur votre instance self-hosted. C’est l’étape centrale pour reprendre le contrôle total sur l’infrastructure tout en conservant vos données et votre schéma.
🧰 Préparation requise
Avant de commencer, vous devez vous assurer :
d’avoir une instance Supabase auto-hébergée fonctionnelle (par exemple via Docker) ;
d’avoir installé la CLI Supabase (supabase) ou utiliser npx supabase ;
que Docker Desktop est installé (utile pour exécuter certains outils CLI) ;
que psql est disponible pour restaurer la base PostgreSQL ;
d’avoir sous la main les identifiants de connexion PostgreSQL de votre projet Cloud et de votre instance self-hosted.
1. Obtenir la connexion à la base Cloud
Depuis le tableau de bord de votre projet Supabase Cloud, cliquez sur Connect et copiez la chaîne de connexion PostgreSQL (utilisez le pooler si disponible)
2. Exporter la base de données Cloud
À l’aide de la CLI Supabase, vous allez créer trois fichiers SQL distincts :
supabase db dump --db-url "[CONNECTION_STRING]" -f roles.sql --role-only
supabase db dump --db-url "[CONNECTION_STRING]" -f schema.sql
supabase db dump --db-url "[CONNECTION_STRING]" -f data.sql --use-copy --data-only
Ces fichiers contiennent respectivement :
les rôles et permissions ;
le schéma SQL ;
les données utilisateurs.
L’outil utilise pg_dump en interne, mais avec des filtres adaptés à Supabase pour éviter les erreurs lors de la restauration.
3. Préparer l’instance Self-Hosted
Avant d’importer les fichiers, assurez-vous que votre instance auto-hébergée est prête :
activez toutes les extensions PostgreSQL utilisées par votre projet Cloud ;
vérifiez que la configuration de votre base cible est correcte (mêmes extensions, versions compatibles, etc.).
4. Restaurer sur l’instance auto-hébergée
Une fois prêt, utilisez psql pour restaurer les fichiers SQL sur votre base self-hosted :
psql \
--single-transaction \
--variable ON_ERROR_STOP=1 \
--file roles.sql \
--file schema.sql \
--command 'SET session_replication_role = replica' \
--file data.sql \
--dbname "postgres://postgres:[POSTGRES_PASSWORD]@[DOMAIN]:5432/postgres"
Le paramètre session_replication_role = replica désactive temporairement certains triggers, ce qui facilite l’import des données sans conflits
5. Vérifier que tout est en ordre
Après la restauration, reconnectez-vous à votre base PostgreSQL auto-hébergée pour vérifier :
la présence des tables principales (\dt public.*) ;
le nombre de lignes dans les tables clés (ex. auth.users) ;
que vos extensions sont bien chargées (SELECT * FROM pg_extension;).
⚠️ Ce qui n’est pas automatiquement transféré
La migration de la base couvre les tables, les données, les rôles et les politiques RLS, mais certains éléments requièrent une configuration manuelle sur votre instance :
Élément
Clés JWT et secrets
Fournisseurs OAuth (Google, Apple…)
Fonctions Edge
Objets de stockage (buckets, fichiers)
SMTP / email
Note : les anciens tokens JWT émis par Supabase Cloud ne sont plus valides après migration, car les secrets changent.
Utiliser MCP avec Supabase auto-hébergé
1. Exposer PostgreSQL (condition indispensable)
Pour que les outils avancés fonctionnent (apply_migration, execute_sql, etc.), le serveur MCP doit pouvoir se connecter directement à PostgreSQL via une variable DATABASE_URL.
Deux configurations sont possibles :
Cas idéal : même réseau Docker
Si votre MCP tourne dans le même réseau Docker que Supabase :
DATABASE_URL=postgresql://supabase-admin:password@db:5432/postgres
Dans ce cas :
Aucun port n’est exposé publiquement
La communication reste interne
La sécurité est maîtrisée
Cas distant (MCP sur votre machine, Supabase sur un VPS)
Dans ce cas, il est fortement recommandé :
d’utiliser un tunnel SSH
ou un VPN (WireGuard / Tailscale)
et d’éviter d’ouvrir le port 5432 publiquement
Le DATABASE_URL pointera alors vers localhost:5432 via le tunnel sécurisé.
2. Utiliser le bon rôle PostgreSQL
Pour bénéficier de tous les outils MCP sans restriction :
❌ Éviter de se connecter avec le superuser postgres
✅ Utiliser un rôle dédié comme supabase-admin
Exemple :
DATABASE_URL=postgresql://supabase-admin:password@localhost:5432/postgres
Pourquoi ?
postgres est un superuser global
supabase-admin permet d’avoir les droits nécessaires aux migrations et requêtes avancées
Cela limite les risques tout en conservant la puissance requise
3. Configuration MCP (exemple avec Cursor)
Dans un environnement local (mode stdio), la configuration peut ressembler à ceci :
{
"mcpServers": {
"selfhosted-supabase": {
"command": "bun",
"args": ["run", "/path/selfhosted-supabase-mcp/dist/index.js"],
"env": {
"SUPABASE_URL": "http://localhost:8000",
"SUPABASE_ANON_KEY": "xxx",
"SUPABASE_SERVICE_ROLE_KEY": "xxx",
"DATABASE_URL": "postgresql://supabase-admin:password@localhost:5432/postgres"
}
}
}
}
Éléments clés :
SUPABASE_SERVICE_ROLE_KEY est nécessaire pour les opérations privilégiées
DATABASE_URL est indispensable pour les outils SQL et migrations
En mode local (stdio), tous les tools sont accessibles (à utiliser uniquement en environnement sécurisé)
4. Ce que cela permet concrètement
Une fois MCP configuré avec Supabase auto-hébergé, il devient possible de :
Demander à l’IA :
“Ajoute une colonne created_at avec index sur la table orders”
→ La migration est générée et appliquée.
Exécuter une analyse :
“Optimise cette requête SQL”
Créer une policy RLS conversationnellement
Inspecter dynamiquement le schéma
Le développement backend devient fluide, itératif et assisté en temps réel.
⚠️ Points de sécurité à ne pas négliger
En auto-hébergé, vous êtes responsable :
de l’exposition réseau
des certificats SSL
de la protection des clés service_role
des accès PostgreSQL
MCP donne énormément de puissance. Il doit donc être limité :
au réseau interne
à un environnement de confiance
ou protégé par authentification stricte en mode HTTP
Supabase s’impose aujourd’hui comme bien plus qu’une simple alternative à Firebase.
C’est une plateforme backend open-source complète, fondée sur PostgreSQL, capable de s’adapter aussi bien à un MVP rapide en Cloud qu’à une infrastructure totalement maîtrisée en auto-hébergement.
Son adoption massive dans l’écosystème du vibecoding, notamment via des outils comme Lovable, Cursor ou Claude, confirme une tendance de fond : le développement moderne devient conversationnel, accéléré par l’IA, mais exige toujours plus de contrôle sur les données et l’architecture.
Avec la possibilité de migrer du Cloud vers une version self-hosted, puis d’intégrer MCP pour piloter la base en langage naturel, Supabase offre un équilibre rare entre rapidité, puissance et souveraineté.
Dans un contexte où l’intelligence artificielle redéfinit la manière de concevoir des applications, Supabase apparaît comme l’un des piliers techniques les plus solides pour construire vite et sans renoncer à la maîtrise de son infrastructure.
