Alternatives à Convex pour les fondateurs qui veulent garder le contrôle de leur backend

Pourquoi les fondateurs cherchent des alternatives à Convex

Convex résout un vrai problème. Construire des applications temps réel, c'est douloureux. La gestion des WebSockets, l'invalidation de cache, les mises à jour optimistes, le cycle de vie des abonnements — tout ça bouffe des semaines de développement. Convex élimine tout. On écrit une fonction de requête, on l'utilise dans un hook React, et l'UI reste synchronisée automatiquement. L'expérience développeur est réellement excellente.

Alors pourquoi vouloir partir ?

Un vendor lock-in sans porte de sortie. C'est le point central. Convex n'est pas open source. Il n'y a pas d'option d'auto-hébergement. Le modèle de données utilise le document store propriétaire de Convex — ni Postgres, ni MySQL, ni même un format NoSQL standard. La logique backend tourne sous forme de fonctions TypeScript spécifiques à Convex avec des patterns Convex pour les queries, mutations et actions. Chaque ligne de code backend est couplée à la plateforme. Si on doit migrer, on ne change pas une chaîne de connexion à la base. On réécrit toute la couche de données.

Le modèle réactif a une courbe d'apprentissage. L'approche de Convex pour le développement backend est différente de tout le reste. Les queries doivent être déterministes (pas de valeurs aléatoires, pas de Date.now()). Les mutations ont des contraintes spécifiques. Le modèle mental du "chaque requête est un abonnement" exige de repenser la façon dont on structure l'accès aux données. Pour les développeurs venant d'API REST ou même de Firebase, il y a une période d'adaptation réelle. Certains patterns triviaux en SQL demandent une réflexion différente dans Convex.

L'incertitude tarifaire à l'échelle. Le tier gratuit de Convex est généreux pour les projets hobby, et le plan Pro à 25 $/mois est raisonnable. Mais quand l'app grandit, la facturation à l'usage fait grandir la facture avec — et les queries réactives qui se relancent automatiquement quand les données changent peuvent générer plus de compute backend qu'on ne l'imagine. Un dashboard qui s'abonne à dix flux de données différents fait tourner dix requêtes live, pas dix réponses en cache. A l'échelle, ça s'additionne de façons plus difficiles à prévoir qu'un modèle requête-réponse classique.

On n'a peut-être pas besoin de réactivité partout. Toutes les apps ne bénéficient pas de la sync temps réel automatique. Un SaaS avec des paramètres utilisateur, un CMS ou un backend e-commerce n'a pas besoin que chaque requête soit un abonnement live. Pour ces cas d'usage, le différenciateur principal de Convex — la réactivité automatique — est du overhead qu'on paie sans utiliser. Un backend plus simple ferait aussi bien le travail, à moindre complexité et moindre coût.

Ces préoccupations ne font pas de Convex un mauvais outil. Elles en font un outil avec des compromis spécifiques qui peuvent ne pas correspondre à tous les projets.

Comment on a évalué ces alternatives

On a regardé chaque outil à travers le prisme d'un fondateur solo bootstrapé qui construit un vrai produit :

• Capacité temps réel : comment l'outil gère les mises à jour live par rapport à la réactivité automatique de Convex ?
• Portabilité des données : peut-on déplacer ses données et sa logique vers une autre plateforme sans tout réécrire ?
• Typage : offre-t-il un typage TypeScript de bout en bout comme Convex ?
• Option d'auto-hébergement : peut-on le faire tourner sur sa propre infrastructure ?
• Coût total à l'échelle : combien coûte réellement une charge de travail SaaS typique par mois ?

On a aussi pesé la taille de la communauté, la qualité de la documentation et la maturité de l'écosystème. Quand on construit seul, un outil bien documenté avec un support communautaire actif vaut plus qu'un outil techniquement supérieur avec une doc éparse.

Analyse détaillée : ce que chaque alternative fait de mieux

Supabase — le standard open source

Supabase est l'alternative la plus directe à Convex pour les fondateurs qui veulent une plateforme backend complète mais que le lock-in propriétaire met mal à l'aise. On obtient Postgres, l'auth, les abonnements temps réel, les edge functions et le stockage de fichiers — toutes les catégories que Convex couvre, construites sur des standards ouverts.

La fondation Postgres est le différenciateur clé. Les données vivent dans une base relationnelle standard que chaque outil de l'écosystème comprend. Outils de BI, frameworks de migration, ORMs, scripts d'analyse de données — tout fonctionne. Quand on écrit une requête dans Supabase, on écrit du SQL qui tourne sur n'importe quelle instance Postgres. Cette portabilité vaut de l'argent réel quand on considère le coût d'une future migration.

Le temps réel dans Supabase fonctionne via la réplication logique Postgres. On s'abonne aux changements sur des tables, filtrés par conditions, et on reçoit les mises à jour poussées vers le client. Ca fonctionne, mais c'est fondamentalement différent de l'approche Convex. Dans Convex, chaque query est automatiquement un abonnement. Dans Supabase, on met en place explicitement des canaux temps réel pour les données qu'on veut surveiller. Ca signifie plus de code de plomberie mais aussi plus de contrôle sur ce qui génère du trafic temps réel.

Le typage est le domaine où Supabase est en retrait par rapport à Convex. Out of the box, le client JavaScript Supabase ne donne pas le même flux de types de bout en bout. On peut générer des types TypeScript depuis le schéma de la base, et coupler Supabase avec Drizzle ORM ou Prisma rapproche du niveau de typage de Convex, mais ça demande une configuration supplémentaire.

Le tier gratuit est généreux pour les projets actifs mais met les bases en pause après sept jours d'inactivité. Pour la production, comptez 25 $/mois minimum pour le plan Pro. L'auto-hébergement avec Docker est une option pour éliminer complètement la dépendance à la plateforme.

Quand choisir Supabase : on veut un backend complet avec le filet de sécurité du Postgres standard et l'option d'auto-héberger. On accepte d'écrire un peu plus de plomberie temps réel en échange de la portabilité des données.

Firebase — le vétéran temps réel éprouvé

Firebase est la comparaison la plus directe avec Convex en termes de capacité temps réel. Les listeners Firestore précèdent Convex de plusieurs années et sont éprouvés à grande échelle sur des millions d'apps. Si la raison principale d'utiliser Convex est la sync temps réel, Firebase mérite une considération sérieuse.

Les listeners onSnapshot de Firestore donnent des données live dans les composants UI. Les SDKs gèrent le cache offline automatiquement — l'app continue de fonctionner quand le réseau tombe et se synchronise au retour. Pour les apps mobile, ce comportement offline-first est réellement difficile à reproduire avec d'autres outils. Les SDKs Flutter, iOS et Android sont les plus aboutis de la catégorie BaaS.

Le modèle tarifaire est le point où Firebase devient inconfortable. Firestore facture par lecture, écriture et suppression de document. Une vue liste affichant 50 éléments coûte 50 lectures. Rafraîchir la page, 50 lectures de plus. Les listeners temps réel qui se déclenchent à chaque changement génèrent des lectures en continu. Cette facturation par opération rend les coûts difficiles à prévoir, surtout pour le même genre d'UIs réactives et fréquemment mises à jour que Convex gère avec un modèle d'usage forfaitaire.

Firebase échange aussi un lock-in contre un autre. Le modèle document Firestore, les security rules et les patterns de requêtes sont propriétaires Google. Passer de Convex à Firebase ne résout pas le problème de portabilité — ça change juste l'entreprise qui nous tient. Mais Firebase a plus de dix ans de track record et le backing de Google Cloud, ce qui réduit (sans éliminer) le risque plateforme.

Quand choisir Firebase : on construit une app mobile avec des besoins offline et on a besoin d'une sync temps réel éprouvée à l'échelle. Le modèle de facturation par lecture fonctionne pour ses patterns d'accès.

PocketBase — le simplificateur radical

PocketBase est à l'extrême opposé du spectre par rapport à Convex. Au lieu d'une plateforme managée avec une infrastructure réactive sophistiquée, c'est un seul binaire Go qu'on télécharge et qu'on lance. Ce binaire contient une base SQLite, des abonnements temps réel via Server-Sent Events, l'authentification, le stockage de fichiers et un dashboard admin.

L'attrait pour les indie hackers est le coût total de possession. On télécharge le binaire. On le déploie sur un VPS à 5 $/mois chez Hetzner ou Fly.io. On a maintenant un backend complet pour moins qu'un abonnement café. Pas de frais de plateforme, pas de facturation à l'usage, pas de surprises. La base de données est un seul fichier SQLite qu'on peut copier pour les sauvegardes ou télécharger sur son laptop pour le développement local.

Le temps réel dans PocketBase fonctionne via Server-Sent Events. On s'abonne aux changements sur des collections (tables) et on reçoit les mises à jour quand des enregistrements sont créés, modifiés ou supprimés. C'est moins sophistiqué que la réactivité automatique de Convex — on s'abonne aux changements au niveau table, pas au niveau résultat de requête — mais pour la plupart des apps, ça couvre le besoin.

Le compromis fondamental, c'est la montée en charge. PocketBase tourne sur un serveur unique avec SQLite. Pas de clustering, pas de déploiement multi-régions, pas de scaling horizontal. Pour un SaaS avec quelques centaines d'utilisateurs actifs, c'est largement suffisant. Pour un SaaS avec des milliers d'utilisateurs concurrents faisant beaucoup d'écritures, on va toucher les limites.

Le bus factor compte aussi. PocketBase est principalement maintenu par un seul développeur. Le projet est populaire et actif, mais l'infrastructure backend critique dépend de l'intérêt et de la disponibilité d'une seule personne. Pour un side project, c'est acceptable. Pour sa source de revenus principale, il faut peser soigneusement.

Quand choisir PocketBase : on veut le backend le plus simple possible au coût le plus bas possible. L'app a des besoins de montée en charge modestes et on valorise la simplicité plus que la sophistication temps réel.

Appwrite — le tout-en-un auto-hébergé

Appwrite répond à la question "je veux une plateforme backend complète comme Convex mais je veux posséder l'infrastructure." On obtient des bases de données, l'auth avec 30+ fournisseurs OAuth, le stockage de fichiers, des fonctions serverless dans plusieurs langages, des abonnements temps réel et du messaging — le tout déployable avec une seule commande Docker Compose.

L'auto-hébergement est l'argument principal. On fait tourner Appwrite sur son propre serveur et on contrôle les données, l'uptime et le coût. Aucun vendeur ne peut changer les prix, déprécier des fonctionnalités ou fermer boutique. Pour les fondateurs qui construisent des produits qu'ils comptent faire tourner pendant des années, cette indépendance a une vraie valeur.

Le temps réel dans Appwrite couvre les changements en base, les événements auth et les événements stockage. On s'abonne à des canaux spécifiques et on reçoit des mises à jour quand des changements pertinents se produisent. Le modèle est basé sur les événements plutôt que sur les requêtes — plus proche de Firebase que de Convex. On n'obtient pas de mises à jour UI automatiques depuis les résultats de requêtes, mais on a les briques de base pour l'implémenter.

La flexibilité du runtime de fonctions est notable. Contrairement à Convex (TypeScript uniquement), les fonctions Appwrite tournent en Node.js, Python, PHP, Ruby, Dart et plus. Si l'équipe inclut un développeur Python qui veut écrire de la logique de traitement de données, ou si on veut utiliser une bibliothèque PHP pour la génération PDF, Appwrite s'adapte sans contournements.

Le cloud managé démarre à 15 $/mois pour le plan Pro — moins cher que Convex et Supabase. L'auto-hébergement sur un VPS à 10 $/mois donne un BaaS capable de production pour le coût du serveur seul.

Quand choisir Appwrite : on veut une plateforme BaaS complète qu'on possède et qu'on opère. On valorise le support multi-langage pour les fonctions et on est à l'aise avec Docker en production.

Hasura — la couche GraphQL réactive

Hasura prend une approche différente de tous les autres outils de cette liste. Au lieu de fournir une plateforme backend complète, il donne une couche API puissante qui se pose sur une base Postgres existante et génère automatiquement une API GraphQL temps réel depuis le schéma.

On crée une table dans Postgres, et Hasura fournit immédiatement queries, mutations et subscriptions — le tout avec des types corrects. Les subscriptions sont la fonctionnalité clé pour les réfugiés de Convex. Une subscription GraphQL dans Hasura maintient une connexion live ouverte et pousse les nouveaux résultats chaque fois que les données sous-jacentes changent. Pour des besoins data complexes avec des jointures entre plusieurs tables, les subscriptions Hasura sont en fait plus puissantes que les queries réactives de Convex parce qu'on a toute l'expressivité du SQL en dessous.

Le système de permissions est complet. On définit des règles de contrôle d'accès row-level et column-level basées sur les rôles utilisateur, les variables de session et des conditions arbitraires. Pour un SaaS multi-tenant, c'est plus flexible que l'approche de Convex par fonctions côté serveur pour l'autorisation.

Le compromis, c'est que Hasura est une couche API, pas une plateforme. Pas d'auth intégrée (on amène la sienne — Clerk, Auth0 ou une solution custom). Pas de stockage de fichiers. Pas de fonctions serverless au-delà des Hasura Actions et Event Triggers. On assemble un stack plutôt que d'utiliser une plateforme tout-en-un.

Le prix est aussi une préoccupation. Le tier gratuit du cloud managé Hasura est limité à 60 requêtes par minute. Le plan Professional démarre à 99 $/mois, ce qui est raide pour un fondateur solo. L'auto-hébergement de la Community Edition est gratuit, mais on gère l'infrastructure soi-même.

Quand choisir Hasura : on veut des subscriptions GraphQL temps réel sur une base Postgres standard et on est à l'aise pour assembler auth, stockage et fonctions à partir de services séparés.

NocoDB — la couche visuelle sur la base

NocoDB est le choix le plus atypique de cette liste. Ce n'est pas une plateforme backend ni un BaaS. C'est un outil open source qui transforme n'importe quelle base SQL en interface tableur avec des API REST et GraphQL auto-générées.

Pourquoi est-il là ? Parce que certains fondateurs qui utilisent Convex ne construisent pas que pour des développeurs. Ils ont besoin d'un moyen pour les membres non techniques de l'équipe — cofondateurs, ops, support client — de consulter et modifier des données sans un admin panel custom. NocoDB remplit ce rôle. On le connecte à sa base Postgres, MySQL ou SQLite existante, et les utilisateurs non techniques obtiennent une interface tableur familière tandis que les développeurs obtiennent des endpoints API.

NocoDB génère automatiquement des API REST et GraphQL depuis le schéma de la base. Ces API incluent filtrage, tri, pagination et lookups d'enregistrements imbriqués. Pour les applications CRUD-heavy, ça peut remplacer une quantité significative de code backend.

La limitation est claire : NocoDB n'est pas un backend réactif temps réel. Il ne remplace pas le système de queries live de Convex, l'auth ni les fonctions serverless. C'est une couche d'un stack plutôt qu'une solution complète. En le couplant avec Supabase pour l'auth et le temps réel, on obtient une combinaison convaincante — Postgres avec temps réel pour l'app, plus une interface tableur pour l'équipe.

Quand choisir NocoDB : on a besoin d'une interface visuelle de base de données pour les parties prenantes non techniques et d'API auto-générées pour le frontend. A utiliser comme partie d'un stack, pas comme remplacement autonome de Convex.

Comparaison des coûts pour des charges typiques

Pour un SaaS avec 1 000 utilisateurs actifs mensuels, des fonctionnalités temps réel modérées, 5 Go de données et 50 Go de stockage de fichiers :

• Convex : plan Pro 25 $/mois plus usage. Estimation 30-60 $/mois selon le volume de queries réactives.
• Supabase : plan Pro 25 $/mois couvre ça confortablement. Auto-hébergé : 10-20 $/mois pour le VPS.
• Firebase : plan Blaze, facturation à l'usage. Estimation 15-50 $/mois selon les patterns de lecture.
• PocketBase : 5-10 $/mois pour un VPS. Pas de frais de plateforme.
• Appwrite : plan Pro 15 $/mois en managé. Auto-hébergé : 10-15 $/mois pour le VPS.
• Hasura : Community Edition auto-hébergée gratuite sur un VPS à 10-20 $/mois. Cloud Professional 99 $/mois.
• NocoDB : gratuit en auto-hébergé. Cloud managé à partir de 8 $/siège/mois.

PocketBase est l'option la moins chère de loin si les besoins de montée en charge sont modestes. Supabase et Appwrite sont les plus prévisibles sur les plans managés. Convex et Firebase sont les plus difficiles à prévoir parce que la facturation à l'usage dépend des patterns d'accès spécifiques.

Quand rester sur Convex

Convex reste le bon choix dans des situations précises :

• Le temps réel est au coeur du produit. Si l'app est un éditeur collaboratif, un dashboard live, un jeu multijoueur ou n'importe quoi où chaque utilisateur voit chaque changement instantanément, la réactivité automatique de Convex fait gagner des semaines de développement.
• On valorise le typage TypeScript par-dessus tout. Le flux de types de bout en bout, du schéma de base de données au composant React, est réellement excellent. Aucun autre outil de cette liste ne l'égale sans outillage supplémentaire.
• On est early stage et on optimise pour la vitesse. Si on doit valider une idée le plus vite possible et que le temps réel est impliqué, l'expérience développeur de Convex permet de shipper plus vite. On pourra toujours migrer plus tard si l'idée fonctionne.
• L'équipe est petite et native TypeScript. Un développeur solo ou une petite équipe qui vit dans TypeScript trouvera les patterns de Convex naturels et productifs.

La préoccupation du lock-in est réelle, mais c'est aussi un problème futur. Si on est pré-revenu et qu'on essaie de trouver le product-market fit, shipper vite compte plus que la portabilité. Il faut juste y entrer les yeux ouverts sur le compromis.

Ce qu'implique une migration hors de Convex

Quitter Convex demande de la planification parce que le couplage est profond.

Export des données. Convex supporte les exports par snapshot qui donnent les données sous forme de fichiers JSON. Les données elles-mêmes sont portables. Il faut exporter tôt et souvent pour avoir des sauvegardes indépendamment des plans de migration.

Réécriture de la logique backend. C'est la partie difficile. Les fonctions query, mutations, actions et fonctions planifiées de Convex doivent toutes être réécrites pour la plateforme cible. Les queries Convex deviennent des requêtes SQL ou des appels API. Les mutations deviennent des écritures en base derrière des endpoints REST ou des mutations GraphQL. Les actions qui appellent des API externes deviennent des fonctions serverless ou des routes API.

Replomberie du temps réel. Si on s'est appuyé sur la réactivité automatique de Convex, il faut mettre en place explicitement l'infrastructure temps réel sur la nouvelle plateforme. Sur Supabase, ça signifie configurer les canaux temps réel Postgres. Sur Firebase, mettre en place des listeners Firestore. Sur Hasura, écrire des subscriptions GraphQL. Il faut budgéter un temps significatif pour ça si le temps réel était central dans l'app.

Migration de l'auth. Si on utilisait l'auth intégrée de Convex, il faut migrer les comptes utilisateur vers le système d'auth de la nouvelle plateforme. Les hashes de mots de passe peuvent ne pas être directement portables selon l'algorithme de hachage utilisé.

Approche incrémentale. Mieux vaut migrer fonctionnalité par fonctionnalité plutôt que tout d'un coup. On monte le nouveau backend en parallèle de Convex. On migre une fonctionnalité, on vérifie que ça fonctionne, puis on passe à la suivante. On garde Convex actif jusqu'à ce que la migration soit entièrement vérifiée. Comptez 4 à 8 semaines pour un projet de taille moyenne avec des fonctionnalités temps réel significatives.

Le coût de migration est le vrai prix du lock-in de Convex. Il faut l'intégrer dans sa décision, mais ne pas se laisser paralyser. Chaque plateforme a des coûts de switching. La question est de savoir si les gains de productivité de Convex justifient ces coûts pour le projet spécifique en question.