Stack technique
Convex vs Supabase : la vraie comparaison pour ton SaaS
Convex ou Supabase pour ton backend SaaS ? Comparaison honnête : modèle de données, realtime, type safety, pricing, vendor lock-in. Décide en connaissance de cause.
Quand tu démarres un SaaS, le choix du backend pèse plus que celui du framework front. Tu vas vivre avec pendant des années, et migrer ensuite coûte une fortune. Convex et Supabase dominent l'espace BaaS en 2026. Voici la comparaison technique honnête, basée sur 12 mois de prod avec les deux.
Convex en deux minutes
Convex est un backend réactif end-to-end TypeScript. Tu écris des queries et mutations en TS, elles sont typées de bout en bout, le frontend reçoit des updates en temps réel automatiquement (sans WebSocket à câbler), et le système gère lui-même les transactions, le cache et la concurrence optimiste.
C'est un document store inspiré de Firebase mais bien plus mature : schémas TypeScript stricts, indexes explicites, requêtes en code (pas en SQL), file storage natif, scheduled functions, full-text search. Tu ne touches jamais à une base SQL — tu écris des fonctions.
Supabase en deux minutes
Supabase est un Postgres managé + auth + storage + realtime + edge functions. C'est l'alternative open-source à Firebase qui mise sur SQL standard. Tu écris des requêtes SQL ou tu utilises le client JS, tu as Row Level Security (RLS) pour l'authz, et tout est portable parce que c'est du Postgres.
Le gros argument : zéro vendor lock-in. Tu peux self-host Supabase, exporter ta DB Postgres, migrer ailleurs. Convex est aussi self-hostable (Docker, FSL Apache 2.0) depuis 2024, mais l'exportation vers un autre backend reste plus contraignante qu'un dump Postgres.
Les 6 critères qui comptent
1. Modèle de données
Supabase = SQL relationnel. Tables, foreign keys, joins, transactions ACID. Si tu connais Postgres, tu es chez toi. Les migrations sont des fichiers .sql, versionnées.
Convex = documents typés. Pas de joins SQL, mais des indexes composites et des relations explicites via des IDs. Le schéma est défini en TypeScript dans convex/schema.ts, validé à l'écriture. Moins flexible que SQL mais infiniment plus type-safe.
// convex/schema.ts
import { defineSchema, defineTable } from "convex/server";
import { v } from "convex/values";
export default defineSchema({
articles: defineTable({
slug: v.string(),
title: v.string(),
authorUserId: v.id("users"),
publishedAt: v.optional(v.number()),
tags: v.array(v.string()),
})
.index("by_slug", ["slug"])
.index("by_author", ["authorUserId"]),
});Le schéma est validé à chaque insert/update. Une mutation qui essaie d'écrire un champ inconnu plante en TypeScript à la compilation, pas en runtime.
2. Realtime
Convex gagne très large ici. Toutes les queries sont réactives par défaut. Si une mutation met à jour une row, tous les composants React qui lisent cette query se re-render automatiquement, dans tous les onglets, sur tous les devices. Aucun WebSocket à brancher, aucun subscribe à écrire.
Supabase Realtime est puissant mais explicite : tu dois t'abonner à des channels, gérer les reconnexions, les unsubscribe. Et le client realtime ne couvre pas tous les cas de joins complexes.
3. Type safety
Convex génère automatiquement des types depuis ton schéma + tes functions : api.articles.list, api.articles.get, etc. Le frontend appelle useQuery(api.articles.list) et reçoit la valeur typée — sans codegen manuel.
Supabase a fait des énormes progrès avec le codegen TypeScript depuis ton schéma SQL. Mais ça reste un script à lancer après chaque migration, et les types des fonctions Postgres custom sont fragiles.
4. Authz et sécurité
Supabase mise sur Row Level Security (RLS) : des policies SQL qui filtrent les rows par utilisateur. Puissant, mais brutalement difficile à debugger quand une policy bloque une query sans message clair. Et il faut écrire du SQL pour chaque cas.
Convex te laisse écrire l'authz en TypeScript dans chaque function : const userId = await ctx.auth.getUserIdentity(), puis du code normal. C'est plus verbose mais infiniment plus debuggable, testable, et type-safe.
5. Pricing
Supabase : free tier généreux (500 MB DB, 1 GB storage, 50 K MAU), puis 25$/mois pour le pro tier. Très bon rapport. Tu peux self-host si tu veux.
Convex : free tier suffisant pour démarrer (1 M function calls/mois, 0.5 GB DB), puis 25$/mois + usage. Le pricing scale avec le succès du projet — c'est juste, mais à surveiller.
6. Self-host et vendor lock-in
Supabase = Postgres standard, exportable à tout moment vers n'importe quel hébergeur Postgres. Self-host officiel via Docker Compose. Lock-in faible.
Convex = self-hostable depuis 2024 (FSL Apache 2.0, Docker, single-machine sur VPS / Fly.io / RDS). Le dashboard et le CLI marchent en self-host. Limite : pas de support officiel sur self-host, scalabilité multi-machine demande de modifier le code open-source. Et migrer vers un autre backend exige toujours de réécrire les queries/mutations TypeScript. Lock-in moyen. Le tradeoff : la magie réactive end-to-end, avec une porte de sortie technique si besoin.
Tableau récapitulatif
Critère | Convex | Supabase |
|---|---|---|
Modèle | Document TS | 🏆 Postgres SQL |
Realtime | 🏆 Magique | Explicite |
Type safety | 🏆 End-to-end auto | Codegen manuel |
Authz | 🏆 TS testable | RLS SQL |
Migrations | TS au déploiement | 🏆 SQL versionné |
Self-host | ✅ Docker (FSL) | 🏆 ✅ Docker |
DX | 🏆 Exceptionnelle | Très bonne |
Maturité écosystème | En croissance | 🏆 Massif |
Pour quel projet choisir quoi ?
Convex est le meilleur choix si :
Tu construis un SaaS réactif (collab, dashboards live, chat, multi-user)
Tu es solo ou en petite équipe et tu veux maximiser la vitesse
Tu détestes écrire du SQL et tu veux du TypeScript partout
Tu acceptes une DX magique en échange d'un écosystème plus jeune (et tu peux self-host sur VPS si besoin)
Supabase est le meilleur choix si :
Tu as une équipe qui maîtrise Postgres et SQL
Tu veux pouvoir self-host ou migrer ailleurs un jour
Tu construis un produit avec des requêtes analytiques complexes
Tu veux le free tier le plus généreux du marché
Mon choix pour ApexKit : Convex
Quand j'ai conçu ApexKit (template SaaS production-ready), j'ai choisi Convex pour trois raisons :
Le realtime gratuit. Pour un SaaS multi-tenant, voir les mises à jour live entre utilisateurs sans coder un seul WebSocket, c'est un game-changer.
Le typage de bout en bout. Du schéma au composant React, sans aucun codegen manuel. Quand tu refactor une mutation, tous les appels frontend cassent à la compilation. Magique.
La simplicité opérationnelle. Pas de pool de connexions à gérer, pas de migrations à orchestrer en prod, pas de monitoring SQL. Tu push, ça marche.
Le tradeoff de DX vs portabilité existe, mais reste raisonnable : Convex est self-hostable sur VPS via Docker si tu veux reprendre le contrôle, et les semaines économisées en démarrage compensent largement pour un solo-founder ou une petite équipe.
Exemple : la même query dans les deux mondes
// Convex — query réactive type-safe
// convex/articles.ts
export const listPublished = query({
args: { limit: v.optional(v.number()) },
handler: async (ctx, args) => {
return await ctx.db
.query("articles")
.withIndex("by_status", q => q.eq("status", "published"))
.order("desc")
.take(args.limit ?? 10);
},
});
// React — useQuery se re-run automatiquement à chaque update
const articles = useQuery(api.articles.listPublished, { limit: 10 });// Supabase — query + subscription à brancher manuellement
const { data: articles } = await supabase
.from("articles")
.select("*")
.eq("status", "published")
.order("published_at", { ascending: false })
.limit(10);
// Realtime : abonnement séparé
supabase
.channel("articles")
.on("postgres_changes",
{ event: "*", schema: "public", table: "articles" },
payload => { /* refetch ou patch local */ }
)
.subscribe();Démarre avec une stack déjà câblée
Brancher Convex à un frontend TanStack Start ou Next.js prend une journée. Brancher auth (Better Auth), billing (Stripe), emails (Resend), multi-tenancy, RBAC, blog, docs et dashboard admin… plusieurs semaines.
J'ai assemblé tout ça dans ApexKit pour éviter à d'autres founders de réinventer la roue. Tu peux comparer les deux backends en démarrant deux projets, ou prendre le template et passer direct au produit.
Construire ton SaaS encore plus vite
ApexKit est le template full-stack TypeScript que j'ai construit pour livrer un SaaS en une semaine : auth passwordless, multi-tenant, billing Stripe, blog, docs et dashboard admin — câblés ensemble avec TanStack Start et Convex.
Web seul ou Web + mobile (Expo), source-of-truth Convex partagée, prêt à déployer sur VPS ou Vercel en quelques minutes.