Avis sur Supabase : mon retour d’expérience après 14 mois d’utilisation (2026)

J'ai utilisé Supabase pendant 14 mois sur 6 projets clients, du MVP lancé en 3 semaines à une app B2B avec 15 000 utilisateurs actifs.

C'est rapide à démarrer, l'offre gratuite est bluffante, et l'idée d'avoir Postgres + auth + storage + real-time dans un seul package est séduisante. Mais après plusieurs mois en production, j'ai commencé à me poser ces questions :

• Est-ce que ça tient vraiment la route face à une charge croissante ?
• Row Level Security : puissant, mais est-ce que ça ne devient pas un casse-tête ?
• Quand faut-il rester avec Firebase, migrer vers du custom, ou choisir Supabase ?

Selon mon avis Supabase est un super outil de base de données notament quand on créer un MVP grâce aux applications de Vibecoding.

Dans cet article, je détaille ce que Supabase fait exceptionnellement bien, où il montre ses limites, et pour quels types de projets il est vraiment pertinent.

‍

#1 Qu'est-ce que Supabase ?

Supabase est un Backend-as-a-Service (BaaS) open-source qui permet de démarrer un projet web ou mobile sans construire son infrastructure serveur. C'est une alternative à Firebase, mais basée sur PostgreSQL et des technologies standard plutôt que propriétaires.

On y trouve une base de données relationnelle hébergée, un système d'authentification, du stockage de fichiers et des API REST/GraphQL auto-générées. Tout est accessible via des SDK ou directement depuis le frontend. Le temps réel est natif : dès qu'une donnée change en base, les clients connectés sont notifiés.

L'outil est pensé pour les développeurs qui veulent lancer rapidement un MVP ou un SaaS sans gérer l'infra backend. En revanche, il n'est pas conçu pour les non-techniques : il faut savoir coder et comprendre les bases de données pour en tirer parti.

‍

#2 Ce que j'aime dans Supabase

1. PostgreSQL complet, sans limitations artificielles

Contrairement à d'autres BaaS qui vous enferment dans leur propre système de données, Supabase vous donne accès à une vraie base PostgreSQL. Vous pouvez écrire du SQL brut, créer des triggers, des fonctions, des vues matérialisées, ou utiliser des extensions comme PostGIS pour de la géolocalisation.

J'ai migré un projet d'une base Firebase vers Supabase justement pour cette raison. J'avais besoin de requêtes complexes avec des jointures et des agrégations que Firestore ne pouvait pas gérer efficacement. Avec Supabase, j'ai pu écrire directement mes requêtes SQL dans l'éditeur intégré, tester les performances avec EXPLAIN, et optimiser avec des index. Tout ce qu'on attend d'une vraie base de données relationnelle.

Pour une PME qui a des besoins métier spécifiques ou qui veut éviter de se retrouver coincée par les limitations d'un système propriétaire, cette ouverture est précieuse. Vous n'êtes pas dépendant d'une API limitée. Vous avez le contrôle total de votre schéma et de vos requêtes.

2. APIs REST générées automatiquement depuis votre schéma

Dès que vous créez une table dans Supabase, une API REST complète est générée automatiquement. Pas besoin d'écrire de routes, de contrôleurs ou de logique CRUD. Vous pouvez immédiatement faire des SELECT, INSERT, UPDATE, DELETE depuis votre frontend avec des filtres, du tri, de la pagination.

Quand j'ai construit un prototype pour un client, j'ai créé 5 tables dans l'interface Supabase en 10 minutes. L'API était prête instantanément. J'ai pu connecter mon frontend React et afficher, filtrer et modifier les données sans écrire une seule ligne de backend. Pour un MVP ou une application interne, ce gain de temps est énorme.

L'API est aussi très flexible. On peut faire des requêtes avec des opérateurs like, in, or, des jointures entre tables, et même des appels de fonctions SQL custom. C'est beaucoup plus puissant que ce qu'on trouve dans la plupart des outils no-code, tout en restant simple à utiliser pour un développeur junior.

3. Une documentation exceptionnelle qui accélère la prise en main

La documentation de Supabase est l'une des meilleures que j'ai vues dans l'écosystème dev. Elle est claire, structurée, avec des exemples de code dans plusieurs langages (JavaScript, Python, Dart...), et surtout, elle couvre à la fois les cas simples et les scénarios avancés.

J'ai formé un développeur qui n'avait jamais utilisé Supabase. En deux heures, il était autonome sur la création de tables, la gestion de l'auth et les requêtes API. La documentation interactive avec des exemples copiables-collables a fait la différence. Il n'a eu besoin de me poser qu'une seule question sur le Row Level Security.

Il y a aussi des guides pour des use cases précis : comment gérer des uploads de fichiers, comment configurer une authentification avec Google, comment mettre en place du temps réel. Pas besoin de fouiller dans des forums ou Stack Overflow. Tout est là, testé et à jour. Pour une petite équipe sans expert backend, cette accessibilité réduit drastiquement le temps de mise en route.

4. Un free tier généreux qui vous laisse démarrer gratuitement

Le plan gratuit de Supabase inclut 500 Mo de base de données, 1 Go de stockage fichiers, 50 000 utilisateurs actifs mensuels, et 2 Go de bande passante. C'est largement suffisant pour tester, prototyper, ou même lancer une petite application en production sans débourser un euro.

J'ai fait tourner un outil interne pour un client sur le plan gratuit pendant 6 mois. On avait une vingtaine d'utilisateurs, quelques milliers de lignes en base, et ça n'a jamais ralenti. Quand on est passé à la facturation, le plan Pro à 25$/mois nous a suffi, et on a pu scaler sans surprise.

Le pricing est aussi transparent. Pas de coûts cachés basés sur le nombre de requêtes ou de lectures comme chez certains concurrents. Vous payez pour les ressources (CPU, RAM, stockage) et la bande passante. Pour une PME qui veut maîtriser son budget tech, cette prévisibilité est rassurante. Vous savez combien ça coûtera à mesure que vous grandissez.

5. Authentification complète prête à l'emploi

Supabase intègre un système d'authentification complet : inscription/connexion par email, magic links (sans mot de passe), OAuth avec Google, GitHub, Azure, et même de l'authentification par téléphone. Tout est configurable depuis le dashboard, sans code custom à écrire.

Sur un projet récent, j'ai ajouté la connexion Google et l'authentification par magic link en moins de 20 minutes. J'ai activé les providers dans les settings, copié quelques lignes de code dans mon frontend, et ça fonctionnait. Plus besoin de gérer des tokens JWT manuellement, des sessions, ou de sécuriser des endpoints. Supabase s'occupe de tout.

Le système s'intègre directement avec le Row Level Security (RLS) de PostgreSQL. On peut définir des règles SQL pour que chaque utilisateur ne puisse accéder qu'à ses propres données. C'est extrêmement puissant pour des applications multi-tenant ou des espaces clients. Vous avez une sécurité au niveau base de données, pas juste au niveau application, ce qui réduit les risques de fuite de données.

‍

#3 Ce que je n'ai pas aimé dans Supabase

1. La courbe d'apprentissage est raide pour les non-développeurs

Supabase se présente comme une alternative "simple" à Firebase, mais dans la réalité, c'est un outil qui demande de vraies compétences techniques. Si vous n'avez pas quelqu'un dans l'équipe qui maîtrise SQL et PostgreSQL, vous allez vite vous sentir perdu.

Contrairement à des outils no-code ou low-code, il n'y a pas vraiment d'interface visuelle pour construire sa base de données. Tout passe par du SQL brut ou par l'interface d'administration qui reste très technique.

Ce qui manque concrètement :

• Pas de constructeur visuel de base de données (tout se fait en SQL)
• Les Row Level Security policies demandent de comprendre PostgreSQL en profondeur
• La gestion des relations entre tables n'est pas assistée visuellement
• Les messages d'erreur sont souvent cryptiques pour un non-technique

Dans mon expérience, j'ai accompagné une PME qui voulait construire un portail client avec Supabase. Le fondateur, plutôt orienté business, pensait pouvoir configurer la base lui-même. Après deux semaines de blocages sur les permissions et les requêtes, on a dû faire appel à un développeur freelance. Ce qui devait être "rapide et simple" a fini par coûter 4 000€ en prestations externes.

Si vous n'avez pas de développeur en interne ou un budget pour externaliser, Supabase va être frustrant. Ce n'est pas un outil pour des équipes purement métier.

2. Les coûts deviennent vite imprévisibles en production

Supabase affiche des prix attractifs au départ : 25$/mois pour le plan Pro. Mais ce tarif ne reflète pas le coût réel une fois l'application en production, car tout ce qui compte (bande passante, stockage, compute) est facturé séparément.

Le plan Pro inclut :

• 8 Go de base de données
• 100 Go de bande passante
• 100 Go de stockage fichiers

Au-delà, chaque Go supplémentaire est facturé. Et ça peut vite monter :

• 0,125$/Go pour la base de données
• 0,09$/Go pour la bande passante
• 0,021$/Go pour le stockage

Sur un projet que j'ai suivi pour une marketplace B2B, on a démarré avec le plan Pro à 25$/mois. Trois mois plus tard, avec seulement 150 utilisateurs actifs mensuels, la facture était passée à 180$/mois. La raison : les images produits stockées sur Supabase Storage et les requêtes temps réel qui consommaient énormément de bande passante.

Le problème, c'est qu'il n'y a pas de système d'alerte vraiment clair avant de dépasser les quotas. On découvre le surcoût en fin de mois. Pour une PME qui gère un budget serré, cette imprévisibilité est un vrai point de friction.

3. Le support est limité en cas de problème critique

Le plan Pro inclut un "support email", mais dans la pratique, il ne faut pas s'attendre à une réactivité comparable à des solutions SaaS plus matures. J'ai eu plusieurs situations où le temps de réponse dépassait 48 heures, et les réponses restaient assez génériques.

Ce qui manque :

• Pas de support téléphone ou chat en temps réel (même sur les plans payants de base)
• Pas de SLA garanti sur le temps de résolution
• Les réponses renvoient souvent vers la documentation ou GitHub
• Le support "prioritaire" n'est disponible qu'à partir du plan Enterprise (sur devis, souvent 1000$+/mois)

J'ai vécu une situation où une API tombait en prod un vendredi après-midi. L'équipe ne comprenait pas pourquoi (c'était lié à une limite de connexions PostgreSQL). Le ticket de support est resté sans réponse jusqu'au lundi. Entre-temps, le service client de mon client était bloqué et on a perdu un week-end à chercher des workarounds.

La documentation et la communauté Discord sont excellentes pour des questions générales, mais si vous avez un incident critique en production, vous serez seul. Pour une PME qui dépend de son application pour tourner, c'est un risque réel. Il faut avoir les compétences techniques en interne pour débloquer la situation soi-même.

4. Les limitations du plan gratuit poussent vite vers les upgrades

Le plan gratuit de Supabase est généreux sur le papier : base PostgreSQL, authentification, storage, API. Mais il vient avec des contraintes qui le rendent impraticable dès qu'on sort du stade prototype.

Les limites qui posent problème :

• Le projet se met en pause automatiquement après 7 jours d'inactivité (il faut le réactiver manuellement)
• Pas de backups automatiques quotidiens (seulement des snapshots hebdomadaires gardés 7 jours)
• Limite stricte de 500 Mo de base de données et 1 Go de stockage fichiers
• Pas de support par email (uniquement communauté)

La pause automatique est le point le plus frustrant. J'ai testé Supabase sur un projet interne de gestion de leads. Après un week-end sans activité, l'application ne répondait plus. Il fallait se connecter au dashboard Supabase et cliquer sur "Resume" pour relancer le projet. Impossible de mettre ça en production, même pour un usage interne limité.

Et même en passant au plan Pro à 25$/mois, certaines fonctionnalités restent bridées : pas de log retention au-delà de 7 jours, pas de point-in-time recovery, pas de réplication entre régions. Ces features sont réservées au plan Enterprise, qui coûte facilement 10 fois plus cher.

En résumé, le plan gratuit est OK pour tester ou pour un side-project sans enjeu. Mais dès qu'on veut déployer quelque chose de sérieux, même à petite échelle, il faut passer direct sur le plan Pro. Et si on a besoin de fiabilité et de support, on se retrouve vite à devoir négocier un plan Enterprise qui n'est plus du tout dans la gamme de prix initiale.

‍

#4 Tarification Supabase (2026)

Supabase adopte un modèle de pricing hybride : base fixe + usage mesuré. Cette approche "pay as you grow" est séduisante sur le papier, mais nécessite une vraie compréhension des métriques pour éviter les mauvaises surprises.

Structure tarifaire

3 paliers accessibles + Enterprise :

• Free (0€) : 50K MAUs, 500 MB database, 1 GB storage. Limité à 2 projets actifs, pause après 1 semaine d'inactivité. Pour expérimenter, pas pour produire.
• Pro (25$/mois) : 100K MAUs, 8 GB database, 100 GB storage + 10$ de compute credits (= 1 instance Micro). Projets additionnels à 10$/mois.
• Team (599$/mois) : Même base que Pro, mais avec SOC2, SSO, backups 14 jours, support prioritaire. Pour entreprises avec contraintes de conformité.
• Enterprise (custom) : SLAs, support 24/7, BYO Cloud, custom compute.

Les add-ons qui font grimper la facture

Compute (obligatoire en prod) :

• Micro (1 GB RAM) : 10$/mois – couvert par les crédits sur Pro
• Small (2 GB RAM) : 15$/mois – recommandé dès 10K+ MAUs
• Medium (4 GB RAM) : 60$/mois – nécessaire pour apps avec trafic réel
• Large (8 GB RAM) : 110$/mois – à partir de 50K+ MAUs actifs

Add-ons quasi-indispensables en production :

• Point in Time Recovery : +100$/mois (7 jours de rétention). Indispensable pour toute app critique.
• Log Drains : +60$/mois par drain. Nécessaire si vous centralisez vos logs (Datadog, Logflare, etc.).
• Custom Domain : +10$/mois par projet. Pour une URL branded (api.votre-entreprise.com).

Add-ons optionnels :

• Advanced MFA (Phone) : +75$/mois (1er projet) puis +10$/mois par projet additionnel
• SSO (SAML) : 50 MAUs inclus puis 0.015$/MAU (seulement sur Team+)

Ce que vous paierez vraiment

Projet solo / proof of concept :

• Plan Pro : 25$/mois
• Compute Micro (couvert par crédits) : 0$
• Total : 25$/mois

Équipe de 5 personnes (app B2B, 10K MAUs, 2 environnements) :

• Plan Pro : 25$/mois
• Compute Small (prod) : 15$/mois → 5$ au-delà des crédits
• Projet staging : 10$/mois + Compute Micro (couvert)
• Point in Time Recovery (prod) : 100$/mois
• Custom Domain : 10$/mois
• Total : 150$/mois (30$/mois/personne)

Équipe de 15 personnes (app SaaS, 50K MAUs, 3 environnements) :

• Plan Pro : 25$/mois
• Compute Medium (prod) : 60$/mois → 50$ au-delà des crédits
• 2 projets additionnels (staging + dev) : 2 × 10$ = 20$/mois
• Compute staging (Micro) : couvert par crédits du projet
• Point in Time Recovery : 100$/mois
• Log Drain : 60$/mois
• Custom Domain (prod) : 10$/mois
• Storage dépassement (20 GB au-delà) : 20 × 0.0213$ = 0.43$/mois
• Total : ~265$/mois (~18$/mois/personne)

Si vous dépassez 100K MAUs : +162.50$/mois pour 50K MAUs additionnels (50K × 0.00325$).

Verdict

Supabase est ultra-compétitif pour des projets en phase de croissance. Le modèle "pay as you grow" permet de démarrer à 25$/mois et de scaler progressivement. Mais attention : la facture peut rapidement grimper si vous ajoutez les add-ons production (PITR, Log Drains, compute plus puissant).

Pour un usage réel en PME B2B, comptez plutôt 150–300$/mois (selon le trafic), soit environ 15–20$/mois par développeur dans l'équipe. C'est moins cher que Firebase/AWS Amplify dès que vous sortez des free tiers, et vous gardez un vrai Postgres sous le capot.

Pour qui c'est adapté : startups et PME tech qui veulent un backend moderne (Postgres + Auth + Storage + Realtime) sans gérer l'infra. Idéal pour des apps SaaS, marketplaces, dashboards internes. Le coût par utilisateur actif (0.00325$ au-delà de 100K) reste très raisonnable.

Attention : le saut à 599$/mois (Team) arrive vite si vous avez besoin de SOC2 ou SSO Dashboard. À ce niveau, vérifiez si vous n'auriez pas intérêt à self-host (Supabase est open source) ou à passer sur Enterprise pour négocier un tarif volume.

À partir de quand ça devient cher : si vous avez plusieurs apps en production avec des compute Large+ (110$/mois), ou si vous dépassez régulièrement 200K MAUs. Au-delà de 500$/mois de facture totale, il est temps de contacter l'équipe Enterprise pour voir si un pricing sur mesure est possible.

‍

#5 Comment Supabase se compare aux alternatives

Voici comment Supabase se positionne face aux principales alternatives :

‍

En résumé

Firebase : le choix évident si vous êtes déjà dans l'écosystème Google ou si vous cherchez la solution la plus mature. En contrepartie, vous êtes lié à une base NoSQL et à l'infrastructure Google.

AWS Amplify : idéal si vous utilisez déjà AWS et que vous avez besoin de scalabilité maximale. Complexité plus élevée que Supabase, courbe d'apprentissage plus raide.

Appwrite : l'alternative directe si vous voulez héberger vous-même. Open-source complet, mais vous gérez vous-même la maintenance et les mises à jour.

PocketBase : parfait pour les projets simples ou les MVP rapides. Extrêmement léger mais moins adapté aux applications complexes avec équipes multiples.

Nhost : une bonne option si vous préférez GraphQL à REST. Architecture très proche de Supabase, avec Hasura pour la gestion des API.

Convex : excellent si vous voulez tout écrire en TypeScript et privilégiez l'expérience développeur. Approche différente, plus opiniâtre que Supabase.

‍

#6 Pour qui Supabase est-il fait ?

✓ Supabase est un bon choix si :

• Vous avez au moins un développeur à l'aise avec SQL et JavaScript/TypeScript dans l'équipe
• Vous construisez un MVP, un SaaS ou une application qui nécessite une base relationnelle (clients, projets, commandes...)
• Vous voulez un backend prêt à l'emploi (auth, API, stockage) sans dépendre d'un écosystème propriétaire comme Firebase

✗ Supabase n'est PAS le bon choix si :

• Vous n'avez aucune compétence technique en interne et comptez uniquement sur du no-code (privilégiez Airtable ou Notion)
• Votre application repose massivement sur des données non structurées ou du traitement temps réel complexe (considérez Firebase ou un backend custom)
• Vous avez besoin d'un écosystème riche avec intégrations natives (auth sociale avancée, analytics, push...) sans développement supplémentaire