Aurabase Logo
aurabasedocs
docs›Foundations›Architecture

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.

9 min read·Level intermediate·Revised on Apr 15, 2026
This English text was generated automatically from the French original and has not been reviewed yet.
#
Overview

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.

Info

The entire platform is open-source under the Apache 2.0 license and available on GitHub on the official Aurabase repository.

#
The 8 services

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

Astuce

Modular architecture: Microservices share strict data contracts and unified security primitives (end-to-end encryption, JWT ES256, RLS).

#
Mental model

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.
Attention

Exception: Schema aura_console is shared. It contains the projects table and global Studio sessions. No application data passes through it.

#
Query flow

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.

flux.logtext
# 1. HTTPS Termination & API Gateway
Client HTTPS → aura-gateway (/v1/db/devices)

# 2. Middleware request_id + tracing
request_id = "req_7f3c..."   trace_id = "4a2e..."

# 3. Rate limit (token bucket per IP + API key)
RATE_LIMIT_RPS=100   burst=200

# 4. Authentication — JWT decoding + claims verification
Auth Middleware → { sub: "u_9k2", project_id: "p_a7f3", role: "authenticated" }

# 5. Circuit breaker — Dispatch to data service
circuit_breaker[aura-db] = HEALTHY   proceed

# 6. PostgreSQL execution with schema isolation and RLS
SET search_path TO project_a7f3_, public;
SELECT id, value FROM devices ORDER BY last_seen DESC LIMIT 50;
Astuce

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.

#
Horizontal scale

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

Last updated · Apr 15, 2026