Skip to main content
REG121 isolates every site at the database level. Each site is backed by its own dedicated Postgres schema. The application layer for any given site has no structural path to the schema of any other site. This is not application-level separation enforced by conditional queries — it is a structural boundary enforced at the database layer.

​
Database-Level Isolation

Tenant isolation in REG121 is enforced at the database level using two complementary mechanisms: schema-level isolation and row-level isolation. Together they ensure that data belonging to one site cannot be reached from another site, regardless of application-layer behavior. Schema-level isolation is the primary boundary. Each site has its own Postgres schema. When the application layer for site A executes a query, that query operates within site A’s schema. There is no mechanism in the application layer by which a query for site A can reach data in site B’s schema. Row-level isolation provides an additional layer of enforcement within the database, reinforcing the schema boundary and ensuring that even within the database engine, cross-tenant data access is structurally prevented. This boundary is enforced at the database level, not only in application code. Relying solely on application-level logic to prevent cross-tenant data access introduces risk when logic has bugs; REG121’s model does not depend on that. The schema boundary exists independently of any application-layer access control. This means the isolation guarantee holds structurally — it is not contingent on correct query construction or middleware behavior in the application layer.

​
What Is Isolated

All data generated and stored for a site lives within that site’s isolated schema boundary. This includes:
  • User accounts and session data (authentication)
  • Form submissions
  • Custom table data
  • REST API scope — the generated API for a site operates against that site’s schema only
No data category is stored in a shared cross-site table or namespace. Every record belonging to a site is scoped to that site’s schema.

​
What This Means for You

As a developer building on REG121, you do not need to implement tenant isolation yourself at the infrastructure level. The database boundary between your site and any other site is enforced structurally — cross-tenant data leakage at the infrastructure level is not a risk you carry. You can build features, expose APIs, and store user data with the assumption that the underlying data store is already partitioned to your site. There is no database-level mechanism by which a defect in your application code could inadvertently read or write another site’s data.
Infrastructure-level isolation covers separation between sites. Access controls within a single site — for example, restricting which authenticated user can read or modify which rows — are your responsibility to implement in your application logic. REG121 does not automatically enforce within-site row-level permissions based on the authenticated user’s identity.