This comparison focuses on self-hosting Rust-native backends: sh0.dev, TrailBase and Aurabase. For a more general self-hosted backend, not written in Rust, our comparisons Aurabase vs PocketBase and Aurabase vs Appwrite explore other options. For the complete analysis of what “EU sovereignty” means legally, hosting and nationality of the publisher, our article self-hosting versus an EU sovereign BaaS goes further; This post is limited to placing Aurabase among its Rust peers.
The essentials
- Three real options today for a self-hosting Rust-native backend: sh0.dev (single binary, ~25 MB), TrailBase (Rust + embedded SQLite + SolidJS interface), Aurabase (full platform, dedicated Postgres 16).
- Aurabase assumes the opposite compromise of a mono-binary: several orchestrated services (k3d locally or Kubernetes/Helm in production) in exchange for multi-tenant RLS, real-time CDC and native AI (NL2SQL, RAG).
- Self-hosting and EU sovereignty are two distinct axes: hosting yourself does not guarantee anything as long as the physical server and the publishing company are not themselves in the EU.
- Information about sh0.dev and TrailBase based on their public pages at the time of writing, not thoroughly audited: check their up-to-date documentation before making any decisions.
Why “Rust-native” matters for self-hosting
A self-hosted backend removes the infrastructure from a cloud provider's perimeter, but not the responsibility to run it reliably. This is where the choice of language ceases to be a detail: Rust's memory security and lack of garbage collector reduce an entire class of production failures, those that hit hardest a small team that operates its own server.
This is not a pure performance argument. A service that does not segfault and does not have unpredictable memory collection pauses is easier to monitor for a team without a dedicated SRE. The actual architecture of Aurabase's core, 18-crate Cargo workspace compiled together, is documented in detail in our Rust architecture file.
“Open source” alone is not enough to guarantee portability or lack of lock-in: the actual architecture, single-tenant or multi-tenant, proprietary or standard storage engine, matters more. sh0.dev, TrailBase and Aurabase all provide access to the source code, but with very different scopes and data models.
sh0.dev: a unique Rust binary, designed for minimalism
sh0.dev presents itself, according to its public pages at the time of writing, as a backend distributed in the form of a single Rust binary of around 25 MB. The central argument is the simplicity of deployment: a file to copy to a server, without external dependencies to install separately.
We have not audited the exact functional scope or licensing model of sh0.dev in detail for this article: publicly available information on this subject remains limited, and a project of this type evolves quickly. If this criterion weighs in your decision, check its up-to-date official documentation before deciding.
TrailBase: Rust core, embedded SQLite, SolidJS interface
TrailBase combines, according to its public pages, a backend core written in Rust, an embedded SQLite database and an administration interface built with SolidJS, all delivered as a self-hosting project. The architecture is reminiscent of PocketBase (Go, SQLite, integrated interface), with a runtime written in Rust rather than Go.
As with sh0.dev, this article does not claim to have thoroughly checked the TrailBase code or roadmap. What we can say with confidence is the general architectural positioning: a binary that embeds its own storage engine rather than a backend backed by an external Postgres.
Aurabase: dedicated Postgres 16, complete platform, also self-hosted
Aurabase assumes a different tradeoff than a mono-binary. The repository provides a local Kubernetes cluster (k3d) launched in one command via ./start.sh, as well as a full Helm chart (deploy/helm/aurabase/) with separate value profiles for Hetzner, a local Kubernetes bench (k3d), and Scaleway. The root Cargo workspace is released under the MIT license.
This choice involves several services to be orchestrated, gateway, auth, database, real time, storage, functions, AI, rather than a single process. In exchange, each project receives a dedicated PostgreSQL 16 (not a shared SQLite file), with pgvector 0.8.6 and pg_graphql embedded in the tenant image, and Row-Level Security isolation at the engine level rather than at the application level.
The only notable nuance to the Rust core: the default mode for edge functions relies on a dedicated TypeScript service (V8 Isolates), an engineering compromise documented in detail in the architecture file cited above, not an omission that we prefer to keep quiet.
Three architectures, summarized side by side
The sh0.dev and TrailBase columns marked “to check” reflect a non-exhaustive search on our part on these two tools, not a confirmed absence of functionality from them.
| Criterion | Aurabase | sh0.dev | TrailBase |
|---|---|---|---|
| Main language | Rust (full workspace, 18 crates) | Rust (single binary) | Rust (core) + SolidJS (interface) |
| Deployment footprint | k3d locally or Helm/Kubernetes in production, several services | Single binary, ~25 MB | A single binary, embedded SQLite |
| Database | PostgreSQL 16 dedicated per project + pgvector + pg_graphql | To be verified (official doc) | Embedded SQLite |
| Administration interface | Separate Next.js studio | To check | SolidJS interface integrated into binary |
| Native AI (NL2SQL / RAG) | Yes, checked in code (aura-ai) | To check | To check |
| Official voice on this comparison | This comparison, published by Aurabase | None, unsolicited | None, unsolicited |
EU sovereignty: which does not depend on the choice of binary
Self-hosting a backend written in Rust, whatever it may be, does not in itself guarantee anything regarding EU sovereignty. Two distinct conditions must be met: the physical server must run in the European Union, and you must maintain actual operational control of it. Neither sh0.dev, nor TrailBase, nor Aurabase can guarantee the second condition for you: you choose where to deploy the binary or containers.
The jurisdiction of the software publisher also matters, but on a different axis: that of a version managed by the supplier rather than your own self-hosting. This is the CLOUD Act angle detailed in our article on choosing a BaaS. For the Aurabase managed infrastructure itself: it runs, verified in production, on Hetzner data centers in Nuremberg and Falkenstein (Germany) as well as in Helsinki (Finland). This is EU sovereignty as it actually exists today, distinct from the Paris headquarters of Aurabase SAS.
Details of the compliance criteria to check before choosing accommodation, sovereign or not: our page compliance.
When to choose what
If deployment footprint is the number one criterion, a minimal VPS, an edge device, a project where every megabyte counts, sh0.dev or TrailBase are worth a try. These are defensible choices for this specific use case, even if we have not ourselves tested their behavior in production.
If your project needs true multi-tenancy with advanced Row-Level Security, full Postgres rather than SQLite, or native AI (NL2SQL, RAG) without third-party assembly, Aurabase covers that ground. It is also the most direct path if you start from an existing Supabase project: Aurabase is then positioned as an alternative to Supabase written in Rust, with an SDK and RLS policies which aim for almost direct compatibility, documented in our migration guide.