TL;DR

• Supabase a dépassé le stade de "Firebase open-source". C'est une plateforme backend complète avec des fonctionnalités que Firebase n'a pas.
• Edge Functions GA, client MCP pour connecter les LLM à ta base, type inference sur le JSON, et un moteur de graphes sur PostgreSQL.
• Firebase reste pertinent pour les apps mobiles simples et l'écosystème Google.
• Le self-hosting Supabase est viable mais demande du travail. Le managed est recommandé pour la plupart des équipes.

Supabase n'est plus un challenger

Quand Supabase a lancé en 2020, le pitch était clair : "Firebase, mais open-source, et avec du vrai SQL". Cinq ans plus tard, la comparaison avec Firebase ne rend plus justice à ce que Supabase est devenu.

Le produit a évolué d'un wrapper sympa autour de PostgreSQL vers une plateforme backend complète : auth, stockage, fonctions edge, temps réel, vecteurs, graphes, et maintenant un serveur MCP pour que les agents IA interrogent ta base directement.

Voyons ce qui a changé en 2025 et pourquoi ça mérite ton attention.

Les nouveautés qui comptent

Edge Functions : enfin GA

Les Edge Functions de Supabase sont passées en General Availability début 2025. Basées sur Deno, elles s'exécutent dans 30+ régions avec des cold starts sous les 100ms.

// supabase/functions/hello/index.ts
import { serve } from "https://deno.land/std@0.168.0/http/server.ts";
import { createClient } from "https://esm.sh/@supabase/supabase-js@2";

serve(async (req) => {
  const supabase = createClient(
    Deno.env.get("SUPABASE_URL")!,
    Deno.env.get("SUPABASE_SERVICE_ROLE_KEY")!
  );

  const { data, error } = await supabase
    .from("users")
    .select("id, name, email")
    .eq("active", true);

  return new Response(JSON.stringify(data), {
    headers: { "Content-Type": "application/json" },
  });
});

Ce qui est bien :

• Pas de serveur à gérer. Pas de scaling à configurer.
• Accès direct à ta base Supabase avec les mêmes permissions RLS.
• Support natif des Deno modules (pas de build step).

Ce qui manque encore :

• Pas de support des packages npm complexes (ceux qui dépendent de binaires natifs).
• Le debugging en local est correct mais pas au niveau d'un serveur Express classique.
• Les logs en prod pourraient être plus détaillés.

Le serveur MCP : l'IA parle à ta base

C'est probablement la feature la plus "2025" de Supabase. Un serveur MCP (Model Context Protocol) intégré permet aux LLM d'interroger ta base de données en langage naturel.

Concrètement, tu peux connecter Claude, GPT ou n'importe quel agent compatible MCP à ton instance Supabase. L'agent peut :

• Lister les tables et leur schéma
• Exécuter des requêtes SELECT (en lecture seule par défaut)
• Créer des migrations
• Gérer le stockage

{
  "mcpServers": {
    "supabase": {
      "command": "npx",
      "args": ["-y", "@supabase/mcp-server"],
      "env": {
        "SUPABASE_URL": "https://xxx.supabase.co",
        "SUPABASE_SERVICE_ROLE_KEY": "eyJ..."
      }
    }
  }
}

C'est puissant pour le développement : tu peux demander à un agent de "créer une table pour gérer les abonnements avec les bonnes contraintes" et il va directement interagir avec ta base. En production, c'est la base du RAG appliqué à tes propres données.

Type inference sur le JSON

PostgreSQL stocke du JSON. Supabase a toujours supporté les colonnes jsonb. Mais jusqu'ici, le client TypeScript te renvoyait any pour ces colonnes.

En 2025, le CLI Supabase génère des types TypeScript qui incluent l'inférence sur les colonnes JSON :

// Avant : data.preferences était 'any'
// Après : data.preferences est { theme: string; lang: string; notifications: boolean }
const { data } = await supabase
  .from("users")
  .select("id, preferences")
  .single();

// TypeScript connaît la structure de preferences
console.log(data.preferences.theme); // ✅ Typé

Ça marche en analysant les données existantes dans ta base et en générant les types correspondants. Pas parfait (si tes données JSON sont inconsistantes, les types seront une union), mais c'est un vrai gain de DX.

Graph DB sur PostgreSQL

Supabase a intégré Apache AGE (A Graph Extension) pour permettre des requêtes de graphes directement sur PostgreSQL. Pas besoin de Neo4j séparé.

-- Créer un graphe
SELECT * FROM ag_catalog.create_graph('social');

-- Ajouter des noeuds et des relations
SELECT * FROM cypher('social', $$
  CREATE (alice:User {name: 'Alice'})
  CREATE (bob:User {name: 'Bob'})
  CREATE (alice)-[:FOLLOWS]->(bob)
$$) AS (v agtype);

-- Requêter les relations
SELECT * FROM cypher('social', $$
  MATCH (u:User)-[:FOLLOWS]->(friend)
  WHERE u.name = 'Alice'
  RETURN friend.name
$$) AS (name agtype);

C'est intéressant pour les cas d'usage sociaux, les systèmes de recommandation, ou l'analyse de dépendances. Ça ne remplace pas Neo4j pour des graphes massifs (milliards de noeuds), mais pour la majorité des applications web, c'est suffisant et ça évite un service supplémentaire.

Supabase vs Firebase : le vrai comparatif en 2025

La question n'est plus "lequel est mieux ?". C'est "lequel correspond à ton projet ?".

Où Supabase gagne

Où Firebase gagne

Le vrai critère de décision

Choisis Supabase si :

• Tu veux du SQL et des relations entre tes données
• Tu veux pouvoir migrer sans tout réécrire
• Tu construis une webapp ou une API
• Tu as besoin de fonctionnalités IA (vecteurs, MCP, embeddings)
• Le self-hosting est un critère

Choisis Firebase si :

• Tu construis une app mobile native
• L'offline-first est critique
• Tu es déjà dans l'écosystème Google Cloud
• Tu as besoin de push notifications et d'analytics intégrés

Le self-hosting : viable mais pas gratuit

Supabase se déploie en self-hosted via Docker Compose. L'équipe maintient un repo officiel avec tout le nécessaire. Mais "déployable" ne veut pas dire "simple".

Ce qui fonctionne bien :

• Le Docker Compose officiel est à jour et documenté
• PostgreSQL, GoTrue (auth), Realtime, Storage -- tout démarre
• Les mises à jour suivent les releases

Ce qui demande du travail :

• Les backups : tu es responsable de configurer pg_dump ou WAL-E
• Le monitoring : pas de dashboard intégré, il faut installer Grafana + Prometheus
• Les mises à jour : chaque composant peut avoir des migrations, et l'orchestration est manuelle
• Le SSL/TLS : à configurer toi-même via nginx ou Caddy
• Les Edge Functions : le runtime Deno en self-hosted est expérimental

Mon conseil : si tu n'as pas un ops dédié, reste sur le managed. Le plan gratuit de Supabase est généreux (500MB de base, 1GB de stockage, 2GB de bandwidth) et le plan Pro à 25$/mois couvre la majorité des projets.

Intégration avec l'écosystème moderne

Supabase s'intègre bien avec les outils que les devs utilisent en 2025 :

• Next.js : le package @supabase/ssr gère l'auth côté serveur proprement
• SvelteKit : support officiel avec helpers pour le SSR
• React Native / Expo : le client JS fonctionne, mais les features offline manquent
• Vercel : intégration native (les variables d'environnement se synchronisent)

L'écosystème de packages communautaires grandit aussi :

• supabase-py pour les backends Python
• supabase-swift pour les apps iOS en Swift
• supabase-kt pour Kotlin/Android

Ce qu'il faut retenir

Supabase en 2025, ce n'est plus "l'alternative Firebase open-source". C'est une plateforme backend à part entière qui fait des choses que Firebase ne peut pas faire : du SQL, des graphes, de l'IA, du self-hosting.

Le produit a des faiblesses -- le SDK mobile est en retard, l'offline-first manque, et le self-hosting demande du boulot. Mais pour une webapp, une API, ou un projet qui intègre de l'IA, c'est devenu un choix solide et crédible.

Et le fait que tes données soient dans un PostgreSQL standard, avec la possibilité de migrer à tout moment -- ça, ça vaut plus que n'importe quel benchmark.

Ressources

• Supabase Blog -- annonces officielles et guides techniques
• Supabase MCP Server -- connecter un agent IA à ta base
• Apache AGE -- l'extension graph pour PostgreSQL
• Supabase Self-Hosting Guide -- documentation officielle pour le déploiement
• Supabase vs Firebase (officiel) -- comparatif côté Supabase
• Firebase Documentation -- pour comparer par toi-même