Laravel: What kind of multitenant architecture should you choose?
Multi-tenancy is an architecture in which a single instance of a software application serves several customers.
In a so-called "multi-tenant environment", all customers use the same source code and the same database, but each customer only has access to their own data.
SaaS products in particular are often based on a multi-client architecture.
The main advantage of a multi-tenant architecture is that it enables economies of scale: the same code base and infrastructure can be used for multiple customers, reducing development and maintenance costs. Updates and upgrades only have to be carried out once to be available for all customers.
What is multi-client capability?
In software engineering, multitenancy is a principle in software architecture in which a single instance of the software runs on a server and serves several clients (tenants). A tenant is a group of users who have the same access with certain privileges to the software instance.
In multi-tenancy, a software application is designed so that each tenant has its own area with application data, configuration, user administration and client-specific customisations. The term is also used in network architecture, where a single server hosts several independent tenants or organisations.
What is multi-client capable software used for?
Multi-tenant software allows a single software instance to be used by multiple customers, with the data and settings of each customer group remaining separate.
This means that different customers can use the same software without their information being mixed together.
Which multi-tenant architecture is suitable?
The type of multi-tenant architecture that is suitable for your company depends on a number of factors, including the sensitivity of the data, the legal requirements of the project, the number of clients and the organisational structure.
There are two main types of multi-tenant architectures: shared database or separate databases per customer. Another implementation option is to use the same schema with prefixed tables within a database instance. Wordpress uses this approach when using a multisite installation.
Multitenancy with a shared database
In an architecture with a shared database, all tenants share the same database instance. This means that the data from several or all tenants (clients) is stored in the same database.
The separation of the data into tenants is usually made possible by a group_id or organisation_id and therefore takes place at code level.
This form of implementation offers no physical separation of data. A shared database can always be used if there are no legal requirements for more extensive data separation.
For multi-tenant implementations that work with a shared database, the lower security is often cited as a disadvantage because data from several customers is stored in the same database.
We think this is a bogus argument. Common and widely used shop systems, for example, work according to the same principle: customer data is stored in a central database. Furthermore, it is a question of clean and robust implementation to ensure that the separation of clients works properly. In our opinion, splitting the data into different databases should not be a shortcut to save on software quality or clean implementation. The test coverage of the code is of particular importance here.
Advantages of multitenancy with a database
A multi-client capable Laravel system with a central database basically enjoys all the advantages Laravel offers and thus ensures a high developer experience and efficient development.
Far-reaching interventions in the Laravel core system are avoided and also facilitate the maintainability of a project in future version updates.
Without the need to create a separate database for each client, new clients can be quickly onboarded through a simple registration process - using Laravel board tools, so to speak.
Multitenancy with separate databases
In an architecture with separate databases, each tenant has its own database instance. This means that the data of each tenant is isolated from the other tenants. A separate database architecture is generally used if there are legal requirements for data separation.
Attention: dead end!
This type of implementation is significantly more complex and therefore more cost-intensive. Once this path has been taken, it is also difficult or impossible to reverse. It is therefore essential to take a close look at the project right from the start. Without absolutely necessary requirements, implementation with several databases is not recommended.
Using multiple databases with Laravel
The development of multi-client capable software can be achieved in many different ways, the more elaborate method being the use of multiple databases. This approach can be used with the Laravel framework and allows you to create a separate database for each client. This allows you to physically isolate the data. This implementation variant is ideal for companies that require comprehensive data separation.
If one database is to be used per client, we recommend using Spatie's "Multitenancy" package. It facilitates the handling of separate databases per client and also provides helpful Artisan commands for administration.
Additional challenges due to a multi-database setup
If several databases are used, it is always necessary to know which tenant is currently being worked with. This means that all requests, artisan commands, queues etc. must know their client (be tenant-aware).
Onboarding new customers
The effort involved here is also greater than usual. A new database must be created for each new client during onboarding (see registration). Of course, this process can be automated, but it is an additional and complex infrastructure component that is associated with costs that can be saved.
If this step is not automated, new clients can only be added manually or partially manually, e.g. with an Artisan command.
Real advantages of multi-client capable software
The advantages of multi-tenant software development are that it fully utilises economies of scale, offers almost immediate elasticity and improves software quality through higher test coverage. A single instance of the software can serve multiple clients, which reduces costs compared to conventional development models.
Implementation with Laravel board tools
As an implementation with several databases is only very rarely required, we will restrict ourselves here to the implementation of multitenancy with a single database.
In principle, Laravel already comes with everything you need to develop a multi-client capable system. No additional packages are required for a single-database solution. What is needed is a model and an Organisations table. In our projects, we prefer the term "organisation" for a client, but tenant or group would also be possible.
The respective resources that the app manages are now linked to this organisation. This only requires one "organisation_id" column in the respective tables. We use PhpUnit tests to seamlessly ensure that no client can see the data of another client. Test Driven Development (TDD) is an indispensable approach in such projects. At this point, it must be communicated to the customer at an early stage why this effort is necessary and worthwhile.
Laracon Talk on the topic of multi-tenancy
As part of Laracon 2017, Tom Schlick gave a presentation on the topic of multi-tenancy.
Our recommendation
Multitenancy with a single database is a good solution because it enables economies of scale, almost instant elasticity and improved software quality. It also provides separation between the application owner/operator and the individual tenants, which increases security and manageability.
Unless there are legal requirements that necessitate actual, physical data separation, a multi-client solution with a database is completely sufficient and recommended.
Further material:
- Presentation by Tom Schlick on Multitenancy in Laravel, Laracon 2017
- Wikipedia on client-enabled software
- Foto von Joshua Coleman