Aurabase vs Convex : SQL natif ou backend réactif ?
Convex prend le pari inverse de la plupart des BaaS : pas de Postgres, pas de SQL, un query builder TypeScript propriétaire et une réactivité automatique par défaut. Aurabase reste sur PostgreSQL 16 standard, avec SQL et Row Level Security natifs. Les deux moteurs partagent pourtant un point commun rarement mis en avant : ils sont écrits en Rust. Voici où chacun l’emporte, sans mauvaise foi.
Convex remplace SQL par un modèle document-relationnel propriétaire piloté en TypeScript, avec une synchronisation temps réel automatique dès qu’une requête change — sans code de souscription à écrire. Aurabase garde PostgreSQL 16 standard : SQL, RLS, pg_dump/pg_restore, et une portabilité que le modèle propriétaire de Convex ne permet pas. Les deux moteurs sont écrits en Rust. Convex propose depuis février 2026 une région UE (Irlande) mais reste une société américaine ; Aurabase SAS est une société française, hébergée en Allemagne et en Finlande. Le choix dépend de votre priorité : réactivité clé en main en TypeScript, ou SQL portable avec souveraineté UE documentée.
SQL Postgres natif contre query builder TypeScript propriétaire
Aurabase s’appuie sur PostgreSQL 16 standard : SQL, migrations classiques, policies RLS. Convex prend le chemin inverse. Sa documentation officielle est explicite sur ce choix : « There is nothing to set up and no need to write any SQL. Just use JavaScript to express your app’s needs » (docs.convex.dev/database, consulté le 24 août 2026). Les tables Convex stockent des documents typés par un schéma TypeScript optionnel, créées au premier insert, sans DDL à écrire.
Voici à quoi ressemble une requête Convex typique, avec un index déclaré dans le schéma :
Aucun des deux modèles n’est strictement supérieur. Le query builder de Convex élimine une classe entière de bugs d’injection SQL par construction. Il vous enferme aussi dans son propre langage de requête. Pas d’outil BI standard, pas d’ORM Postgres existant, pas d’extension SQL comme pgvector ou pg_graphql sans réécriture complète de la couche de données.
Synchronisation automatique contre CDC opt-in par canal
Chez Convex, toute requête est réactive par défaut. Le client ouvre une connexion WebSocket vers le déploiement, et le moteur retient l’ensemble des lignes lues par chaque requête (son « read-set »). Dès qu’une mutation touche ce read-set, la fonction est rejouée côté serveur. Le résultat mis à jour est poussé au client, sans code de souscription à écrire (stack.convex.dev/how-convex-works, consulté le 24 août 2026).
Le realtime d’Aurabase fonctionne à l’inverse, en opt-in. NATS JetStream diffuse le flux de changement (CDC) PostgreSQL ; vous vous abonnez explicitement à un canal via channel().on('postgres_changes', …), avec filtrage possible par colonne. C’est plus de code à écrire pour une vue live, mais un protocole standard adossé à la réplication logique Postgres — pas un mécanisme propriétaire couplé à un query builder spécifique.
Rust des deux côtés, MIT contre FSL
Un point commun qu’on ne s’attend pas à trouver ici : les deux moteurs sont écrits en Rust. Le dépôt open source de Convex (get-convex/convex-backend) est majoritairement composé de crates Rust. TypeScript sert uniquement à l’environnement d’exécution des fonctions développeur, via le moteur V8 (stack.convex.dev/how-convex-works, consulté le 24 août 2026). Contre Supabase — stack Elixir/Go/TypeScript/Node — le cœur Rust reste un vrai différenciateur Aurabase. Contre Convex, non : les deux ont fait ce pari, chacun pour builder un moteur transactionnel fiable sans pauses de ramasse-miettes imprévisibles.
La différence se joue sur la licence. Le code du moteur Convex (get-convex/convex-backend) est publié sous FSL-1.1-Apache-2.0, une licence « fair source ». Elle autorise tout usage sauf créer un produit concurrent de Convex Cloud. Chaque version bascule en Apache 2.0 pur deux ans après sa mise à disposition — clause vérifiée directement dans le fichier LICENSE.md du dépôt (github.com/get-convex/convex-backend, consulté le 24 août 2026). Le workspace Rust et le SDK JavaScript d’Aurabase sont publiés sous licence MIT, open source sans délai ni restriction d’usage.
ghcr.io/get-convex/convex-backend). Elle stocke par défaut sur SQLite, mais peut s’appuyer sur Postgres ou MySQL en configuration — sans jamais exposer de SQL à l’application pour autant. Aurabase fournit un docker-compose.yml complet dans son dépôt, sans restriction de licence, mais le cloud managé reste la voie principale recommandée pour la production.RAG des deux côtés, NL2SQL propre à Aurabase
Convex n’est pas en reste sur l’IA. Sa recherche vectorielle native est accessible depuis les actions, avec un index vectoriel déclaré dans le schéma. Avec son framework @convex-dev/agent et rag.search(), elle forme une capacité RAG comparable, sur le papier, au RAG natif d’Aurabase (docs.convex.dev/search/vector-search, consulté le 24 août 2026).
La vraie différence n’est donc pas « RAG contre pas de RAG ». Aurabase intègre en plus un moteur NL2SQL — traduction d’une question en langage naturel vers une requête SQL, validée puis bornée avant exécution. Convex ne peut structurellement pas proposer d’équivalent : sans SQL à traduire, il n’y a rien à générer. C’est une conséquence directe du choix d’architecture documenté plus haut, pas un retard produit.
Une région UE chez Convex, une société américaine derrière
Convex propose une région EU West (Ireland), déployée depuis le 6 février 2026, en plus de sa région US East par défaut (docs.convex.dev/production/regions et news.convex.dev, consultés le 24 août 2026). Une option réelle qui mérite d’être reconnue. Mais Convex Inc. reste une société de droit américain. Son fondateur et CEO, Jamie Turner, se dit basé à San Francisco (news.convex.dev, levée de 57 M$ en Series B menée par Insight Partners, 4 août 2026). Choisir la région Irlande ne change pas la juridiction de la société qui héberge vos données.
C’est exactement le même mécanisme que celui documenté face à Supabase. Une région européenne cochée dans un panneau d’administration ne suffit pas à sortir du régime juridique du CLOUD Act tant que la société mère reste américaine. Aurabase SAS, société de droit français, exploite une infrastructure de production vérifiée en Allemagne (Nuremberg, Falkenstein) et en Finlande (Helsinki).
Approfondir : pourquoi le CLOUD Act change le choix de votre BaaSSur les benchmarks, une retenue partagée — dans deux directions différentes
Convex a pris position publiquement contre la course aux benchmarks marketing. Le titre de son billet ne fait pas dans la nuance : « I don’t care about your database benchmarks (and neither should you) » (stack.convex.dev/on-competitive-benchmarks, consulté le 24 août 2026). Un choix de posture assumé, pas une attaque ciblée — le billet ne nomme d’ailleurs aucun concurrent en particulier.
La position d’Aurabase part du même constat mais prend la direction inverse : publier une méthodologie de benchmark reproductible et datée plutôt que renoncer à publier des chiffres. C’est encore un chantier en cours — aucun chiffre de performance n’est mis en avant dans cet article tant qu’il n’est pas accompagné de sa méthodologie complète.
TypeScript de bout en bout contre SDK multi-langage
Convex assume un choix radical : un seul langage, du schéma à la fonction serveur jusqu’au client React, avec un typage de bout en bout sans génération manuelle. C’est un vrai atout de productivité pour une équipe déjà 100 % TypeScript.
Le SDK JavaScript d’Aurabase est distribué en 10 packages npm scopés @aurabase/*, tous publiés et installables. Des SDK Python, Dart et Rust existent aussi dans le dépôt. Aucun des trois n’est encore publié sur son registre respectif (PyPI, pub.dev, crates.io) : ils ne sont installables qu’en dépendance de dépôt Git pour l’instant. Une couverture multi-langage plus large sur le papier, avec un écart d’exécution réel à combler avant de la revendiquer pleinement.
pg_dump standard contre modèle propriétaire
Aurabase repose sur PostgreSQL 16 standard et une API compatible PostgREST. Un export de schéma et de données se fait avec pg_dump/pg_restore classiques — vers Aurabase, ou vers n’importe quel autre Postgres.
Convex ne repose pas sur SQL : il n’existe pas d’équivalent direct à un export vers un format relationnel standard. Migrer une application Convex vers un backend SQL suppose de remodéliser le schéma en tables relationnelles et de réécrire la couche d’accès aux données — pas seulement de convertir un fichier d’export.
Quand Convex reste le bon choix
Si votre équipe est déjà 100 % TypeScript, construit une app React réactive, et n’a pas de dépendance forte à SQL ou aux extensions Postgres, Convex a un avantage produit réel. Deux atouts concrets : une réactivité automatique sans configuration, et un typage de bout en bout qui réduit une classe entière de bugs d’intégration frontend/backend.
Le compromis apparaît quand SQL, RLS Postgres, la portabilité des données ou une région d’hébergement en Allemagne/Finlande avec société mère française deviennent des critères de décision. C’est là qu’Aurabase construit son différenciateur.
Ce qui distingue les deux plateformes
Envie d’un comparatif orienté open source et auto-hébergement ? Voir Aurabase vs Appwrite. Pour le comparatif de référence sur Postgres et l’architecture, voir Aurabase vs Supabase.