> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reg121.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Database & Schema: Real Postgres DDL for Every Site

> REG121 generates real Postgres DDL for every custom table, scoped to each site's isolated schema — not simulated or abstracted storage.

Every custom table you define in REG121 is materialized as actual DDL against a real Postgres schema. There is no abstraction layer simulating relational storage — when a table is created, a `CREATE TABLE` statement is executed against that site's dedicated schema.

## Schema Generation

When you create a custom table for a site, REG121 generates and executes the corresponding `CREATE TABLE` DDL directly against the site's isolated Postgres schema. The schema is derived from the data model you describe — field names, types, and relationships are translated into real database objects, not virtual representations.

Each site has its own schema namespace within the database. Objects created for one site exist within that site's schema boundary and are not shared with or accessible from any other site's schema.

## Schema Access & Migrations

<Warning>
  Schema access methods, migration workflow, and any CLI or dashboard tooling for direct schema management are not yet documented here. This section will be updated once confirmed with engineering. Contact REG121 support for current guidance.
</Warning>

Direct schema access — including connection credentials, migration tooling, and any CLI or dashboard interfaces for schema introspection or modification — is not yet publicly documented. Do not rely on inferred connection patterns or undocumented endpoints for production integrations.

## Data Types & Constraints

Tables generated by REG121 use standard Postgres data types and constraints, selected to match the data model described for the site. The generated schema reflects idiomatic Postgres — types and constraints are not invented by the platform but derived from what Postgres natively supports.

No custom or proprietary type system is introduced. If your data model specifies a numeric field, an appropriate Postgres numeric type is used. If uniqueness or nullability is required, the corresponding constraint is applied at the DDL level.

Because the schema is real Postgres DDL, any tool or library that operates against standard Postgres — including query builders, ORMs, and introspection utilities — will interact with the schema as expected, subject to access permissions once those are confirmed and documented.