Multi-tenancy all the way down: a model designed for SaaS applications

Praxys is being designed for a more demanding situation. Praxys creators build applications that can themselves serve many customer organisations. The platform therefore distinguishes the relationship between Praxys and a creator from the relationship between that creator's application and its customers. That distinction is the foundation for a tenancy model that can grow without blurring ownership, identity, or data access.

Name each level precisely

"Tenant" is too overloaded to be useful on its own. Praxys uses four explicit terms:

• An account is a Praxys customer: a creator, agency, or service provider that owns applications. It is an ownership and billing concept, not part of every application request.
• An app is a deployed product built on Praxys. It is the first runtime level and has its own codebase, database, secrets, and domain configuration.
• A sub-tenant is a customer organisation within a multi-tenant app—for example, a company using a creator's SaaS product.
• A user is a person acting in an app, either within a sub-tenant or directly in a single-tenant app. Roles and capabilities determine what that person may do.

This vocabulary prevents an important class of mistakes. The runtime request context carries the app, optional sub-tenant, and user; it does not casually carry the creator account into every operation. Ownership metadata stays where it belongs, while the information required to make an access decision stays close to the request.

Different modes, different code shapes

Praxys treats single-tenant and multi-tenant applications as distinct application shapes, not one codebase with a hidden switch.

A single-tenant application has app-level identity and users, but no sub-tenant routing, tenant-management interface, or tenant-scoped tables. An internal tool is a good example. It should not carry the overhead or attack surface of a model it does not use.

A multi-tenant application adds the sub-tenant level deliberately. Tenant-scoped data carries a tenant identifier; requests resolve a tenant context; tenant-focused interface blocks become available; and generated database access is expected to remain within that context. A person may participate in more than one sub-tenant, but their application identity is scoped to that membership—so the same external login in two customer organisations does not become an implicit cross-organisation identity.

The compiler reinforces this distinction. It reads the project's tenancy mode and generates the appropriate shape. Its tenancy pass rejects database-query patterns that bypass tenant scoping, unless the code takes an explicit cross-tenant path. This gives the platform a practical guardrail during generation, rather than relying only on a team's code-review checklist.

Isolation at the right boundary

The intended deployment model gives each app its own database. That boundary is designed to limit the blast radius of an application defect and keep one application’s operational data, secrets, and lifecycle separate from another’s.

Within a multi-tenant app, the intended v1 isolation model is row-level separation. Per-app data stores expose tenant-scoped rails that add the tenant condition to reads and writes. Database row-level security can provide a second enforcement layer where the deployment uses it. Exceptional cross-tenant access must be explicit and auditable rather than silently available through an unrestricted database client.

The model is designed to evolve from there. Schema-per-tenant and database-per-tenant options are future isolation tiers for workloads that require them, but they are not presented as current defaults. Starting with a clear row-level boundary keeps the initial operating model practical while preserving a path to stronger separation.

The hierarchy at a glance

⤢ enlarge

×

The diagram also shows a deliberate boundary: the account owns the app, but it is metadata above the request path. A request is authorised using the identity and tenancy context of the running application, not by treating the creator account as an all-purpose credential.

A staged rollout, not a retrofit

Today, Praxys' v1 application runtime ships the single-tenant path. The multi-tenant contract, data model, compiler checks, and tenant-scoped storage rails are being established ahead of activation rather than retrofitted after applications have accumulated data and users. That is a material architectural choice: it lets new multi-tenant capabilities arrive as an additive activation, instead of forcing creators through a disruptive rewrite.

For customers, the value is straightforward. An internal tool can stay simple. A SaaS product can adopt a tenancy model designed around customer organisations, scoped access, and data separation. In both cases, the platform gives the application a clear model from the first generated schema and request handler.

Multi-tenancy is a contract shaping the runtime, compiler, data layer, and application templates. The implementation work is intended to make future activation additive rather than a retrofit; availability remains part of the preview conversation.