Database

Le service aura-db expose un CRUD générique au-dessus d'un PostgreSQL 16 : chaque projet a sa propre base de données, hébergée sur le cluster PostgreSQL de votre organisation (un cluster entièrement dédié à un seul projet sur l'offre entreprise). Chaque appel SDK est traduit en SQL natif via une couche fine qui respecte les RLS policies injectées dans la session.

Vous pouvez aussi bypasser le SDK et pointer Prisma, Drizzle, Kysely ou psql directement sur la connection string — nous exposons le port 5432 standard avec wire protocol PostgreSQL.

Sous le capot, le SDK sérialise vos appels .from().select()… en requête HTTP vers aura-db qui délègue à un sidecar PostgREST. PostgREST traduit en SQL et ouvre une connexion pooled via PgBouncer avec le search_path du projet injecté.

SDK        → HTTPS    GET /v1/db/sensors?select=id,name
Gateway    → aura-db  Vérification de session & Routage
aura-db    → PgBouncer → PostgreSQL 16
# Connexion avec search_path projet
SET LOCAL search_path = project_a7f3_, public;
SET LOCAL request.jwt.claims = '{ "sub": "u_9k2", "tenant": "t_4c" }';
SELECT id, name, temperature FROM sensors WHERE active = true LIMIT 50;

Les quatre opérations de base partagent la même surface .from(table). Les types retournés sont inférés depuis votre schéma — ouvrez votre IDE, autocomplete fonctionne sur les colonnes, les joins et les retours.

// Lister les 50 derniers sensors actifs
const { data, error } = await aura
  .from('sensors')
  .select('id, name, temperature, location!inner(city)')
  .eq('active', true)
  .order('captured_at', { ascending: false })
  .limit(50)

Activables en un clic depuis le Studio. Versions fixées, mises à jour coordonnées, audit de sécurité partagé.