tl;dr
Supabase est un excellent choix par défaut pour la plupart des projets indie — vous avez Postgres, l'auth, le stockage et les edge functions avec une bonne expérience développeur. Mais le tier gratuit met votre base en pause après inactivité, le plan Pro démarre à 25 $/mois, et vous restez sur l'infrastructure de quelqu'un d'autre. Voici ce qui existe d'autre et quand chaque option a plus de sens.
Pourquoi les fondateurs cherchent des alternatives à Supabase
Supabase est devenu populaire pour de bonnes raisons. Il a pris la formule Firebase — auth, base de données, stockage, fonctions dans un seul SDK — et l'a reconstruit sur Postgres. Open source, basé sur SQL, auto-hébergeable. Pour les développeurs web venant du monde Firebase, c'était une bouffée d'air frais.
Mais à mesure que votre projet grandit, des frictions apparaissent.
Le tier gratuit est généreux pour les projets actifs, mais il met votre base en pause après sept jours d'inactivité. Pour les side projects et les outils internes, c'est agaçant. Vous allez vérifier quelque chose et votre base est endormie. Le réveil prend une minute. Pas rédhibitoire, mais ça envoie le signal que les utilisateurs du tier gratuit sont des citoyens de seconde classe.
Le saut de prix est le vrai problème. De gratuit à 25 $/mois, c'est un pas significatif pour un projet qui ne rapporte peut-être rien. Et le compute inclus dans le plan Pro (2 cœurs CPU, 1 Go RAM) peut se sentir serré pour tout ce qui a du trafic modéré. Besoin de plus ? Les add-ons de compute commencent à 5 $/mois et grimpent vite.
Le Row Level Security (RLS), bien que puissant, a une courbe d'apprentissage. Écrire des politiques Postgres pour contrôler l'accès aux données est plus complexe que les security rules de Firebase, et débugger les problèmes de RLS n'est pas une partie de plaisir. Beaucoup de développeurs finissent avec des politiques soit trop permissives (risque de sécurité), soit trop restrictives (fonctionnalités cassées).
Rien de tout cela ne signifie que Supabase est mauvais. Ça signifie qu'il a des compromis, comme tout le reste. Les alternatives ci-dessous optimisent pour des priorités différentes.
Comment nous avons évalué ces alternatives
Chaque outil a été jugé sur ce dont un développeur solo ou une petite équipe a réellement besoin :
- Temps jusqu'à la première requête : À quelle vitesse peut-on passer de l'inscription à des données en base ?
- Expérience développeur : Qualité de la documentation, des SDKs et du typage ?
- Viabilité du tier gratuit : Peut-on faire tourner un vrai side project sans payer ?
- Trajectoire de scaling : Que se passe-t-il quand on passe de 100 à 10 000 utilisateurs ?
- Risque de lock-in : À quel point est-ce difficile de partir si nécessaire ?
Nous avons spécifiquement regardé cela du point de vue des fondateurs bootstrapés et développeurs indie qui construisent des produits SaaS, pas des équipes enterprise avec des départements DevOps.
Analyse détaillée : ce que chaque alternative fait de mieux
Firebase — l'incumbent que vous connaissez déjà
Firebase est là où la plupart des développeurs découvrent le concept de backend-as-a-service. Firestore vous donne une base de données NoSQL à documents avec des listeners temps réel. L'authentification supporte email, Google, Apple, téléphone et providers sociaux nativement. Cloud Functions exécutent de la logique côté serveur. L'Hosting sert votre frontend.
La sync temps réel de Firestore est réellement magique pour certains cas d'usage. Construisez une app de chat, un éditeur collaboratif ou un dashboard en direct, et les listeners onSnapshot de Firestore gardent tout synchronisé sans écrire la moindre ligne de WebSocket. Les SDKs pour Flutter, iOS et Android sont éprouvés à très grande échelle.
Mais Firestore est NoSQL, et ça compte plus qu'on ne le pense. Pas de jointures. Pas d'agrégations sans dénormalisation. La modélisation de données en Firestore exige de penser différemment votre schéma, en dupliquant les données entre collections pour éviter des lectures coûteuses. Si vous venez d'un background SQL, c'est frustrant.
Le modèle de coût est aussi piégeux. Firestore facture par opération de lecture, écriture et suppression. Un écran qui affiche 50 items effectue 50 lectures. Rafraîchissez la page, encore 50 lectures. Ça rend les coûts difficiles à prévoir et parfois choquants quand une requête mal optimisée s'emballe.
Le vendor lock-in est le problème qu'on évite de regarder en face. Le modèle de données de Firestore, les security rules et les SDKs sont propriétaires. Migrer hors de Firebase signifie réécrire votre couche de données, votre auth et votre logique de sécurité. Ce n'est pas une petite tâche.
Qui devrait choisir Firebase : Les développeurs mobile utilisant Flutter ou des SDKs natifs qui ont besoin de sync temps réel et peuvent vivre avec les compromis du NoSQL.
PocketBase — le binaire unique qui remplace tout
PocketBase est l'entrée la plus opinionée de cette liste, et c'est peut-être la meilleure pour les développeurs solo.
Téléchargez un seul binaire Go (environ 30 Mo). Lancez-le. Vous avez maintenant une base de données relationnelle type Postgres (en réalité SQLite), l'authentification utilisateur avec email/mot de passe et OAuth2, le stockage de fichiers, des subscriptions temps réel via Server-Sent Events, et un dashboard admin pour tout gérer. Pas de Docker. Pas de variables d'environnement. Pas de configuration d'infrastructure.
L'expérience développeur est remarquablement simple. Définissez des collections (tables) dans l'UI admin ou via des migrations. Interrogez les données avec une API REST directe ou les SDKs JavaScript/Dart. L'authentification fonctionne tout simplement — enregistrez des utilisateurs, connectez-les, gérez les sessions. Les uploads de fichiers s'attachent aux enregistrements.
SQLite sous le capot signifie zéro gestion de base de données. Les sauvegardes consistent littéralement à copier un fichier. Le développement local est identique à la production. Il n'y a pas de fossé « ça marche sur ma machine mais pas en prod » parce que l'ensemble du backend est le même binaire unique partout.
La limitation, c'est l'échelle. PocketBase tourne comme un processus unique. Il gère bien les lectures concurrentes (SQLite est rapide en lecture), mais la forte concurrence en écriture sur une seule base SQLite a des limites inhérentes. Pour une app SaaS typique avec quelques milliers d'utilisateurs actifs quotidiens, c'est très bien. Pour une app qui doit gérer des milliers d'écritures concurrentes par seconde, il faut une autre architecture.
Il n'y a pas d'edge functions ni de compute serverless intégrés. Si vous avez besoin de logique côté serveur au-delà de ce que les règles API fournissent, vous étendez PocketBase avec des hooks Go ou faites tourner des services séparés à côté.
Qui devrait choisir PocketBase : Les développeurs solo qui veulent le backend auto-hébergé le plus simple possible avec un minimum de préoccupations d'infrastructure.
Appwrite — le pari de la plateforme open source
Appwrite se positionne comme une alternative open source à Firebase/Supabase avec toutes les fonctionnalités incluses. Bases de données, authentification, stockage, fonctions serverless, subscriptions temps réel et messagerie — tout dans une seule plateforme. Auto-hébergez avec Docker ou utilisez leur cloud managé.
L'étendue des fonctionnalités est impressionnante. L'auth supporte 30+ providers OAuth. La base de données supporte les documents relationnels avec des données imbriquées. Les fonctions serverless tournent en Node.js, Python, PHP, Ruby, Dart et plus encore. Le service de messagerie gère les push notifications, SMS et emails. Pour un développeur solo qui a besoin de tout ça, les avoir sur une seule plateforme avec un seul SDK a de la valeur.
Le prix du cloud managé est simple à 15 $/mois par membre d'équipe sur le plan Pro. Le tier gratuit vous donne 75 000 requêtes mensuelles, 2 Go de stockage et 3 bases de données. Pour un side project, le tier gratuit est adéquat.
Là où Appwrite diffère de Supabase, c'est la base de données. Appwrite utilise MariaDB sous le capot, pas Postgres. Pour la plupart des cas d'usage, ça ne change rien. Mais si vous dépendez de fonctionnalités spécifiques à Postgres (comme les requêtes jsonb, la recherche full-text ou PostGIS), elles vous manqueront. L'interface de requête MariaDB dans Appwrite est aussi plus abstraite que l'accès direct Postgres de Supabase.
L'auto-hébergement d'Appwrite nécessite Docker et est plus complexe que le binaire unique de PocketBase. Vous gérez plusieurs conteneurs (base de données, API, workers, schedulers). La documentation est bonne, mais le passage en production demande des connaissances DevOps.
Qui devrait choisir Appwrite : Les développeurs qui veulent un BaaS open source complet avec auto-hébergement Docker et support multi-langages pour les fonctions.
Nhost — pour le développement GraphQL-first
Nhost vous donne Postgres avec Hasura par-dessus. Hasura auto-génère une API GraphQL depuis votre schéma de base de données. Définissez vos tables, configurez les permissions, et vous avez une API GraphQL entièrement typée avec queries, mutations et subscriptions temps réel. Pas de code API à écrire.
Pour les développeurs qui préfèrent GraphQL au REST, c'est convaincant. Le langage de requête s'adapte naturellement aux composants UI — vous demandez exactement les données dont vous avez besoin pour chaque écran. Le système de permissions de Hasura est puissant, permettant de définir l'accès au niveau des lignes et des colonnes selon les rôles utilisateurs et les variables de session.
Nhost inclut aussi l'auth (basée sur Hasura Auth), le stockage et les fonctions serverless. Comme il utilise du Postgres standard, votre schéma est portable. Les migrations fonctionnent de la même manière que Supabase ou toute autre plateforme basée sur Postgres.
Le compromis, c'est la complexité. GraphQL a une courbe d'apprentissage. Le modèle de permissions de Hasura est différent des politiques RLS de Supabase. Et pour les applications qui ont juste besoin d'opérations CRUD simples, GraphQL ajoute de l'overhead en outillage (il vous faut un client GraphQL comme Apollo ou urql) et en modèle mental sans bénéfice proportionnel.
La communauté et l'écosystème sont plus petits que ceux de Supabase. Moins de tutoriels, moins de réponses Stack Overflow, moins d'intégrations tierces. Si vous rencontrez un problème, vous avez plus de chances de lire les docs Hasura et les issues GitHub que de trouver une solution toute faite.
Qui devrait choisir Nhost : Les développeurs qui préfèrent GraphQL et veulent la génération automatique d'API depuis leur schéma Postgres.
Convex — pour le temps réel sans y penser
Convex adopte une approche fondamentalement différente du développement backend. Au lieu de vous donner une base de données et une couche API, il vous donne un document store réactif où tout est temps réel par défaut.
Vous écrivez des fonctions TypeScript qui définissent vos queries et mutations. Elles tournent sur les serveurs Convex. Côté frontend, vous appelez ces fonctions avec des hooks React, et elles se re-rendent automatiquement quand les données sous-jacentes changent. Pas de polling. Pas de gestion WebSocket. Pas de données périmées. Le composant affiche simplement l'état actuel, toujours.
Ce n'est pas juste des subscriptions temps réel boulonnées sur une base de données. L'architecture entière est construite autour de la réactivité. Les queries sont des fonctions déterministes que Convex peut cacher et invalider automatiquement. Les fonctions planifiées remplacent les cron jobs. La recherche full-text est intégrée. Le stockage de fichiers fonctionne sans configurer de buckets.
L'expérience développeur pour construire des applications interactives, collaboratives ou type dashboard est réellement bonne. Le typage TypeScript de bout en bout signifie que votre frontend et backend sont toujours en sync au niveau des types.
L'inquiétude, c'est le lock-in. Le modèle de données de Convex est propriétaire. Votre logique backend tourne sur leur infrastructure. Si vous devez migrer, vous réécrivez votre backend entier, pas juste un changement de chaîne de connexion. Pour un side project, ça n'a peut-être pas d'importance. Pour un produit que vous comptez bootstraper jusqu'à la ramen profitability, la dépendance mérite réflexion.
Qui devrait choisir Convex : Les développeurs qui construisent des apps collaboratives temps réel, des dashboards ou toute UI où la fraîcheur des données est critique.
Turso + Drizzle — pour les développeurs obsédés par l'edge
Ce n'est pas une plateforme unique mais une combinaison qui a gagné en traction parmi les développeurs qui veulent des bases SQL proches de leurs utilisateurs.
Turso fournit des bases libSQL (un fork de SQLite maintenu par l'équipe Turso) qui se répliquent vers des emplacements edge dans le monde entier. Votre base principale vit dans une région. Les réplicas de lecture sont automatiquement distribués mondialement. Un utilisateur à Tokyo obtient des lectures sub-10 ms depuis un réplica proche, pas des allers-retours de 200 ms vers un serveur en Virginie.
Drizzle ORM se place par-dessus, vous donnant des requêtes SQL entièrement typées en TypeScript. Il génère zéro overhead runtime — Drizzle compile en SQL brut, donc pas de pénalité de performance ORM. La définition du schéma est en TypeScript, les requêtes sont en TypeScript, les résultats sont typés. L'expérience développeur est excellente pour les projets TypeScript-heavy.
Le hic, c'est que c'est une base de données et un ORM, pas une plateforme backend. Il n'y a pas d'auth intégrée, pas de stockage de fichiers, pas de fonctions serverless. Vous assemblez tout vous-même — Lucia ou Clerk pour l'auth, Cloudflare R2 ou S3 pour le stockage, Cloudflare Workers ou Deno Deploy pour le compute. Ça vous donne une flexibilité maximale mais demande plus de décisions architecturales en amont.
Pour les développeurs qui aiment choisir leurs propres outils et veulent des performances edge computing sans la complexité des bases de données distribuées traditionnelles, Turso + Drizzle est une fondation convaincante.
Qui devrait choisir cette combinaison : Les développeurs qui privilégient la latence de lecture, veulent du SQL complet en edge et sont à l'aise pour assembler leur propre stack backend.
Quand rester sur Supabase
Supabase reste le bon choix par défaut pour beaucoup de projets :
- Vous voulez Postgres avec auth, stockage et fonctions dans un seul SDK
- Vous préférez SQL et la modélisation relationnelle au NoSQL
- Vous valorisez l'open source et l'option de vous auto-héberger plus tard
- Votre projet génère assez de revenus ou de trafic pour justifier le plan Pro à 25 $/mois
- Vous voulez une communauté active avec des tutoriels et exemples extensifs
L'écosystème Supabase est large et en croissance. L'expérience de développement local avec la CLI Supabase est bonne. Le chemin de migration du gratuit au payant est direct. Pour la plupart des applications web construites avec Next.js, Nuxt ou SvelteKit, Supabase est un choix par défaut sensé sur lequel vous pouvez construire longtemps.
Choisir votre backend : un cadre de décision
- Quel est votre cas d'usage principal ? App collaborative temps réel : Convex ou Firebase. SaaS orienté contenu : Supabase ou Nhost. App CRUD simple : PocketBase.
- Combien d'infrastructure voulez-vous gérer ? Zéro : Firebase, Convex ou Supabase Cloud. Un peu : PocketBase sur un VPS. Beaucoup : Appwrite ou Supabase auto-hébergé.
- Quel modèle de base de données préférez-vous ? SQL : Supabase, Nhost, Turso. NoSQL : Firebase, Convex. SQLite : PocketBase, Turso.
- Quel est votre budget ? Zéro euro : PocketBase auto-hébergé. Moins de 25 $/mois : Supabase gratuit, Firebase Spark, Turso gratuit, Convex gratuit. Plus de 25 $/mois : n'importe lequel en plan payant.
- Quelle importance a la stratégie de sortie ? Portabilité maximale : PocketBase (vos données sont un fichier SQLite) ou Supabase (Postgres standard). Moins portable : Firebase (NoSQL propriétaire) ou Convex (modèle réactif propriétaire).
Il n'y a pas de mauvaise réponse si vous choisissez honnêtement selon vos besoins réels. La mauvaise réponse, c'est de choisir en suivant la hype et de se battre contre la plateforme pendant six mois.
| feature | Supabase | Firebase | PocketBase | Appwrite | Nhost | Convex | Turso + Drizzle |
|---|---|---|---|---|---|---|---|
| Type de base de données | Postgres | Firestore (NoSQL) | SQLite | MariaDB | Postgres (Hasura) | Custom (réactif) | libSQL (fork SQLite) |
| Auth intégrée | Oui | Oui | Oui | Oui | Oui | Oui | Non (Lucia, Clerk, etc.) |
| Temps réel | Oui (changements Postgres) | Oui (natif) | Oui (SSE) | Oui | Oui (subs GraphQL) | Oui (fonctionnalité cœur) | Non (à construire soi-même) |
| Auto-hébergeable | Oui (Docker) | Non | Oui (binaire unique) | Oui (Docker) | Oui (Docker) | Non | Turso : Non / Drizzle : N/A |
| Limites du tier gratuit | 500 Mo BDD, 1 Go stockage | Généreux (à l'usage) | Illimité (auto-hébergé) | 75K requêtes/mois | 1 projet | Tier hobby généreux | 500 BDD, 9 Go stockage |
| Edge functions | Oui (basées sur Deno) | Cloud Functions | Non | Oui (serverless) | Oui (serverless) | Oui (TypeScript) | Non (coupler avec Cloudflare Workers) |
Alternatives recommandees
Firebase
Backend-as-a-service de Google avec Firestore (NoSQL), Authentication, Cloud Functions, Hosting et un écosystème massif. Le BaaS originel que Supabase a été construit pour remplacer.
pricing: Tier gratuit généreux (plan Spark). Pay-as-you-go (plan Blaze) à partir de 0 $.
pros
- + La sync temps réel fonctionne nativement avec les listeners Firestore
- + Éprouvé à très grande échelle — l'infrastructure Google derrière
- + Excellents SDKs Flutter, iOS et Android pour le développement mobile
cons
- - Le modèle NoSQL (Firestore) vous force à penser en documents, pas en tables
- - Le vendor lock-in est sévère — migrer hors de Firebase est douloureux
- - Les coûts peuvent grimper de façon imprévisible avec des charges lourdes en lecture/écriture
PocketBase
Backend open source en un seul binaire Go. Base SQLite, auth, stockage de fichiers et abonnements temps réel. Téléchargez un fichier, lancez-le, et vous avez un backend.
pricing: Gratuit et open source. Auto-hébergement sur un VPS à 5-10 $/mois.
pros
- + Déploiement ridiculement simple — un binaire, une commande, un backend qui tourne
- + Dashboard admin intégré pour gérer les collections, utilisateurs et données
- + SQLite signifie zéro configuration de base de données et des sauvegardes triviales (copier un fichier)
cons
- - Architecture mono-serveur — le scaling horizontal n'est pas simple
- - Écosystème et communauté plus petits que Supabase ou Firebase
- - Pas d'edge functions ni de compute serverless intégrés
Appwrite
Plateforme backend open source avec bases de données, auth, stockage, fonctions et messagerie. Auto-hébergeable ou en cloud managé. Positionné comme le Firebase open source.
pricing: Tier gratuit (75K requêtes/mois). Pro 15 $/mois par membre. Auto-hébergement gratuit.
pros
- + Plateforme complète — auth, base de données, stockage, fonctions et messagerie
- + Auto-hébergeable avec Docker pour un contrôle total des données
- + SDKs pour 10+ plateformes dont Flutter, React Native et les langages côté serveur
cons
- - La plateforme cloud est plus récente et moins éprouvée que Supabase ou Firebase
- - Utilise MariaDB sous le capot, pas Postgres — dialecte SQL et écosystème différents
- - L'auto-hébergement nécessite de gérer des conteneurs Docker et les mises à jour
Nhost
Backend open source construit sur Hasura GraphQL et Postgres. Vous donne une API GraphQL sur votre base automatiquement, avec auth, stockage et fonctions serverless.
pricing: Tier gratuit (1 projet). Pro 25 $/mois. Auto-hébergement gratuit.
pros
- + API GraphQL générée automatiquement depuis votre schéma Postgres
- + Le moteur Hasura fournit des subscriptions temps réel et des capacités de requêtes puissantes
- + Compatible avec les migrations Supabase — même Postgres sous-jacent
cons
- - GraphQL ajoute de la complexité si votre app n'a besoin que de CRUD simple
- - Hasura a sa propre courbe d'apprentissage en plus de Postgres
- - Communauté plus petite que Supabase — moins de tutoriels et de réponses Stack Overflow
Convex
Plateforme backend réactive où vos données sont en temps réel par défaut. Écrivez des fonctions TypeScript qui tournent côté serveur et synchronisent automatiquement l'état vers votre frontend.
pricing: Tier gratuit (généreux pour le hobby). Pro 25 $/mois. Pay-as-you-go au-delà.
pros
- + Sync temps réel automatique — pas de polling, pas de WebSocket à configurer, pas d'invalidation de cache
- + TypeScript de bout en bout avec typage complet entre frontend et backend
- + Fonctions planifiées, stockage de fichiers et recherche intégrés
cons
- - Modèle de données propriétaire — ni SQL, ni NoSQL traditionnel
- - Vendor lock-in — votre logique backend tourne sur l'infrastructure Convex
- - Plateforme plus jeune — moins éprouvée à l'échelle que Supabase ou Firebase
Turso + Drizzle
SQLite en edge via libSQL, couplé à Drizzle ORM pour des requêtes typées. Bases de données répliquées mondialement pour des lectures basse latence de n'importe où.
pricing: Tier gratuit Turso (500 bases, 9 Go stockage). Scaler 29 $/mois. Drizzle est gratuit/open source.
pros
- + Bases répliquées en edge — lectures sub-10 ms depuis n'importe où dans le monde
- + Drizzle ORM donne un typage TypeScript complet avec zéro overhead runtime
- + Compatibilité SQLite signifie développement local et tests simples
cons
- - Pas d'auth, stockage ou fonctions intégrés — vous assemblez tout vous-même
- - SQLite a des limitations pour les requêtes complexes et les écritures concurrentes
- - Nécessite plus de décisions d'architecture qu'un BaaS tout-en-un
FAQ
Pourquoi les gens quittent Supabase ?+
Les plaintes les plus courantes sont la mise en pause du tier gratuit après une semaine d'inactivité, le saut de prix entre le gratuit et le plan Pro à 25 $/mois avec peu de compute inclus, et la complexité des politiques Row Level Security pour l'autorisation. Certains développeurs trouvent aussi que le temps réel Postgres est moins fluide que les listeners Firestore ou la sync automatique de Convex. La plateforme est excellente, mais le palier de prix et la pause frustrent les projets hobby et side projects.
PocketBase est-il prêt pour la production ?+
PocketBase est utilisé en production par de nombreux développeurs solo et petites équipes. Le backend SQLite gère bien les lectures concurrentes et l'auth et le stockage intégrés fonctionnent de manière fiable. La limitation principale est le scaling horizontal — PocketBase tourne comme un processus unique sur un seul serveur. Pour des apps avec moins de 10 000 utilisateurs actifs quotidiens et des charges d'écriture modérées, ça fonctionne très bien. Pour des apps nécessitant du multi-région ou une forte concurrence en écriture, il faut une autre architecture.
Faut-il choisir Firebase ou Supabase pour un nouveau projet ?+
Choisissez Supabase si vous voulez du SQL et Postgres, préférez l'open source ou prévoyez de vous auto-héberger. Choisissez Firebase si vous construisez une app mobile avec Flutter ou des SDKs natifs, avez besoin de sync temps réel éprouvée, ou êtes déjà dans l'écosystème Google Cloud. Pour les apps web construites avec Next.js ou des frameworks similaires, Supabase offre généralement une meilleure ergonomie développeur. Pour les apps mobile-first, les SDKs Firebase sont plus matures.
Quelle est l'alternative Supabase la moins chère pour un side project ?+
PocketBase sur un VPS à 5 $/mois (comme Hetzner ou un petit droplet DigitalOcean) est l'option la moins chère qui vous donne un vrai backend avec auth et stockage. Si vous avez juste besoin d'une base de données, le tier gratuit de Turso vous donne 500 bases avec 9 Go de stockage total. Pour un coût zéro, PocketBase sur une instance gratuite Oracle Cloud ou le tier gratuit de Railway fonctionne pour les projets hobby.
Peut-on migrer facilement depuis Supabase vers une autre plateforme ?+
Parce que Supabase utilise du Postgres standard, la migration des données est directe — pg_dump et pg_restore fonctionnent. Votre schéma SQL, vos fonctions et triggers sont portables. Les parties plus difficiles sont l'auth (migration des comptes utilisateurs et des hashs de mots de passe), le stockage (déplacement des fichiers et mise à jour des URLs) et les fonctionnalités spécifiques à Supabase comme les Edge Functions ou les politiques Row Level Security. Migrer de Supabase vers une autre plateforme basée sur Postgres comme Nhost est plus facile que migrer vers Firebase ou Convex.