Database & migrations

Every module owns its own PostgreSQL schema, isolated from the core and from the other modules. Queries are checked at compile time by SQLx.

Schema isolation #

A module named calendar only creates tables in the calendar schema. No foreign key crosses schemas: modules stay decoupled.

Migrations #

Migrations live in migrations/, versioned and numbered. They are applied at startup (or through the CLI). Naming convention:

migrations/
├── 000001_calendar_schema.up.sql
├── 000001_calendar_schema.down.sql
├── 000002_calendar_attendees.up.sql
└── 000002_calendar_attendees.down.sql

Tip

The core itself follows the same convention (the core schema): users, sessions, modules, settings, jobs, event_log, themes, MCP, push…

SQLx & the offline cache #

Queries use the compile-time-checked macros (sqlx::query_as!). A .sqlx cache lets you build without a database (CI, packaging):

# Build hors-ligne (utilise le cache .sqlx, aucune DB requise)
SQLX_OFFLINE=true cargo build --release

# Régénérer le cache après un changement de requête/schéma
DATABASE_URL=postgres://… cargo sqlx prepare   # puis commitez le dossier .sqlx

Injected connection #

The core supervisor hands the module process its database credentials through the environment (KUBUNO_DB_HOST, KUBUNO_DB_PORT, KUBUNO_DB_USER, KUBUNO_DB_PASSWORD, KUBUNO_DB_NAME).