What is a multi-tenant architecture?
A multi-tenant architecture is a setup in which a single application serves multiple customers (tenants) and cleanly separates their data on a logical level. They all use the same software and infrastructure but each see only their own data.
Also known as: multi-tenancy · tenant capability · multi-tenant-capable architecture
Where a multi-tenant architecture is used
Multi-tenancy is the basic principle of many SaaS solutions and digital platforms. Instead of running a separate installation for each customer, a shared application runs that separates data and configurations per tenant. This significantly reduces operating and maintenance effort because updates and security fixes only have to be applied once.
Technically, the separation can be implemented through separate databases, separate schemas or shared tables with a tenant identifier. In Microsoft Azure this is often combined with Azure App Service and a managed database such as Azure Database for PostgreSQL.
A practical example
A SaaS platform serves ten insurance customers through the same application. Each tenant logs in through its own area and sees only its own cases and data. In the background, a tenant identifier ensures that every query stays strictly limited to the respective customer – a new connection requires no separate installation, just one more tenant.
How it relates & how smiit uses it
In contrast to a single-tenant architecture, where each customer gets its own instance, with multi-tenancy everything shares one foundation – this saves cost but requires especially careful data separation and access control. smiit built Claimity AG's SaaS platform multi-tenant-capable from the ground up on Microsoft Azure: the multi-tenant architecture reliably separates customer data, Keycloak controls identity and MFA, and operations are GDPR-compliant throughout. This allowed the platform to go into production in six weeks and to grow tenant by tenant ever since.
Common mistakes & misconceptions
- Multi-tenancy is often seen as insecure because several customers share one instance, when in fact logical isolation and access controls enforce strict data separation if implemented correctly.
- It is frequently assumed that every tenant needs its own database, yet depending on requirements shared databases with a tenant identifier or hybrid models are common and valid approaches.
- Many confuse multi-tenancy with simply running many separate installations, although its core is to operate one shared application efficiently for many tenants.
Frequently asked questions
How is customer data separated in a multi-tenant architecture?
Separation is achieved through separate databases, separate schemas or a tenant identifier in shared tables. The crucial point is that every query and every access stays strictly limited to the respective tenant.
Is multi-tenancy secure enough for sensitive data?
Yes, provided data separation, access control and identity management are implemented cleanly. With clear tenant boundaries, MFA via Keycloak and GDPR-compliant operations, even sensitive sectors such as insurance can be served securely.
What is the difference between multi-tenant and single-tenant?
With single-tenant, each customer gets its own instance, while with multi-tenant all customers share a common application and infrastructure. Multi-tenancy lowers operating and maintenance effort but in return requires especially careful data separation.
How does multi-tenancy affect updates and maintenance?
Because all tenants use the same software, updates and security fixes only have to be applied once and are immediately available to all customers. This significantly reduces maintenance effort but calls for careful testing, since one change affects all tenants at the same time.
Related terms
Sources & further reading
Want to put this topic to work in your company?
Updated · Back to the glossary