SaaS architecture
A multi-tenant application serves multiple customers from one product while keeping each customer's data isolated from the others.
Before designing the screens, decide where that isolation lives. Two common architectures are a shared database with a tenant identifier and a separate database for each tenant. PHPRunner can support either model, but it cannot make the architectural choice for you.
All tenants use the same tables. Each business row carries TenantID or an equivalent ownership key.
Operationally simple for schema changes, but every query and security rule must preserve tenant isolation.
Each customer has a separate database with the same schema while a central database identifies the tenant and connection.
Isolation and per-customer backup can be simpler, but provisioning and schema upgrades must be automated across many databases.
Quick answer: Choose the tenant boundary before you build the UI. Shared databases centralize operations but make tenant filtering critical; separate tenant databases strengthen physical separation but require disciplined provisioning and schema management.
One schema serves everyone, so tenant identity becomes part of almost every business query.
In a shared model, Orders might contain TenantID in addition to OrderID and CustomerID. The logged-in user is associated with a tenant, and every page, report, export, API, and background process must apply the same tenant restriction.
This model can be efficient when there are many small tenants because schema upgrades happen once. Its main design risk is accidental cross-tenant access if any query forgets the ownership rule.
The connection itself becomes part of the security and routing model.
A central login or tenant directory can identify which database belongs to the user. After login, the application connects to that tenant's database for business data.
The separation is conceptually clear and individual backups or customer-specific moves can be easier. The cost is operational: new tenants need databases, and every schema change must be applied reliably to all tenant databases.
A practical PHPRunner SaaS example demonstrates this architecture by keeping a central users database and routing each user to a customer database with the same structure.
Think about the hundredth tenant, not only the first two.
| Question | Shared database | Database per tenant |
|---|---|---|
| Onboard a customer | Create tenant/account records | Create tenant records plus a new database |
| Schema upgrade | Apply once | Apply to every tenant database |
| Backup one customer | Requires tenant-aware export or restore | Naturally separated |
| Move one customer | Extract tenant data carefully | Move that customer's database |
| Cross-tenant analytics | Straightforward with correct filtering | Requires aggregation across databases |
The goal is to keep the architecture understandable while reducing repetitive application work.
PHPRunner can support multiple database connections and custom connection logic, making it possible to implement either tenant pattern when the project requires it.
| Need | PHPRunner approach |
|---|---|
| Shared-database model | Use record-level security and tenant ownership fields consistently across application pages. |
| Database-per-tenant model | Use a central identity/tenant source and select the appropriate business database connection after login. |
| Common application | Keep one project and consistent page structure while tenant data remains isolated. |
| Customization | Add provisioning, billing, tenant administration, or other SaaS-specific workflows through application logic. |
The tenant boundary is an architecture decision, not a page-design setting.
Both models can work. Choose based on isolation requirements, number and size of tenants, backup needs, operational tooling, and how frequently the schema changes.
Whichever model you choose, make tenant isolation a first-class rule that is applied to every route through which data can be read or changed.