Esta comparação se concentra em back-ends nativos de Rust auto-hospedados: sh0.dev, TrailBase e Aurabase. Para um back-end auto-hospedado mais geral, não escrito em Rust, nossas comparações Aurabase vs PocketBase e Aurabase vs Appwrite exploram outras opções. Para uma análise completa do que significa legalmente “soberania da UE”, hospedagem e nacionalidade do editor, nosso artigo auto-hospedagem versus um BaaS soberano da UE vai além; Esta postagem se limita a colocar o Aurabase entre seus pares do Rust.
O essencial
- Três opções reais hoje para um backend nativo de Rust auto-hospedado: sh0.dev (binário único, ~25 MB), TrailBase (Rust + SQLite incorporado + interface SolidJS), Aurabase (plataforma completa, Postgres 16 dedicado).
- Aurabase assume o compromisso oposto de um mono-binário: vários serviços orquestrados (k3d localmente ou Kubernetes/Helm em produção) em troca de RLS multilocatário, CDC em tempo real e IA nativa (NL2SQL, RAG).
- O auto-hospedamento e a soberania da UE são dois eixos distintos: o alojamento próprio não garante nada enquanto o servidor físico e a editora não estiverem na UE.
- Informações sobre sh0.dev e TrailBase baseadas em suas páginas públicas no momento da redação, não auditadas minuciosamente: verifique sua documentação atualizada antes de tomar qualquer decisão.
Por que “Rust-native” é importante para auto-hospedagem
Um back-end auto-hospedado remove a infraestrutura do perímetro de um provedor de nuvem, mas não a responsabilidade de executá-la de maneira confiável. É aqui que a escolha da linguagem deixa de ser um detalhe: a segurança da memória do Rust e a falta de coletor de lixo reduzem toda uma classe de falhas de produção, aquelas que atingem mais duramente uma pequena equipe que opera seu próprio servidor.
Este não é um argumento puro de desempenho. Um serviço que não possui falha de segmentação e não possui pausas imprevisíveis na coleta de memória é mais fácil de monitorar para uma equipe sem um SRE dedicado. A arquitetura real do núcleo do Aurabase, espaço de trabalho Cargo de 18 caixas compilada em conjunto, está documentada em detalhes em nosso arquivo de arquitetura Rust.
O “código aberto” por si só não é suficiente para garantir a portabilidade ou a falta de aprisionamento: a arquitetura real, de locatário único ou multilocatário, mecanismo de armazenamento proprietário ou padrão, é mais importante. sh0.dev, TrailBase e Aurabase fornecem acesso ao código-fonte, mas com escopos e modelos de dados muito diferentes.
sh0.dev: um binário Rust exclusivo, projetado para o minimalismo
sh0.dev apresenta-se, de acordo com suas páginas públicas no momento da escrita, como um backend distribuído na forma de um único binário Rust de cerca de 25 MB. O argumento central é a simplicidade de implantação: um arquivo para copiar para um servidor, sem dependências externas para instalar separadamente.
Não auditamos detalhadamente o escopo funcional exato ou o modelo de licenciamento do sh0.dev para este artigo: as informações publicamente disponíveis sobre este assunto permanecem limitadas e um projeto deste tipo evolui rapidamente. Se esse critério pesa na sua decisão, verifique sua documentação oficial atualizada antes de decidir.
TrailBase: núcleo Rust, SQLite integrado, interface SolidJS
TrailBase combina, de acordo com suas páginas públicas, um núcleo backend escrito em Rust, um banco de dados SQLite integrado e uma interface de administração construída com SolidJS, tudo entregue como um projeto auto-hospedado. A arquitetura lembra o PocketBase (Go, SQLite, interface integrada), com um tempo de execução escrito em Rust ao invés de Go.
Tal como acontece com sh0.dev, este artigo não afirma ter verificado minuciosamente o código ou roteiro do TrailBase. O que podemos dizer com confiança é o posicionamento geral da arquitetura: um binário que incorpora seu próprio mecanismo de armazenamento em vez de um backend apoiado por um Postgres externo.
Aurabase: Postgres 16 dedicado, plataforma completa, também auto-hospedada
Aurabase assume uma compensação diferente de um monobinário. O repositório fornece um cluster Kubernetes local (k3d) iniciado em um comando via ./start.sh, bem como um gráfico Helm completo (deploy/helm/aurabase/) com perfis de valor separados para Hetzner, um banco Kubernetes local (k3d) e Scaleway. O espaço de trabalho raiz Cargo é lançado sob a licença MIT.
Esta escolha envolve vários serviços a serem orquestrados, gateway, autenticação, banco de dados, tempo real, armazenamento, funções, IA, ao invés de um único processo. Em troca, cada projeto recebe um PostgreSQL 16 dedicado (não um arquivo SQLite compartilhado), com pgvector 0.8.6 e pg_graphql incorporados na imagem do locatário e isolamento de segurança em nível de linha no nível do mecanismo, e não no nível do aplicativo.
A única nuance notável no núcleo do Rust: o modo padrão para funções de borda depende de um serviço TypeScript dedicado (V8 Isolates), um compromisso de engenharia documentado em detalhes no arquivo de arquitetura citado acima, não uma omissão que preferimos manter em segredo.
Três arquiteturas, resumidas lado a lado
As colunas sh0.dev e TrailBase marcadas como “para verificar” refletem uma pesquisa não exaustiva de nossa parte sobre essas duas ferramentas, e não uma ausência confirmada de funcionalidade delas.
| Critério | Aurabase | sh0.dev | TrilhaBase |
|---|---|---|---|
| Idioma principal | Ferrugem (área de trabalho completa, 18 caixas) | Ferrugem (binário único) | Rust (núcleo) + SolidJS (interface) |
| Pegada de implantação | k3d localmente ou Helm/Kubernetes em produção, vários serviços | Binário único, ~25 MB | Um único SQLite binário incorporado |
| Banco de dados | PostgreSQL 16 dedicado por projeto + pgvector + pg_graphql | A ser verificado (documento oficial) | SQLite incorporado |
| Interface de administração | Estúdio Next.js separado | Para verificar | Interface SolidJS integrada em binário |
| IA nativa (NL2SQL/RAG) | Sim, código verificado (aura-ai) | Para verificar | Para verificar |
| Voz oficial sobre esta comparação | Esta comparação, publicada pela Aurabase | Nenhum, não solicitado | Nenhum, não solicitado |
Soberania da UE: que não depende da escolha do binário
A auto-hospedagem de um back-end escrito em Rust, seja ele qual for, não garante por si só nada em relação à soberania da UE. Devem ser cumpridas duas condições distintas: o servidor físico deve funcionar na União Europeia e deve manter o controlo operacional real do mesmo. Nem sh0.dev, nem TrailBase, nem Aurabase podem garantir a segunda condição para você: você escolhe onde implantar o binário ou contêineres.
A jurisdição do editor do software também é importante, mas em um eixo diferente: o de uma versão gerenciada pelo fornecedor, e não a de sua própria hospedagem. Este é o ângulo do CLOUD Act detalhado em nosso artigo sobre escolhendo um BaaS. Para a própria infraestrutura gerenciada pela Aurabase: ela é executada, verificada em produção, nos data centers da Hetzner em Nuremberg e Falkenstein (Alemanha), bem como em Helsinque (Finlândia). Esta é a soberania da UE tal como existe hoje, distinta da sede da Aurabase SAS em Paris.
Detalhes dos critérios de conformidade a verificar antes de escolher o alojamento, soberano ou não: nossa página conformidade.
Quando escolher o que
Se o tamanho da implantação for o critério número um, vale a pena tentar um VPS mínimo, um dispositivo de borda, um projeto onde cada megabyte conta, sh0.dev ou TrailBase. Estas são escolhas defensáveis para este caso de uso específico, mesmo que não tenhamos testado seu comportamento na produção.
Se o seu projeto precisa de multilocação verdadeira com segurança avançada em nível de linha, Postgres completo em vez de SQLite ou IA nativa (NL2SQL, RAG) sem montagem de terceiros, o Aurabase cobre esse terreno. É também o caminho mais direto se você começar a partir de um projeto Supabase existente: Aurabase é então posicionado como uma alternativa ao Supabase escrito em Rust, com políticas SDK e RLS que visam compatibilidade quase direta, documentadas em nosso guia de migração .