Supabase : l'alternative open source à Firebase

Contexte

Qu'est-ce que Supabase, et pourquoi est-il né en réponse à Firebase ? Supabase est une plateforme de développement open source centrée sur Postgres. Elle reproduit l'expérience Firebase avec des outils open source de niveau entreprise. Depuis une dizaine d'années, le backend des applications mobiles et web ressemble à un lot fixe : base de données, connexion des utilisateurs, stockage de fichiers, temps réel et fonctions côté serveur. Firebase a empaqueté ce lot en service managé. Les développeurs front-end pouvaient livrer un produit sans presque toucher à un serveur. Le prix à payer : un modèle de données enfermé dans un système propriétaire, difficile à migrer ou à auto-héberger.

Supabase part de ce point douloureux. Son principe est simple. Si un outil existe déjà sous licence MIT, Apache 2 ou équivalente, le projet l'adopte et le soutient. Sinon, l'équipe le construit et le publie en open source. Supabase n'est donc pas une copie de Firebase, mais une plateforme qui assemble des composants ouverts et éprouvés.

Le cœur est une base Postgres dédiée, un système relationnel-objet forgé par plus de trente ans de développement. Le dépôt GitHub dépasse 110 000 étoiles et il est écrit surtout en TypeScript. Ses étiquettes (ai, auth, database, deno, embeddings, firebase) montrent un double rôle : alternative à Firebase et couche de données pour applications IA.

Analyse approfondie

La valeur technique de Supabase tient à l'assemblage de ses briques. PostgREST est un serveur web qui transforme une base Postgres en API RESTful : dès qu'une table existe, le point d'accès existe aussi, sans code CRUD écrit à la main. L'extension pg_graphql ajoute une interface GraphQL sur les mêmes données, ce qui laisse l'équipe choisir son style de requête. Comment Supabase fournit-il le temps réel à partir de Postgres ? Le composant Realtime est un serveur écrit en Elixir. Il écoute par websockets les insertions, mises à jour et suppressions de Postgres. Il lit les changements grâce à la fonction de réplication intégrée, les convertit en JSON et les diffuse aux clients autorisés. La base reste ainsi la source unique de vérité.

L'authentification repose sur GoTrue, une API fondée sur JWT qui gère inscription, connexion et sessions. Storage est une API RESTful qui gère des fichiers S3 et confie les droits à Postgres : fichiers et lignes de données partagent la même logique d'autorisation. Les fonctions sont de deux types, fonctions de base de données et Edge Functions, l'étiquette deno suggérant le lien avec le runtime Deno. Une boîte à outils de vecteurs et d'embeddings permet enfin à Postgres de stocker données relationnelles et embeddings côte à côte. Trois voies de démarrage existent : la plateforme hébergée, accessible depuis le tableau de bord sans rien installer, l'auto-hébergement selon le guide officiel, ou un environnement local. Le flux typique consiste à concevoir les tables, puis à laisser le système générer les interfaces REST, GraphQL et temps réel. La documentation, sur supabase.com/docs, suit la liste des fonctions du README. Pour la communauté, GitHub Discussions traite les questions de construction, GitHub Issues les bogues et Discord le partage de projets.

Impact sur l'industrie

Pour les équipes d'ingénierie, Supabase réunit démarrage rapide et absence de verrouillage. Comme Postgres occupe le centre, le schéma, le langage de requête et le modèle de droits relèvent du savoir commun du métier. Ce qu'une équipe apprend aujourd'hui reste utile si elle change d'infrastructure demain, une vraie protection contre le risque fournisseur pour les petites équipes.

L'angle IA compte aussi. Placer vecteurs et embeddings dans une base relationnelle permet de passer du prototype à la mise en ligne avec moins de systèmes. Une seule base porte la table des utilisateurs, les règles de droits et les embeddings, sans synchronisation avec un service vectoriel séparé.

Les limites sont réelles et la source les nomme. Supabase est composée de plusieurs composants open source indépendants : en auto-hébergement, l'équipe doit les comprendre et les exploiter, pour un effort qui dépend de sa taille et de son expérience. Le projet précise aussi qu'il ne correspond pas terme à terme à Firebase. Une équipe qui migre doit repenser la modélisation et les droits, et apprendre Postgres sérieusement. Enfin, le choix entre service hébergé et composants auto-gérés se juge selon le coût, la conformité et les compétences d'exploitation.

Perspectives

Trois points méritent d'être suivis. D'abord, la boîte à outils IA et vectorielle tiendra-t-elle sur des charges réelles plus importantes ? Le README la présente comme une fonction centrale, mais la source ne donne aucun chiffre de performance : chaque équipe devra tester par elle-même.

Ensuite, l'expérience de développement des Edge Functions. C'est là que la logique sur mesure quitte la base, et le lien avec Deno déterminera la fluidité de cette étape pour les développeurs TypeScript.

Enfin, la cohésion de l'ensemble. PostgREST, GoTrue, Realtime et pg_graphql sont des composants distincts, et la valeur de la plateforme dépend de leur évolution coordonnée. Avec plus de 110 000 étoiles et des canaux actifs sur Discussions, Issues et Discord, Supabase dispose d'une large base d'utilisateurs pour éprouver cette promesse. Pour qui veut un backend web, mobile et IA sans dépendance propriétaire, la démarche reste simple : démarrer sur le service hébergé, garder le schéma en SQL standard et traiter l'auto-hébergement comme une option testée, non comme un après-coup.