Supabase : le guide complet de la plateforme Postgres open source

Supabase se présente aujourd'hui comme « The Postgres Development Platform »¹ : chaque projet est une base PostgreSQL dédiée, livrée avec l'authentification, une API REST et GraphQL générée depuis le schéma, le temps réel, le stockage de fichiers, des fonctions serveur et la recherche vectorielle². Pour une entreprise, l'intérêt est de ne pas assembler cinq outils : un seul back-end, sur une base de données standard dont les données restent exportables. Le code est open source (dépôt principal sous licence Apache 2.0) et la pile peut être auto-hébergée avec Docker³. Le service hébergé a un plan gratuit ; la production commence au plan Pro, à partir de 25 $ par mois⁴.

Cette page est le point d'entrée de notre dossier Supabase : elle explique ce qui tourne dans un projet, ce qu'il coûte, comment démarrer, puis renvoie vers l'article détaillé de chaque sujet.

Qu'est-ce que Supabase, concrètement ?

• Database : PostgreSQL complet, avec plus de 50 extensions préinstallées à activer selon les besoins⁵.
• Auth : e-mail et mot de passe, magic link, OTP, téléphone, connexion sociale et SSO, avec des JWT reconnus par la base⁶.
• API de données : REST via PostgREST et GraphQL via l'extension pg_graphql².
• Realtime : Broadcast, Presence et écoute des changements de la base².
• Storage : stockage objet compatible S3, droits d'accès par policies².
• Edge Functions : fonctions TypeScript exécutées sur un runtime compatible Deno².
• Vector : stockage et recherche d'embeddings avec pgvector.

La sécurité repose sur un principe unique : chaque requête arrive dans Postgres sous un rôle (anon, authenticated ou service_role) et la Row Level Security décide des lignes accessibles⁷. Le détail est dans notre guide des droits d'accès : RLS, rôles et permissions.

Quels services composent un projet ?

Un projet Supabase est une base PostgreSQL dédiée entourée de services open source qui lui parlent directement. Une passerelle API Envoy reçoit les requêtes et les route vers le bon service². La plupart des composants sont développés ou maintenus par Supabase, les autres sont des projets open source existants : c'est un choix revendiqué, « utiliser et soutenir des outils existants plutôt que tout développer »².

Source : page Architecture de la documentation². Le dépôt du service Auth s'appelle aujourd'hui supabase/auth.

Pourquoi PostgreSQL est-il au centre ?

Supabase n'abstrait pas la base : vous y accédez avec tous les privilèges, en SQL, et les autres services s'appuient sur ses mécanismes. Les utilisateurs d'Auth vivent dans le schéma auth, les métadonnées des fichiers dans storage, et les droits de tous les services passent par les rôles Postgres et la Row Level Security²⁹. Conséquence pratique : on ne peut pas utiliser Supabase sans PostgreSQL.

Plus de 50 extensions sont préinstallées, mais la plupart s'activent à la demande, depuis le Dashboard (Database > Extensions) ou en SQL⁵ :

create extension if not exists vector with schema extensions;  -- pgvector

C'est le cas de pg_graphql et de vector (pgvector) pour les embeddings. Pour la mise en pratique, voir stocker et rechercher des embeddings avec pgvector. Pour créer ses tables, voir structurer sa base Supabase.

Comment fonctionne l'API automatique ?

PostgREST lit le schéma et expose chaque table, vue et fonction des schémas exposés sous /rest/v1/. Une requête s'authentifie avec la clé API dans l'en-tête apikey (documentation de l'API) :

curl 'https://<PROJECT_REF>.supabase.co/rest/v1/articles?select=*&status=eq.published' \
  -H "apikey: <PUBLISHABLE_KEY>"

La clé identifie l'application ; si un utilisateur est connecté, son JWT fait basculer la requête sur le rôle authenticated, et la RLS filtre les lignes⁹. L'API GraphQL repose sur l'extension pg_graphql, qui traduit une requête GraphQL en SQL à l'intérieur de Postgres ; depuis sa version 1.6.0, l'introspection du schéma est désactivée par défaut.

Comment Realtime suit-il les changements de la base ?

Realtime est un cluster Elixir/Phoenix distribué mondialement. Il offre trois fonctions : Broadcast (messages entre clients), Presence (qui est connecté, via un magasin clé-valeur en mémoire) et Postgres Changes. Pour ces derniers, Realtime ouvre un slot de réplication logique sur votre base et lit le WAL (journal d'écriture de Postgres). Le Broadcast depuis la base passe, lui, par la table realtime.messages, partitionnée par jour et conservée 3 jours¹⁰.

const channel = supabase
  .channel('messages')
  .on('postgres_changes',
    { event: 'INSERT', schema: 'public', table: 'messages' },
    (payload) => console.log('Nouveau message :', payload.new)
  )
  .subscribe()

Détails et limites : Supabase Realtime.

Comment Storage gère-t-il les fichiers ?

Storage est un service de stockage objet compatible S3, avec API REST et envois reprenables (TUS). Les métadonnées des fichiers sont dans Postgres, ce qui permet d'écrire les droits d'accès sous forme de policies RLS (documentation Storage). Le CDN est « basique » sur le plan gratuit et « Smart CDN » sur les plans payants ; les transformations d'images (redimensionnement à la volée) ne sont pas disponibles sur le plan gratuit⁴. Voir Supabase Storage.

Où s'exécutent les Edge Functions ?

Sur le Supabase Edge Runtime, un runtime open source compatible Deno, et non sur Deno Deploy. Au déploiement, la CLI regroupe la fonction et ses dépendances dans un fichier ESZip, distribué sur le réseau de Supabase ; la passerelle route ensuite chaque appel vers le nœud le plus proche de l'utilisateur¹¹. Voir les Edge Functions.

Qu'est-ce qui change en auto-hébergement ?

La même pile se déploie avec Docker Compose à partir du dépôt supabase/supabase, en figeant une version (par exemple self-hosted/v0.8.2 dans la documentation actuelle). La passerelle est Envoy par défaut, sur le port 8000, qui sert aussi le Dashboard¹². Les configurations antérieures à self-hosted/v0.8.0 utilisaient Kong ; les tutoriels qui décrivent Kong comme passerelle de Supabase sont donc datés. Chaque service est conçu pour fonctionner seul, avec « rien d'autre qu'une base Postgres »² : on peut ne déployer qu'une partie de la pile, mais c'est alors à vous d'assembler et de maintenir les briques. Le logiciel est gratuit, mais le serveur, les sauvegardes, les mises à jour et la sécurité sont à votre charge. Pour la pile locale de développement, voir le guide de la CLI Supabase.

Par où commencer dans ce dossier ?

Supabase ou Firebase ?

La différence historique tient au modèle de données : Firestore, la base principale de Firebase, est une base NoSQL orientée documents, alors que Supabase est construit sur une base relationnelle². L'écart s'est réduit : Google propose désormais Firebase SQL Connect (anciennement Data Connect), une base PostgreSQL gérée via Cloud SQL⁸. Restent deux différences nettes : Supabase donne un accès SQL direct à toute la base et peut s'auto-héberger, là où Firebase reste un service Google. Le comparatif détaillé est dans Supabase vs Firebase.

Combien coûte Supabase ?

• Free (0 $) : 500 Mo de base par projet, 1 Go de fichiers, 5 Go d'egress, 50 000 utilisateurs actifs par mois, deux projets actifs, pause après une semaine d'inactivité, pas de sauvegarde automatique.
• Pro (dès 25 $/mois) : 8 Go de disque par projet, 100 Go de fichiers, 250 Go d'egress, 100 000 utilisateurs actifs, sauvegardes quotidiennes sur 7 jours, plus de pause.
• Team (dès 599 $/mois) : SOC 2, ISO 27001, SSO pour l'équipe, sauvegardes sur 14 jours.
• Enterprise : sur devis, avec SLA de disponibilité.

Chaque projet est en plus facturé selon sa taille de calcul (10 $ par mois pour une instance Micro, couverts par le crédit inclus dans les plans payants)⁴. Détails et exemples chiffrés : Supabase Pricing.

Comment démarrer un premier projet ?

npm install supabase --save-dev
npx supabase init
npx supabase start          # pile locale, Docker requis
npm install @supabase/supabase-js

La CLI s'installe dans le projet (ou globalement avec Homebrew ou Scoop) ; l'installation globale par npm n'est pas une méthode prévue (documentation de la CLI). Côté code, le client se crée avec l'URL du projet et la clé publishable :

import { createClient } from '@supabase/supabase-js'

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!
)

const { data, error } = await supabase
  .from('articles')
  .select('id, title')
  .eq('status', 'published')

Cette requête ne renverra des lignes que si la table a la RLS activée, une policy qui autorise la lecture et les grants correspondants⁷.

Quels pièges éviter en 2026 ?

• Anciennes clés : anon et service_role sont en cours de dépréciation (fin 2026) ; utilisez les clés publishable et secrètes⁹.
• Session côté serveur : protégez les pages avec getClaims() via @supabase/ssr, jamais avec getSession() (documentation SSR). Voir Supabase Auth.
• RLS sans grants : les policies ne retirent pas les privilèges accordés automatiquement aux nouvelles tables de public⁷.
• E-mails : le SMTP intégré est limité et non prévu pour la production ; configurez le vôtre avant d'ouvrir les inscriptions.
• Plan gratuit en production : pause après une semaine sans activité et aucune sauvegarde automatique⁴.

Pour quels projets Supabase est-il adapté ?

• SaaS multi-clients : isolation des données par organisation avec la RLS.
• Applications mobiles : bibliothèques clientes officielles notamment pour JavaScript, Flutter (Dart), Swift, Kotlin, Python et C# (exemples par bibliothèque).
• Outils internes : une vraie base relationnelle derrière un outil d'administration.
• Applications d'IA : embeddings et recherche sémantique avec pgvector, dans la même base que les données métier. Pour piloter une base depuis un assistant, voir Supabase MCP et le guide pratique de MCP avec Claude.

Supabase est moins indiqué si votre équipe ne veut pas écrire de SQL ni raisonner en policies : la sécurité d'un projet Supabase dépend directement de la qualité de ses règles RLS. Pour un projet que vous voulez confier ou faire auditer, voyez notre agence d'automatisation et d'IA.