The main advantage of a multitenant 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 need to be performed only once to be available to all customers.
In this article we will focus on database models and programming. We do not cover domain models.
What is multitenancy?
In software engineering, multitenancy is a principle in software architecture where a single instance of the software runs on a server and serves multiple clients (tenants). A tenant is a group of users that 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 of application data, configuration, user management, and tenant-specific customization. The term is also used in network architecture, where a single server hosts multiple independent tenants or organizations. What is the benefit or advantage of multi-tenant software?
Multitenant software has many benefits that make it an attractive option for businesses. One of the most important benefits is that companies can save money by sharing resources. In addition, multi-tenancy can help businesses better manage their resources.
The real benefit of designing a system to be multi-tenant is so that it can be used by customers who, in turn, bring their own customers into their "realm".
To illustrate, this graphic shows a multitenancy architecture with a shared database to allow tax firms to manage their clients through the software.
Which multi-tenant architecture is right for you?
Which type of multitenant architecture is appropriate for your organization depends on a number of factors, including the sensitivity of the data, legal requirements for the project, the number of clients, and the organizational structure.
There are two main types of multitenant architectures: shared database or separate databases. 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 a shared database architecture, all clients share the same database instance. This means that data from multiple or all tenants is stored in the same database. The separation of the data to the tenants is usually enabled by a groupid or organizationid and thus takes place on code level. This form of implementation does not provide physical separation of data. A shared database can be used whenever there are no legal requirements for more extensive data separation.
In multitenant implementations that use a shared database, the lower security is often cited as a disadvantage because data from multiple customers is in the same database. We think this is a bogus argument. Common and widely used store 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 the clients works properly. Splitting the data to different databases should in our opinion not be a shortcut to save on software quality or clean implementation. The test coverage of the code here is of particular importance.
Advantages of multitenancy with one database
A multitenant Laravel system with a central database basically enjoys all the advantages that Laravel offers and thus ensures a high developer experience and efficient development.
There is no need for extensive intervention in the core Laravel system and it also facilitates the maintainability of a project for future version updates.
Without the need to create a separate database for each client, new clients can be onboarded quickly through a simple registration process - virtually with Laravel's board tools.
Multitenancy with separate databases
In a disconnected database architecture, each tenant has its own database instance. This means that each tenant's data is isolated from the other tenants. A segregated database architecture is typically used when there are legal requirements for data segregation. Caution: Dead end!
This type of implementation is significantly more complex and therefore more cost-intensive. Moreover, once this path is taken, it is difficult or impossible to reverse. Therefore, an exact consideration is absolutely necessary already at the beginning of the project. Without absolutely necessary requirements, an implementation with multiple databases is not recommended.
Using multiple databases with Laravel
Developing multi-tenant software can be achieved in many different ways, the more elaborate method is to use 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 achieve physical isolation of the data. This implementation option is ideal for companies that require comprehensive data separation.
If a database is to be used for each 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 with a multi-database setup
When using multiple databases, it becomes necessary to always know which tenant is currently being worked with. I.e. all requests, artisan commands, queues etc. must know their tenant (be tenant-aware). Onboarding new clients
Here, too, the effort is greater than usual. For each new client, a new database must be created during onboarding (cf. during registration). Of course, this process can be automated, but it is an additional and complex infrastructure part that involves efforts 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 multitenant software
The advantages of multi-tenant software development are that it takes full advantage of economies of scale, provides near-instant elasticity, and improves software quality by increasing test coverage. A single instance of the software can serve multiple clients, which lowers costs compared to traditional development models. Implementation with Laravel board resources
Because an implementation with multiple databases is very rarely needed, we limit ourselves here to the implementation of multitenancy with a single-line database.
Basically Laravel already brings everything needed to develop a multitenant system. For a single database solution no additional packages are needed. What is needed is a model and a table organization. In our projects we prefer the name "Organization" for a client, but tenant or group would be just as possible.
The respective resources that the app manages are now bound to this organization. For this purpose, only one column "organisation_id" is needed in the respective tables. Via PhpUnit tests we make sure that no client can see the data of the other client. Test Driven Development (TDD) is an essential approach in such projects. At this point, it is important to communicate to the customer at an early stage why these efforts are necessary and worthwhile.
Multitenancy with a single database is a good solution because it provides economies of scale, near-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-tenant solution with one database is perfectly adequate and recommended.
- Picture by Joshua Coleman