Architecture
Eight independent Axum services, a unified network via NATS, one PostgreSQL cluster per organization. Understand how Aurabase routes a request end-to-end, how each organization and then each project are isolated, and how to scale horizontally without coordination.
One backend, eight services, one network
Aurabase is a Rust monorepo organized into 8 independent Axum binaries. Each listens on its own port, exposes its HTTP /v1/<service>/…routes, and communicates with the others via NATS request/reply.
A service can restart, crash or be deployed independently. The gateway observes everyone's health via a circuit breaker — after 5 consecutive failures on a service, it opens the breaker and responds 503 for 30 seconds, letting the service recover.
The entire platform is open-source under the Apache 2.0 license and available on GitHub on the official Aurabase repository.
Roles and responsibilities
Each microservice has a unique responsibility, dedicated SQL migrations, and strict siloing. All external traffic goes exclusively through the unified gateway.
DepartmentRoleResponsibilities
aura-gatewayAPIProxy gateway, authentication middleware, rate limiting, circuit breaker
aura-authAuthenticationSignup, signin, OAuth 2.1, MFA TOTP & WebAuthn, sessions, JWKS
aura-dbPostgREST CRUD database, versioned migrations, codegen, schema management
aura-realtimeReal-Time EngineWebSocket binary, SSE, event relay, presence, CDC Postgres
aura-storageObject storage Backend S3-compatible, multipart upload, signed URLs, transformations
aura-functionsEdge FunctionsRuntime WASM/Deno, periodic cron, asynchronous job queue, DLQ
aura-notificationsNotificationsTransactional email (SMTP), SMS, mobile push, HMAC signed webhooks
aura-aiAI gatewayUnified LLM inference, calculation of vector embeddings, RAG pgvector
Modular architecture: Microservices share strict data contracts and unified security primitives (end-to-end encryption, JWT ES256, RLS).
One CNPG cluster per organization, one project, four diagrams
Each Aurabase organization receives its own PostgreSQL cluster, provisioned via CloudNativePG (CNPG) in a Kubernetes namespace reserved for it — never shared with another organization. Its capacity (vCPU, memory, replicas) grows with the organization's plan level (Free → Pro → Team).
Inside this cluster, each project receives its own Postgres database, itself divided into four subschemas. Inter-project partitioning is applied by PostgreSQL itself: each project has its own connection role, member of its only roles, and rights on its schemas are only granted to those — never to PUBLIC. The gateway injects the connection search_path from the client JWT, and the application tables are protected by RLS.
On the enterprise offer, a project can also receive a fully dedicated CNPG cluster, reserved for itself in its own namespace: partitioning is then ensured by the physical separation of the clusters, not only by the permissions and logical isolation of the shared namespace.
SchemaOwnerContent
project_{uuid}userYour business tables
project_{uuid}_authaura-authusers, sessions, oauth_accounts, mfa
project_{uuid}_storageaura-storagebuckets, objects, rls_policies
project_{uuid}_platformplatformfunctions, jobs, cron, api_keys, webhooks
Three guarantees
- Organizational isolation — no cluster, Kubernetes namespace or connection pool is ever shared between two different organizations: no cross-tenant leaks, no noisy neighbors from another client.
- Independent migrations — each project evolves at its own pace; a rollback only affects him.
- Trivial export —
pg_dump --schema=project_*renders your entire database, extensions and policies included.
Exception: Schema aura_console is shared. It contains the projects table and global Studio sessions. No application data passes through it.
From curl to Postgres, in seven steps
The gateway validates each incoming request before routing it. Here is the full path of a GET /v1/db/{projectId}/rows?table=devices from a REST client.
Observability baked-in. Each step logs structured via tracing + EnvFilter. JSON logs are correlated by request_id and can be exported to Datadog, Honeycomb or your SIEM via webhook.
Add capacity, not coordination
Services are stateless. Adding a replica means starting a new binary and connecting it to NATS — it joins the cluster automatically and starts serving as soon as it's ready. No leader, no elections, no distributed coordination.
GATEWAY
1M req/s
Anycast BGP + load balancer L7
DB
96 vCPU
Vertical scale up on demand
REALTIME
1M cnx/POP
Fan-out via NATS JetStream
FUNCTIONS
2.4M/day
WASM isolated, memory safe