Convex vs Supabase : lequel choisir pour votre SaaS en 2026 ?

J'ai utilisé Convex sur Pixel-Mart, RendezApp et PLR Library.

J'ai utilisé Supabase sur Bloko.

Ce ne sont pas des concurrents directs. Ils résolvent des architectures différentes. Le mauvais choix ne t'empêche pas de builder — il te coûte du temps là où tu ne l'attendais pas.

La différence fondamentale

Supabase est une base PostgreSQL managée avec une API auto-générée, de l'auth, du storage et des realtime subscriptions. Tu penses en SQL. Tu écris des migrations. Tu utilises Prisma ou l'ORM de ton choix par-dessus.

Convex est un backend serverless TypeScript-first avec une base de données intégrée, des fonctions réactives et un moteur de scheduling. Tu penses en fonctions. Le schéma TypeScript est le schéma de base de données. Il n'y a pas de SQL.

Ce que Convex fait mieux

La réactivité native. Une query Convex est une subscription. Quand les données changent, l'UI se met à jour automatiquement — sans polling, sans WebSocket manuel, sans invalidation de cache.

// Ce composant se re-rend dès que les données changent en base.
// Aucune autre configuration.
const orders = useQuery(api.orders.list, { userId });

L'absence de boilerplate. Il n'y a pas de modèle ORM séparé. Le schéma Convex génère les types TypeScript. Doc<"orders"> est le type de tes commandes. Pas besoin de synchroniser un modèle Prisma avec un type manuel.

L'architecture correcte par construction. La distinction query / mutation / action force à ne jamais faire d'appels réseau dans une mutation, jamais accéder à la DB dans une httpAction. Ce ne sont pas des conventions — ce sont des erreurs de compilation.

query      → lecture, réactif, jamais d'appel réseau
mutation   → écriture, transactionnel, jamais d'appel réseau
action     → appels API externes, jamais de ctx.db direct

Le scheduling intégré. ctx.scheduler.runAfter(0, ...) depuis une mutation — l'action tourne en background sans configuration externe. Pas de BullMQ, pas de Redis, pas de worker séparé.

Le développement local. npx convex dev démarre un backend local complet avec tableau de bord. Pas de Docker, pas de configuration réseau.

Ce que Supabase fait mieux

Le SQL. Si ton domaine est naturellement relationnel — jointures complexes, vues matérialisées, agrégations sur gros volumes — PostgreSQL reste imbattable. Convex a ses propres indexes et ses queries, mais il ne fait pas des JOINs arbitraires.

L'écosystème PostgreSQL. Extensions, procédures stockées, foreign data wrappers, outils d'analyse — tout l'écosystème PostgreSQL est disponible. Supabase est PostgreSQL.

Les migrations versionnées. Prisma migrations, SQL migrations — les changements de schéma sont versionés, réversibles, déployables progressivement avec un contrôle granulaire. Convex gère les évolutions de schéma, mais avec moins de contrôle sur les migrations en production.

Le coût à grande échelle. Sur des volumes de données élevés, Supabase (PostgreSQL) est moins cher à opérer que Convex dont la facturation est basée sur les appels et le stockage.

Pourquoi j'ai choisi quoi

Pixel-Mart → Convex. Marketplace avec temps réel : statut des commandes visible instantanément par le vendeur et l'acheteur, notifications en push, gestion du panier. La réactivité native valait le choix.

RendezApp → Convex. Booking en temps réel : les créneaux disponibles se mettent à jour dès qu'une réservation est confirmée. Sans Convex, c'est du polling ou du WebSocket à maintenir.

Bloko → Supabase. Système d'escrow avec transactions financières critiques. La logique de balance vendeur, les transactions comptables, les rapports d'audit — c'est du SQL. La flexibilité de PostgreSQL et le versioning Prisma étaient nécessaires. C'est le bon choix pour ce domaine.

La règle de décision

L'UI doit refléter la DB en temps réel sans polling ?
→ Convex. La réactivité est native, pas une couche ajoutée.

Des requêtes relationnelles complexes ou un volume élevé ?
→ Supabase. PostgreSQL n'a pas d'équivalent pour ça.

DX maximale pour un MVP TypeScript ?
→ Convex. Zéro configuration, schéma = types.

Équipe familière avec SQL et les ORM ?
→ Supabase. L'écosystème leur est déjà connu.

Transactions financières critiques avec audit trail ?
→ Supabase. Le contrôle SQL sur les migrations l'emporte.

Ce qu'il ne faut pas faire

Choisir Convex parce que c'est "plus moderne". Choisir Supabase parce que c'est "plus connu".

La décision vient du domaine : est-ce que mes données sont naturellement relationnelles ? Est-ce que mon UI doit être réactive ? Quelle est la criticité de mes transactions ?

Ces questions ont des réponses. La réponse choisit l'outil.

→ Le tutoriel complet Moneroo + Next.js + Convex — code de production → Comment je travaille avec Claude Code au quotidien → Lancer un SaaS en Afrique francophone — les 7 spécificités