What is multi-tenancy?

Multi-tenancy: definition and importance

A tenant is a delimited unit within a piece of software: a customer company, a branch or a subsidiary. A multi-tenant application runs once but serves many tenants, each with its own users, data and often its own design and settings. Nearly every SaaS solution is based on this principle.

The opposite is the single installation: the software is run separately for each customer. This offers maximum separation but causes high effort for operations and updates. Multi-tenancy makes software economically scalable, but requires a careful architecture so that no tenant ever sees another’s data.

How multi-tenancy works

There are several architecture models. With a shared schema, all tenants sit in the same tables, every row carries a tenant ID, and every query filters by it. With a schema per tenant, each has its own area in the same database; with a database per tenant, its own complete database. The strongest model is a separate instance per tenant.

The further the separation goes, the higher the isolation and the effort. The shared schema is cheapest but demands discipline: databases such as PostgreSQL offer row-level security, which enforces row filters. Separate databases make backups, deletions and moving individual tenants to their own servers easier.

Real-world example: industry software for property managers

A software vendor develops a platform for property management companies. Each company is a tenant with its own properties, tenants, documents and staff; templates, logo and roles can be configured per company. Improvements and security updates are rolled out once and are immediately available to all customers.

One company requires its own database in Germany because of its own requirements. Because the architecture was designed for this, that tenant can be operated in isolation without touching the others. This shows the value of an early decision on the separation model: changing it later takes great effort.

Benefits, limits and common mistakes

The benefits are lower operating costs, central updates and fast onboarding of new customers. The limits: an error or outage potentially affects all tenants, heavily loaded tenants can slow down others (“noisy neighbor”), and individual requests from single customers can be met only to a limited extent. Typical mistakes:

• Forgetting the tenant filter in individual queries—the classic risk for data leaks
• Not separating files, caches or search indexes by tenant
• No way to back up, restore or delete individual tenants
• Retrofitting multi-tenancy into a single-customer application
• Hard-coding individual customer requests instead of keeping them configurable

What businesses should look out for

Decide early how many tenants and what degree of separation you need—depending on data protection and customer requirements. With external customers, a data processing agreement is part of the package. Nano Concepts develops SaaS platforms and portals with clean tenant separation, a role model and tests that specifically verify that no tenant can reach another’s data.