{"id":7483,"date":"2022-08-02T10:00:06","date_gmt":"2022-08-02T08:00:06","guid":{"rendered":"https:\/\/anexia.com\/blog\/?p=7483"},"modified":"2022-11-24T15:18:49","modified_gmt":"2022-11-24T14:18:49","slug":"where-is-multi-tenancy-used","status":"publish","type":"post","link":"https:\/\/anexia.com\/blog\/en\/where-is-multi-tenancy-used\/","title":{"rendered":"Where is multi tenancy used?"},"content":{"rendered":"

What is Multi Tenancy?<\/h2>\n

In a multi tenant software solution, several different customers or their users use the same software instance. They are always separated from each other and do not perceive any other client on the shared system.<\/p>\n

This means that the clients can never access each other’s data. For this reason, the separation, isolation, and security of the data must be designed during the design of the data model to make a software solution multi-client capable.<\/p>\n

 <\/p>\n

Areas of application of Multi Tenancy<\/h2>\n

For a corporate group, multi tenant accounting software has the special advantage of storing the data of each subsidiary in separate databases. Multi tenancy has also been the standard for many years in the use of ERP and CMS systems.<\/p>\n

If each customer is provided with its own system instance, then this is referred to as a single tenancy architecture. These are usually deployed on virtual environments.<\/p>\n

With multi tenancy architectures, a virtualized environment is not practical because the software already contains the separation of the clients. This saves the resource overhead that virtualized environments inevitably bring.<\/p>\n

 <\/p>\n

\"multi<\/p>\n

<\/h2>\n

 <\/p>\n

Different multi tenant architectures<\/h2>\n

Another advantage of multi tenancy is the ability to define all data and objects as client-specific or cross-client. For example, general-purpose data such as postal codes, city and country names are accessible to all users across clients and only need to be maintained in one place. The database can be integrated into the application in three different ways. Either all clients use a common database with a common database schema, or separate schemas or even separate databases are used.<\/p>\n

A dedicated database per client provides the maximum flexibility and strongest isolation of data, but also requires the highest effort in maintaining, scaling, and managing the system.<\/p>\n

A shared database with separate schemas is useful when a few data fields need to be customized or added, but the application can access the predefined data fields for the most part. Ideally, all clients will use the same database and schema, resulting in the least maintenance and ongoing operational overhead. In addition to efficient use of hardware resources, this variant is also the easiest to scale.<\/p>\n

 <\/p>\n

Disadvantages of Multi Tenancy Architectures<\/h2>\n

With all the advantages, however, it must also be mentioned that the simultaneous use of the application by many users and clients means that no performance guarantee is possible.<\/p>\n

While there are a few ways to balance the workload somewhat, these are not comparable to the performance allocation in a virtual environment. Backup and recovery of data is also very complex in a multi-tenancy solution, as the data is not as isolated from each other as in a multi-instance architecture, and recovery requires additional effort. Additionally, erroneous or failed updates affect all tenants in the system simultaneously.<\/p>\n

 <\/p>\n

Multi tenant vs. single tenant<\/h2>\n

The more common option for current SaaS solutions is multi tenancy, as the efficient use of resources and low maintenance costs offer a decisive price advantage over single tenancy. Only if absolute flexibility and control are required, a single tenant infrastructure usually is the better choice.<\/p>\n

 <\/p>\n

Further information<\/h2>\n