Convex vs Supabase : backend réactif ou BaaS Postgres pour fondateurs indés

La réponse courte

Si on construit un SaaS classique en 2026, Supabase est le défaut le plus sûr. On obtient Postgres, un écosystème massif et un chemin de migration qui ne passe pas par une réécriture complète. Ce genre de détail compte plus qu'on ne le pense jusqu'au jour où la plateforme qu'on a choisie commence à ressembler à une cage.

Convex n'est pas un mauvais choix. C'est un choix intéressant. Le modèle réactif est élégant, la DX est serrée, et pour certains types de produits, il résout des problèmes que Supabase ne fait qu'approximer. Mais "certains types de produits" fait un gros boulot dans cette phrase. La plupart des SaaS indés n'ont pas besoin que chaque requête soit une subscription live. Ils ont besoin d'une base de données fiable, d'une facture prévisible et d'une communauté qui a déjà répondu à la question qu'on google à minuit.

Modèle de données : SQL relationnel vs documents réactifs

C'est la différence fondamentale. Tout le reste en découle.

Supabase donne du Postgres. Du vrai, du standard, du ennuyeux-dans-le-bon-sens-du-terme Postgres. On a SQL, les joins, les foreign keys, les migrations, les triggers, les views et des décennies de savoir accumulé. Si le produit a des utilisateurs, des équipes, des projets, des factures et des settings -- ce qui décrit environ 90 % des apps SaaS -- le modèle relationnel colle comme s'il avait été conçu pour ça. Parce que c'est le cas.

La fondation Postgres veut aussi dire qu'on accède à tout l'écosystème d'outillage construit par-dessus. Prisma, Drizzle, SQL brut, outils BI, data pipelines -- ils parlent tous Postgres. Le jour où on a besoin d'analytics, d'un dashboard de reporting ou de passer la base à quelqu'un côté data, rien n'a besoin d'être traduit.

Convex prend une approche différente. Sa base de données est orientée document, avec des tables qui stockent des objets JavaScript. Les requêtes sont des fonctions TypeScript qui tournent côté serveur. Pas de SQL. À la place, on écrit des fonctions comme db.query("messages").filter(q => q.eq(q.field("channelId"), channelId)) et la plateforme gère l'indexation et l'exécution.

Ce modèle a de vrais avantages. L'intégration TypeScript est sans couture -- les requêtes sont type-safe de bout en bout sans étape de codegen. Le modèle mental c'est "écrire une fonction, récupérer des données" plutôt que "écrire du SQL, mapper vers des types, gérer l'impedance mismatch". Pour les devs qui pensent en TypeScript et trouvent du SQL de la friction, Convex est remarquablement propre.

Le revers, c'est qu'on apprend un langage de requêtes propriétaire lié à une seule plateforme. SQL est une compétence qui se transfère partout. L'API de requêtes Convex se transfère... à Convex. Ce n'est pas une critique du design de l'API -- c'est une considération pratique sur où on investit son temps d'apprentissage.

Real-time : là où Convex brille vraiment

C'est l'argument de vente le plus fort de Convex. Et c'est pas serré.

Dans Convex, chaque requête est réactive par défaut. Quand les données changent, chaque client abonné à une requête qui touche ces données est mis à jour automatiquement. On n'opte pas dans le real-time. On ne configure pas de channels websocket. On ne met pas en place de listeners. Le système entier est construit autour de l'idée que l'UI devrait toujours refléter l'état actuel des données.

Pour les produits où le real-time compte -- outils collaboratifs, dashboards live, applications de chat, expériences multiplayer, toute app où plusieurs utilisateurs regardent et modifient les mêmes données -- c'est une simplification profonde. La quantité de plomberie qu'on n'a pas à écrire est significative. Pas de polling, pas de casse-tête d'invalidation de cache, pas de bugs de données stale. Ça marche.

Supabase a aussi des capacités real-time, construites par-dessus la réplication logique de Postgres. On peut s'abonner aux changements sur des tables spécifiques, filtrer par colonnes et recevoir des updates via websockets. Ça fonctionne, et pour beaucoup d'apps c'est parfaitement adéquat.

Mais le real-time de Supabase est une feature opt-in superposée à une base de données qui n'a pas été conçue autour de la réactivité. On doit réfléchir à quelles tables écouter, comment structurer les subscriptions, et comment gérer l'écart entre ce que la requête retourne et ce que le channel real-time délivre. C'est du real-time comme feature. Convex, c'est du real-time comme architecture.

Si le produit est un SaaS CRUD standard où les mises à jour se font en cycles request-response et qu'une notification real-time occasionnelle est un plus, l'approche de Supabase est plus que suffisante. Si l'expérience centrale du produit casse sans données live, l'approche de Convex évite de construire une couche real-time soi-même.

DX : deux types d'excellence différents

Les deux plateformes ont investi lourdement dans la DX, mais elles ont optimisé pour des choses différentes.

La DX de Convex est centrée sur la pureté TypeScript. Le schéma, les requêtes, les mutations et les actions sont du TypeScript. Le système de types coule depuis la définition du schéma à travers les server functions jusqu'aux React hooks. On renomme un champ dans le schéma et l'éditeur montre immédiatement chaque endroit à mettre à jour. Le serveur de dev local est rapide, et la boucle de feedback entre un changement de code et un résultat visible est serrée.

L'intégration React est particulièrement réussie. On appelle useQuery(api.messages.list, { channelId }) dans le composant et on obtient des données live et typées. Pas de gestion d'état de loading pour les updates suivants. Pas de refetch manuel. Le hook gère les subscriptions, la reconnexion et la consistance. Pour les devs React, ça se sent natif d'une façon que la plupart des intégrations backend n'atteignent pas.

La DX de Supabase est centrée sur la largeur et la familiarité. Le dashboard donne une interface visuelle pour la base, la config auth, les storage buckets et les edge functions. La client library JavaScript est propre et bien documentée. Les types TypeScript auto-générés depuis le schéma Postgres donnent la type safety sans langage de requêtes custom. Et parce que c'est du Postgres en dessous, tous les outils qu'on connaît déjà fonctionnent encore.

Supabase bénéficie aussi d'un pur momentum communautaire. La doc est complète, les discussions GitHub sont actives, et il y a des tutos pour quasiment chaque framework et use case imaginable. Quand on tombe sur un problème, quelqu'un l'a probablement déjà résolu et a écrit dessus. Ce genre de profondeur d'écosystème est un avantage compétitif qui se compose avec le temps.

Aucune des deux DX n'est objectivement meilleure. Convex se sent plus innovant et cohésif. Supabase se sent plus pratique et connecté au reste de l'écosystème. La préférence dépend de si on valorise l'intégration serrée ou la compatibilité large.

Auth et storage : l'avantage bundled de Supabase

Supabase embarque un système d'auth complet construit sur le Row Level Security de Postgres. Email, social logins, magic links, OTP par téléphone -- tout y est, et ça s'intègre directement avec les permissions de la base. On écrit une politique RLS et elle s'applique aux appels API, aux subscriptions real-time et aux requêtes directes. Un seul modèle de sécurité pour tout.

Le storage, c'est pareil. Supabase donne du stockage objet compatible S3 sécurisé par les mêmes politiques RLS qui protègent la base. Les règles d'upload, les permissions de téléchargement et le contrôle d'accès vivent dans le même système.

Convex gère l'auth via des intégrations avec des providers comme Clerk et Auth0 plutôt que de construire son propre système. C'est une approche raisonnable -- l'auth c'est dur et l'externaliser à un spécialiste fait sens -- mais ça implique une dépendance supplémentaire, une facture en plus et une intégration de plus à maintenir.

Pour le stockage de fichiers, Convex a un système intégré qui marche bien pour les besoins de base. C'est plus simple que le storage de Supabase mais aussi moins riche en fonctionnalités.

Si on veut une seule plateforme qui gère base de données, auth et storage sous un même toit avec un modèle de permissions unifié, Supabase a l'avantage ici. Si on préfère des services best-of-breed composés ensemble, l'approche de Convex est défendable.

Pricing : les deux commencent gratuits, mais les trajectoires divergent

Les deux plateformes offrent des free tiers généreux qui suffisent pour valider une idée et servir les premiers utilisateurs. Les deux ont des plans Pro qui commencent à $25 par mois. En surface, le pricing se ressemble.

La différence est dans la forme de la courbe de scaling.

Le pricing de Supabase est structuré autour de la taille de la base, de la bande passante, du storage et des MAU pour l'auth. Les dimensions sont compréhensibles. On peut regarder son dashboard d'usage et estimer la facture du mois prochain. Si les coûts montent trop, le self-hosting est une vraie option -- la plateforme entière est open source.

Le pricing de Convex scale avec les appels de fonctions, le storage de base de données et la bande passante. Parce que chaque requête est une subscription live qui se ré-exécute quand les données changent, la relation entre l'usage produit et le volume d'appels de fonctions est moins intuitive. Une feature qui a l'air simple -- disons un dashboard qui affiche des compteurs de projets en live -- pourrait générer significativement plus d'appels de fonctions qu'on ne l'imagine, parce que chaque changement de données déclenche la ré-évaluation de chaque subscription active qui touche ces données.

Ça ne veut pas dire que Convex est cher. Pour beaucoup d'apps, le free tier et les tiers Pro bas suffisent largement. Mais le modèle de coûts demande un raisonnement plus attentif sur ce que les patterns d'usage donnent vraiment en charge. Avec Supabase, une compréhension de base de la taille de la base et de la bande passante couvre l'essentiel pour une facture prévisible.

L'angle self-hosting compte aussi. Si le burn rate devient un sujet, Supabase donne une vraie soupape de sécurité. On peut faire tourner la stack entière sur sa propre infra. Convex est un service managé sans option de self-hosting. On paie leurs prix ou on s'en va.

Vendor lock-in : le sujet qui fâche

C'est là que la conversation devient inconfortable pour Convex.

Quitter Supabase, c'est exporter un dump Postgres. Le schéma, les données, les migrations -- tout se transfère vers n'importe quel hôte Postgres. AWS RDS, Neon, Railway, une VM nue. Le code applicatif change à peine. L'ORM fonctionne encore. Les requêtes fonctionnent encore. La porte de sortie est grande ouverte et bien éclairée.

Quitter Convex, c'est réécrire la couche d'accès aux données. La base est propriétaire. Le langage de requêtes est propriétaire. Le modèle de subscription réactive est propriétaire. Les server functions, les hooks côté client, le modèle de données -- tout est lié au runtime de Convex. La migration n'est pas une tâche. C'est un projet.

Pour un fondateur solo ou une petite équipe, cette asymétrie mérite un poids sérieux dans la décision. Les produits early-stage pivotent, scalent de façon imprévisible et doivent parfois faire des changements d'infra radicaux. Un backend qu'on peut quitter sans tout réécrire, c'est une assurance qu'on espère ne jamais utiliser mais qu'on sera content d'avoir le jour où.

Convex est conscient du sujet et construit des outils d'export pour rendre le modèle de données plus portable. Mais l'architecture fondamentale -- un runtime réactif propriétaire -- fait qu'il y aura toujours plus de friction à partir comparé à une plateforme construite sur un standard ouvert comme Postgres.

Maturité de l'écosystème : l'avantage qui se compose

Supabase existe depuis plus longtemps, a plus d'utilisateurs et repose sur Postgres, qui existe depuis des décennies. Ça se traduit en avantages concrets et pratiques.

Plus de tutos. Plus de réponses StackOverflow. Plus de billets de blog. Plus de templates de démarrage. Plus d'intégrations framework. Plus d'ORM qui marchent out of the box. Plus d'hébergeurs qui comprennent Postgres. Plus de consultants qui peuvent aider si on est bloqué. Plus de candidats qui connaissent déjà la stack.

Convex grandit. La communauté est engagée, le Discord est actif et la doc est bonne. Mais c'est encore une plateforme plus jeune avec une surface de connaissance communautaire plus petite. Si on tombe sur un edge case bizarre, on est peut-être le premier à le rencontrer. Si on a besoin d'embaucher quelqu'un qui connaît déjà la plateforme, le vivier est plus petit.

Pour les fondateurs indés qui construisent souvent seuls et comptent sur les réponses communautaires pour avancer vite, la profondeur d'écosystème n'est pas un luxe. C'est un multiplicateur sur un temps limité. L'avance de Supabase ici est réelle et se compose.

Server functions : mutations, actions et edge functions

Les server functions de Convex sont l'endroit où une grosse partie de la magie DX opère. On écrit des mutations (écritures transactionnelles), des queries (lectures réactives) et des actions (side effects comme l'appel d'API externes) en TypeScript. Elles tournent sur l'infra de Convex, sont automatiquement transactionnelles dans la base et s'intègrent sans couture avec le système de requêtes réactives.

La garantie transactionnelle mérite d'être soulignée. Dans Convex, une mutation réussit complètement ou échoue complètement. Pas de scénario "j'ai mis à jour la table A mais l'update de la table B a échoué". Pour les apps avec des patterns d'écriture complexes, c'est un vrai filet de sécurité qu'on devrait construire soi-même dans la plupart des autres environnements.

Côté serveur chez Supabase, on a les Edge Functions, qui tournent sur Deno à la périphérie. Elles sont rapides à déployer, bonnes pour les webhooks et les endpoints API légers, et simples à écrire. Mais elles n'ont pas la même intégration profonde avec la base que les functions de Convex. On appelle le client Supabase depuis la function plutôt que d'opérer à l'intérieur d'un runtime transactionnel.

Pour de la logique métier complexe qui a besoin de garanties de consistance forte, le modèle de fonctions de Convex est plus élégant. Pour des endpoints API simples et des handlers de webhook, les Edge Functions de Supabase sont parfaitement adéquates et tournent sur une plateforme bien comprise.

Quand choisir Convex

• L'expérience centrale du produit dépend de la réactivité real-time -- édition collaborative, feeds live, multiplayer ou dashboards en mise à jour constante.
• On est un dev TypeScript-first qui veut la type safety end-to-end sans SQL.
• On valorise les garanties transactionnelles et on les veut intégrées dans la plateforme.
• On construit quelque chose où le modèle réactif évite d'écrire une infra real-time significative soi-même.
• On est à l'aise avec une plateforme plus récente et un écosystème plus petit.
• Le vendor lock-in est un compromis qu'on accepte pour les gains en DX.

Quand choisir Supabase

• Le produit est un SaaS web standard où les patterns request-response couvrent l'essentiel du modèle d'interaction.
• On veut SQL, Postgres et la possibilité d'utiliser n'importe quel ORM ou outil de l'écosystème.
• On se soucie du risque de migration et on veut un chemin de sortie clair.
• On veut auth, storage et permissions de base de données unifiés sous un seul système.
• On valorise une grande communauté, une doc fournie et la sécurité d'une plateforme éprouvée.
• On veut l'option de self-host pour le contrôle des coûts ou la conformité.
• On travaille avec Next.js, SvelteKit, Nuxt ou un autre framework web moderne et on veut un support d'intégration large.

Verdict

Supabase est la recommandation qu'on ferait à la plupart des fondateurs indés sans trop hésiter. Postgres est une fondation sur laquelle on peut construire pendant des années. L'écosystème est assez profond pour répondre à quasiment toute question qu'on se posera. Le pricing est compréhensible. La porte de sortie est réelle. Et pour la grande majorité des produits SaaS, la combinaison base relationnelle, auth intégré, storage et edge functions couvre tout ce dont on a besoin.

Convex gagne sa place quand le real-time n'est pas une feature mais le produit. Si on construit quelque chose où les flux de données live sont l'expérience centrale, où chaque utilisateur voit les changements à la seconde où ils arrivent, où le modèle réactif économise des semaines d'infra custom -- alors l'approche de Convex n'est pas juste différente, elle est véritablement meilleure pour ce use case. La DX est excellente, l'intégration TypeScript est best-in-class et les garanties transactionnelles sont un vrai filet de sécurité.

Mais il faut être lucide sur ce qu'on échange. Un écosystème plus jeune, un runtime propriétaire et un chemin de migration qui se complique au fur et à mesure qu'on s'enfonce. Pour le bon produit, ces compromis en valent absolument la peine. Pour la plupart des produits, la fondation ennuyeuse, fiable et portable de Supabase est le pari le plus intelligent.