What is Multi-tenancy and tenant isolation?
Multi-tenancy is an architecture in which one running instance of an application serves many customer organisations, called tenants. Tenant isolation is the set of controls that keep each tenant data, users and configuration separate, so no organisation can see or change another. Isolation can rely on separate databases, separate schemas or shared tables with enforced row filtering.
How Personal Academy handles it
Personal Academy runs every organisation in one database, isolated by restrictive row-level security on each business table, with each organisation on its own sub-domain.
A worked example
Suppose a training provider serves a 300-person hospital group and a 60-person architecture practice on the same platform. Each customer signs in at its own sub-domain, sees its own branding, courses and learners, and has its own administrators. When the provider ships an update, both customers receive it at once, but neither can ever query, enrol or report on the other customer people.
Software sold as a service usually serves many customers from shared infrastructure. The alternative, a separate installation for each customer, is easier to reason about but costly to run and slow to update. Multi-tenancy trades some of that simplicity for one codebase, one upgrade path and lower running cost.
There are three common isolation models. Database per tenant gives the strongest separation and simple backups per customer, but many databases are expensive to operate. Schema per tenant keeps one database with a separate set of tables for each customer. Shared tables keep every customer in the same tables with a tenant identifier column on each row, which scales best but depends entirely on that identifier being checked everywhere.
In the shared table model, isolation is usually enforced at more than one layer. The application resolves the tenant from the request, often from the sub-domain or a signed token. The database then enforces row-level security so that queries only touch rows for that tenant. File storage, caches, search indexes and background jobs need the same discipline, because each is a place where data from two tenants could meet.
Isolation also covers configuration and identity. Each tenant typically has its own single sign-on settings, roles, branding and feature entitlements. Administrators in one tenant must never be able to act in another, and platform staff access should be time-boxed and logged.
When evaluating a multi-tenant product, ask which isolation model it uses, where the tenant check is enforced, whether any tables are exempt and why, and how the vendor tests that one tenant cannot read another.