Database

The control plane keeps its state in one PostgreSQL database (PostgreSQL 18 or newer). This dictionary is generated from the shipped schema — the drizzle snapshot behind the newest migration — joined with the maintained descriptions in the TurboPanel/turbopanel repository. The same descriptions are applied to the live database as COMMENT ON metadata, so \d+ table in psql and this page always say the same thing.

Tables by area

How to read this dictionary

• Physical names. Every table is one lower-case word (seat, copy, 2fa); the drizzle export names in schema.ts sometimes differ. Pages and anchors use the physical name.
• Standard columns. Every table has id (uuid, defaulting to uuidv7() so keys are time-ordered and collision-free across writers), created_at and, on mutable tables, updated_at. They are listed for completeness but never described per table.
• Foreign keys are shown inline as FK → table.column (on delete …). A plain parent link named <table>_id carries no further text; a foreign key under another name (assigned_tier_id, actor_user_id) always does, because the name signals a rule.
• Vocabularies. A column with a fixed value set carries a CHECK (col IN (…)) listed under Constraints and indexes; the description names the members. Provider-owned vocabularies keep a raw provider_* copy beside the normalized column.
• metadata / options. Tables that carry them declare both, both nullable, right after the timestamps: metadata is free-form, options is validated by the writer named in its description.
• Booleans are named is_*; NULL on a boolean means not set, not false.
• Secrets are never stored in the clear: a column holding one says so and names the envelope format.

To change a description, edit src/lib/db/schema-descriptions.ts in the turbopanel repository and follow the Schema descriptions loop in its AGENTS.md; a schema change regenerates these pages as part of the same migration.