Multi-tenant LMS architecture: options and trade-offs

A multi-tenant LMS serves several client organisations, departments or brands from one platform while keeping each tenant's users, data, branding and administration separate. There are four main ways to build one: separate instances per tenant, a shared database with a tenant ID on every record, a database per tenant on shared application code, or a platform's built-in tenancy features such as Moodle Workplace tenants, IOMAD companies, WordPress Multisite or Open edX sites.

The right choice is a trade-off between isolation, cost, customisation, upgrade effort and cross-tenant reporting. Training providers selling to many small clients usually favour shared infrastructure with logical isolation. Enterprises with strict data residency or contractual separation often need physical isolation for at least some tenants. This guide explains each option, compares them in a trade-offs table, and covers the cross-cutting concerns that decide success: branding, SSO per tenant, data residency and billing.

What multi-tenancy means for an LMS

In a multi-tenant LMS, each tenant should experience the platform as if it were their own: their logo and colours, their users, their course catalogue, their managers who can only see their people, and their reports. Behind the scenes you, as operator, want one codebase, one upgrade process and, ideally, one place to publish shared content.

Typical requirements include:

• Strict user and data isolation between tenants, including in search, messaging and reports.
• Delegated administration, so tenant managers can add learners and assign courses without seeing other tenants.
• Shared and tenant-specific courses, often with seat limits or licences per tenant.
• Per-tenant branding, domains and login methods.
• Consolidated reporting and billing for the operator.

Architecture option 1: separate instances per tenant

Each tenant gets its own installation, database and often its own server or container. This gives the strongest isolation and complete freedom to customise per tenant, and it makes data residency simple: deploy the instance in the required region.

The costs grow with tenant count. Every instance must be patched, upgraded, monitored and backed up. Shared content must be synchronised across instances, and cross-tenant reporting needs a separate data pipeline. Containerisation and infrastructure-as-code reduce the burden, but upgrades still multiply. This model suits a small number of large, high-value tenants.

Architecture option 2: shared database with tenant IDs

All tenants share one application and one database, with a tenant identifier on every tenant-owned row and every query filtered by it. This is the most cost-efficient model at scale, makes shared content and cross-tenant reporting easy, and means one upgrade covers everyone.

The risk is leakage. A single missing tenant filter in a report, API endpoint or search index can expose one client's data to another. Mitigations include enforcing tenant scoping in a data-access layer rather than in each query, row-level security where the database supports it, automated tests that attempt cross-tenant access, and careful review of every third-party plugin. Noisy neighbours are also a concern: one tenant's bulk import can slow everyone. This is the usual model for custom-built SaaS LMS platforms.

Architecture option 3: database per tenant

One application codebase serves all tenants, but each tenant has its own database or schema, selected at request time from the domain or login. Isolation is stronger than a shared database, per-tenant backup and restore is simple, and a tenant's database can be placed in a specific region.

Trade-offs: schema migrations must run across every tenant database, connection management becomes more complex, and cross-tenant reporting again needs aggregation. It is a good middle ground for regulated clients who want contractual separation without the full overhead of separate instances.

Platform-native tenancy options

Moodle Workplace tenants

Moodle Workplace, the corporate edition of Moodle available only through Moodle Certified Partners and Service Providers, includes built-in multi-tenancy. Its documentation describes a single instance serving multiple organisations whose data and configuration are virtually partitioned: each user belongs to one tenant, users cannot see users in other tenants by default, and tenants have their own users, roles, theme settings, reports and learning content in dedicated course categories. A Shared space tenant can hold programs, certifications and reports used across tenants, and tenant-specific authentication (including OAuth 2 and SAML) is supported. Note the documented caveats: login is not restricted to the user's tenant domain, and add-on plugins may not support multi-tenant domains.

IOMAD

IOMAD is an open source (GPLv3) fork of Moodle designed for multi-tenancy. It organises tenants as companies with departments, supports devolved management and hierarchical reporting, and lets courses be shared with all companies, shared selectively or dedicated to one company. It also includes licence-based course allocation, which suits training providers selling seats to client organisations. IOMAD aims to release new versions within about three months of each Moodle release, so plan upgrades on that lag. Our Moodle development page covers both approaches.

WordPress Multisite

WordPress Multisite runs a network of sites from one installation, with separate database tables per site and a network super admin. Each tenant can have its own subdomain or path, theme settings and administrators. With an LMS plugin this gives reasonable isolation, but users are shared at network level, not every LMS plugin or add-on is fully multisite-aware, and cross-site reporting requires custom work. An alternative is a single WordPress site with group-based tenancy, which is simpler but weaker on isolation.

Open edX sites and organisations

Open edX can host multiple sites on separate domains from one installation. Each site is configured in the Django admin and can have its own theme and its own set of available courses, typically filtered by course organisation. This works well for branded portals on shared infrastructure, but user accounts are shared across the installation, so it is not full tenant isolation without additional development.

Multi-tenant LMS trade-offs table

Cross-cutting concerns

Branding and domains

Decide whether tenants need only a logo and colours, or custom domains, email templates, certificates and terms of use. Custom domains need automated TLS certificate management and a clear rule for which tenant a domain resolves to.

SSO per tenant

Enterprise clients will want learners to log in with their own identity provider. Each tenant may need its own SAML or OIDC configuration, attribute mapping and provisioning, and your platform must route a login to the right provider, usually by domain or email. Our guide to LMS SSO with SAML vs OIDC covers the design choices.

Data residency

If some clients require data to stay in a specific country or region, shared-database models struggle. A hybrid is common: most tenants on shared infrastructure, and residency-sensitive tenants on a dedicated database or instance in their region. Remember file storage, backups, logs and analytics, not just the primary database.

Billing and licensing

Operators usually bill per tenant by active users, seats or course licences. Build seat limits, usage metering and exportable billing data into the design rather than reconstructing them from logs later.

Choosing an approach

• Many small tenants, shared catalogue: shared database or a platform-native option such as IOMAD or Moodle Workplace.
• A few large enterprise tenants with contractual separation: database per tenant or separate instances.
• Mixed portfolio: a shared platform with an escalation path to dedicated infrastructure for premium tenants.
• Branded portals without strict isolation: Open edX sites or WordPress Multisite can be enough.

If you prefer a self-hosted PHP/MySQL platform with organisation management, delegated administration, SAML SSO and SCIM provisioning out of the box, LMS Advisor is another option to evaluate alongside the platforms above. Disclosure: LMS Advisor is built by our team.

How we can help

We design and build multi-tenant learning platforms, from extending Moodle, IOMAD and WordPress to custom architectures with strict tenant isolation, per-tenant SSO and regional data placement. See our enterprise LMS development services, or contact us to review your tenancy requirements before you commit to an architecture.