Aurabase Logo
aurabasedocs
docs›Services›Database (Postgres)

Database

PostgreSQL 16, a dedicated database per project on your organization's cluster, isolated schemas, auto-generated TypeScript types, native RLS. No forks, no rewrite proxies — your extensions, triggers and PL/pgSQL work as is.

8 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

Postgres 16, without abstraction

The aura-db service exposes a generic CRUD on top of a PostgreSQL 16: each project has its own database, hosted on your organization's PostgreSQL cluster (a cluster entirely dedicated to a single project on the enterprise offer). Each SDK call is translated into native SQL via a thin layer that respects the RLS policies injected into the session.

You can also bypass the SDK and point Prisma, Drizzle, Kysely or psql directly to the connection string — we expose the standard port 5432 with PostgreSQL wire protocol.

Astuce

A pg_dump gives you your complete database (schema, data, extensions, policies). No lock-ins, trivial outbound migration.

#
Mental model

The SDK calls PostgREST, which calls Postgres

Under the hood, the SDK serializes your .from().select()… calls into an HTTP request to aura-db which delegates to a PostgREST sidecar. PostgREST translates to SQL and opens a pooled connection via PgBouncer with the search_path of the injected project.

internal flowtext
SDK        → HTTPS    GET /v1/db/sensors?select=id,name
Gateway    → aura-db  Vérification de session & Routage
aura-db    → PgBouncer → PostgreSQL 16

# Connection with search_path project
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;
Info

RLS policies have access to auth.uid(), auth.role(), auth.tenant(). These helpers read request.jwt.claims injected by the gateway — impossible to tamper with on the client side.

#
Primitives

Six native abilities

Schema-per-project

Partitioning applied by PostgreSQL: no tenant_id column, one connection role per project, rights never opened to PUBLIC.

§ foundation

Versioned migrations

Versioned SQL, atomic rollback, zero-downtime. TypeScript types regenerate with each migration.

§ migration

Codegen TypeScript

Automatic generation of types for tables, views, enums and RPC functions during each migration.

§ typing

Native EPIRB

Testable declarative policies. The SDK injects the claim tenant into each connection.

§ security

Premium extensions

pgvector, PostGIS, pg_cron, TimescaleDB, PGMQ, pg_partman. Fixed versions, audits.

§ extensions

Branch previews

An ephemeral database by PR, with cloned seed data and unique URL — roadmap, not yet delivered.

§ roadmap

#
Minimal example

CRUD complete, typed

The four basic operations share the same .from(table)surface. Returned types are inferred from your schema — open your IDE, autocomplete works on columns, joins and returns.

queries.tstypescript
// List the last 50 active sensors
const { data, error } = await aura
  .from('sensors')
  .select('id, name, temperature, location!inner(city)')
  .eq('active', true)
  .order('captured_at', { ascending: false })
  .limit(50)
Astuce

Need more complex SQL? Create a Postgres function and call it via aura.rpc('function_name', args). Functions benefit from the same RLS policies as tables.

#
GA Extensions

14 extensions ready

Activated in one click from the Studio. Fixed versions, coordinated updates, shared security audit.

pgvector 0.7

PostGIS 3.5

pg_cron 1.6

TimescaleDB 2.17

PGMQ 1.4

pg_partman 5.1

pg_stat_statements

pgcrypto

citext

uuid-ossp

hstore

ltree

pg_trgm

an accent

Last updated · Apr 15, 2026