Auto-hébergement souverain : positionner Aurabase face aux BaaS Rust-natifs
Si vous cherchez un backend écrit en Rust que vous pouvez auto-héberger vous-même, le choix ne se limite plus à un seul nom. sh0.dev distribue un binaire Rust unique d'environ 25 Mo. TrailBase combine un cœur Rust, une base SQLite embarquée et une interface d'administration SolidJS dans le même paquet. Aurabase reste une plateforme complète, elle aussi auto-hébergeable via Docker Compose ou un chart Helm : Postgres 16 dédié par projet, authentification, temps réel, stockage, fonctions edge et IA native. La vraie question n'est pas « lequel est écrit en Rust », mais quel périmètre fonctionnel correspond à votre projet.
Ce comparatif se concentre sur les backends Rust-natifs auto-hébergeables : sh0.dev, TrailBase et Aurabase. Pour un backend auto-hébergé plus généraliste, non écrit en Rust, nos comparatifs Aurabase vs PocketBase et Aurabase vs Appwrite creusent d'autres options. Pour l'analyse complète de ce que « souveraineté UE » signifie juridiquement, hébergement et nationalité de l'éditeur, notre article auto-hébergement face à un BaaS souverain UE va plus loin ; ce post-ci se limite à situer Aurabase parmi ses pairs Rust.
- Trois options réelles aujourd'hui pour un backend Rust-natif auto-hébergeable : sh0.dev (binaire unique, ~25 Mo), TrailBase (Rust + SQLite embarqué + interface SolidJS), Aurabase (plateforme complète, Postgres 16 dédié).
- Aurabase assume le compromis inverse d'un mono-binaire : plusieurs services orchestrés (Docker Compose ou Kubernetes/Helm) en échange de RLS multi-tenant, CDC temps réel et IA native (NL2SQL, RAG).
- Auto-hébergement et souveraineté UE sont deux axes distincts : héberger soi-même ne garantit rien tant que le serveur physique et la société éditrice ne sont pas eux-mêmes en UE.
- Informations sur sh0.dev et TrailBase basées sur leurs pages publiques au moment de la rédaction, non auditées en profondeur : vérifiez leur documentation à jour avant toute décision.
Pourquoi « Rust-natif » compte pour l’auto-hébergement
Un backend auto-hébergé retire l'infrastructure du périmètre d'un fournisseur cloud, mais pas la responsabilité de le faire tourner de façon fiable. C'est là que le choix du langage cesse d'être un détail : la sécurité mémoire de Rust et l'absence de garbage collector réduisent une classe entière de pannes en production, celles qui touchent le plus durement une petite équipe qui opère elle-même son serveur.
Ce n'est pas un argument de performance pure. Un service qui ne segfault pas et qui n'a pas de pause de collecte mémoire imprévisible est plus facile à surveiller pour une équipe sans SRE dédié. L'architecture réelle du cœur d'Aurabase, workspace Cargo à 18 crates compilées ensemble, est documentée en détail dans notre dossier d'architecture Rust.
sh0.dev : un binaire Rust unique, pensé pour le minimalisme
sh0.dev se présente, d'après ses pages publiques au moment de la rédaction, comme un backend distribué sous la forme d'un unique binaire Rust d'environ 25 Mo. L'argument central est la simplicité de déploiement : un fichier à copier sur un serveur, sans dépendance externe à installer séparément.
Nous n'avons pas audité en détail le périmètre fonctionnel exact ni le modèle de licence de sh0.dev pour cet article : les informations disponibles publiquement à ce sujet restent limitées, et un projet de ce type évolue vite. Si ce critère pèse dans votre décision, vérifiez sa documentation officielle à jour avant de trancher.
TrailBase : cœur Rust, SQLite embarqué, interface SolidJS
TrailBase associe, d'après ses pages publiques, un cœur backend écrit en Rust, une base de données SQLite embarquée et une interface d'administration construite avec SolidJS, le tout livré comme un projet auto-hébergeable. L'architecture rappelle celle de PocketBase (Go, SQLite, interface intégrée), avec un runtime écrit en Rust plutôt qu'en Go.
Comme pour sh0.dev, cet article ne prétend pas avoir vérifié en profondeur le code ou la feuille de route de TrailBase. Ce qu'on peut dire avec confiance, c'est le positionnement architectural général : un binaire qui embarque son propre moteur de stockage plutôt qu'un backend adossé à un Postgres externe.
Aurabase : Postgres 16 dédié, plateforme complète, également auto-hébergeable
Aurabase assume un compromis différent de celui d'un mono-binaire. Le dépôt fournit un docker-compose.yml documenté comme « prod-ready », lancé en local via ./start.sh, ainsi qu'un chart Helm complet (deploy/helm/aurabase/) avec des profils de valeurs distincts pour Hetzner, un banc Kubernetes local (k3d) et Scaleway. Le workspace Cargo racine est publié sous licence MIT.
Ce choix implique plusieurs services à orchestrer, gateway, auth, base de données, temps réel, stockage, fonctions, IA, plutôt qu'un seul processus. En échange, chaque projet reçoit un PostgreSQL 16 dédié (pas un fichier SQLite partagé), avec pgvector 0.8.6 et pg_graphql embarqués dans l'image tenant, et une isolation Row-Level Security au niveau moteur plutôt qu'au niveau applicatif.
Seule nuance notable au cœur pensé Rust : le mode par défaut des fonctions edge s'appuie sur un service TypeScript dédié (V8 Isolates), un compromis d'ingénierie documenté en détail dans le dossier d'architecture cité plus haut, pas une omission qu'on préfère taire.
Trois architectures, résumées côte à côte
Les colonnes sh0.dev et TrailBase marquées « à vérifier » reflètent une recherche non exhaustive de notre part sur ces deux outils, pas une absence confirmée de la fonctionnalité chez eux.
Souveraineté UE : ce qui ne dépend pas du choix du binaire
Auto-héberger un backend écrit en Rust, quel qu'il soit, ne garantit rien en soi sur la souveraineté UE. Deux conditions distinctes doivent être réunies : le serveur physique doit tourner dans l'Union européenne, et vous devez en garder le contrôle opérationnel réel. Ni sh0.dev, ni TrailBase, ni Aurabase ne peuvent garantir la seconde condition à votre place : c'est vous qui choisissez où déployer le binaire ou les conteneurs.
La juridiction de l'éditeur du logiciel compte aussi, mais sur un axe différent : celui d'une version gérée par le fournisseur plutôt que votre propre auto-hébergement. C'est l'angle CLOUD Act détaillé dans notre article sur le choix d'un BaaS. Pour l'infrastructure managée d'Aurabase elle-même : elle tourne, vérifié en production, sur des datacenters Hetzner à Nuremberg et Falkenstein (Allemagne) ainsi qu'à Helsinki (Finlande). C'est la souveraineté UE telle qu'elle existe réellement aujourd'hui, distincte du siège social parisien d'Aurabase SAS.
Quand choisir quoi
Si l'empreinte de déploiement est le critère numéro un, un VPS minimal, un edge device, un projet où chaque mégaoctet compte, sh0.dev ou TrailBase méritent un essai. Ce sont des choix défendables pour ce cas d'usage précis, même si nous n'avons pas nous-mêmes testé leur comportement en production.
Si votre projet a besoin d'un vrai multi-tenant avec Row-Level Security avancée, d'un Postgres complet plutôt que SQLite, ou d'IA native (NL2SQL, RAG) sans assemblage tiers, Aurabase couvre ce terrain. C'est aussi le chemin le plus direct si vous partez d'un projet Supabase existant : Aurabase se positionne alors comme une alternative à Supabase écrite en Rust, avec un SDK et des policies RLS qui visent une compatibilité quasi directe, documentée dans notre guide de migration.