Supabase
Définition
Backend-as-a-Service open-source bâti sur PostgreSQL : authentification, stockage, realtime, edge functions et pgvector pour le RAG. Alternative à Firebase, auto-hébergeable.
Comment ça marche
Supabase assemble plusieurs briques open-source autour d'une instance PostgreSQL : PostgREST génère automatiquement une API REST à partir du schéma SQL, GoTrue gère l'authentification, Realtime diffuse les changements de base via WebSocket, Storage stocke les fichiers avec gestion des droits, Edge Functions exécutent du code Deno proche des utilisateurs. Tout converge sur la base PostgreSQL : utilisateurs, données métier, métadonnées de fichiers, vecteurs d'embeddings. Vous administrez l'ensemble depuis un dashboard web ou en SQL standard via psql. Les SDK JavaScript, Python, Swift et Kotlin abstraient les appels API tout en restant transparents sur ce qui se passe en dessous.
À quoi ça sert
Supabase couvre les besoins backend d'un SaaS sans avoir à monter et maintenir l'infrastructure. Authentification email, magic link, OAuth Google/GitHub, SSO SAML : tout est prêt en quelques minutes. Le stockage de fichiers gère uploads, downloads et CDN avec contrôle d'accès par RLS. Les Edge Functions exécutent la logique sensible (webhooks Stripe, appels OpenAI) sans exposer les clés au client. pgvector permet de bâtir un RAG dans la même base que les données métier. Pour un MVP ou un SaaS jusqu'à plusieurs dizaines de milliers d'utilisateurs, on gagne plusieurs semaines de développement sans sacrifier la qualité.
Le rôle de la Row Level Security
La RLS est le mécanisme qui rend Supabase utilisable directement depuis le frontend. On définit des policies SQL ("un utilisateur ne voit que les lignes où user_id correspond à son auth.uid()") et la base les applique sur toutes les requêtes, y compris celles venant du navigateur. Plus besoin d'écrire une couche API qui filtre à la main : la base est la couche de sécurité. Pour un SaaS multi-tenant, ça transforme un projet complexe en quelque chose de bien plus simple à maintenir. À condition de bien écrire les policies, de les tester systématiquement et de ne jamais utiliser la clé service_role côté client.
Supabase vs Firebase
Firebase repose sur Firestore, une base NoSQL propriétaire de Google. Vous êtes verrouillé chez Google, les requêtes complexes coûtent cher, et migrer vers autre chose est douloureux. Supabase mise sur PostgreSQL : standard, portable, auto-hébergeable. Les requêtes SQL gèrent les jointures, agrégations et reporting sans détour. Le code que vous écrivez tourne aussi en local avec Supabase CLI, ce qui rend le développement et les tests fiables. Pour un projet B2B exigeant en data ou avec contrainte de souveraineté, Supabase l'emporte largement. Firebase reste compétitif pour les apps mobiles grand public avec offline-first et un besoin de scalabilité massive.
Le pricing et les limites
Le plan gratuit (500 Mo de base, 1 Go de stockage, 50 000 utilisateurs auth) couvre les phases POC et MVP. Le plan Pro à 25$/mois débloque les sauvegardes quotidiennes, le branching de base et des quotas plus larges. Au-delà, on paye à l'usage : compute, storage, bandwidth, edge invocations. Pour un SaaS qui scale, l'addition reste correcte mais devient comparable à un VPS Hetzner avec PostgreSQL managé soi-même. Les limites notables : pas de control plane self-service sur la version Postgres, certaines extensions nécessitent un support ticket, le pooler de connexions impose des contraintes sur les transactions longues.
Quand l'auto-héberger
Supabase étant open-source, on peut le déployer sur son propre serveur avec Docker Compose ou Kubernetes. C'est pertinent quand la souveraineté des données est obligatoire (santé, défense, secteur public français), quand la facture managée dépasse ce qu'on paierait pour un VPS, ou quand on veut personnaliser certains composants. Le revers : il faut une compétence DevOps pour gérer les mises à jour, les sauvegardes, le monitoring et la sécurité. La plupart des projets démarrent en managé et migrent en self-hosted seulement quand le volume ou la contrainte le justifie. Le code applicatif ne change pas entre les deux modes.
Les pièges à éviter
Une policy RLS mal écrite laisse fuiter les données : on teste chaque policy avec un compte utilisateur réel, pas seulement en admin. La clé service_role contourne la RLS, elle ne doit jamais quitter le serveur, jamais finir dans un .env public ou un bundle Next.js client. Le pooler de connexions a un mode session et un mode transaction avec des contraintes différentes. Les Edge Functions sont limitées en runtime Deno, certaines libs Node ne marchent pas. Le Realtime peut générer beaucoup de bande passante si on s'abonne aux mauvaises tables. Ces points se documentent bien mais demandent de la rigueur en équipe.