Multi-tenancy: a way to build SaaS products

Photo by Rich Tervet on Unsplash

A way to easily scale the next SaaS product? Yes, it can be done with ease.
A multi-tenant software is a software where a single instance of the application serves different users or groups of users (I’ll reference them as clients). Each client has their data logically or physically separated from each other to avoid data leak from one client from the other.

The biggest SaaS software today are built using a multi-tenant approach.
Think about Jira or Slack, each workspace is independent of the others and there is no way to see the data of other workspaces in yours.

Main characteristics of a multi-tenant software

We can consider 3 main characteristics:

• Reduced costs
• Single deploy point
• Easy maintenance

Reduced costs
If you are starting from the ground you can easily keep the costs low because it’s always the same instance of the application that responds to all clients requests. So you don’t need to deploy the same code for each client that signs up and this means no deploy costs and no resources wasted (in a dockerized environment think about deploying just one container instead of a container for each client).

Single deploy point
All your code lives inside the same space. You don’t need to duplicate it when a new client registers. This results in an easier CI/CD process: you need to care about a single instance of the code.

Easy maintenance
Like the previous point, because your code is in a single place you need to touch only once to resolve a bug or make new features.

How to approach it?

There are two ways to build multi-tenant software:

• Single database:
  All your client data are inside the same instance of the database, separate by a column that identifies the client/tenant (eg. tenant_id );
• Multiple databases:
  Each client have their instance of the database that could be a different schema or an entirely new server: it’s up to you;

Single Database Approach

The easiest way. All backend developers have done something similar in the career and a lot of documentation can be found online.
All client data are inside the same database and belonged to a client by his ID.

This approach is the simplest: add to all the tables that have your client data an ID that identifies the client. The throwback of this approach is that you have to specify in all the queries of the application to filter by the client ID.

One pro of this method is that you can show data from multiple clients with just a query.

The cons of this approach are:

• Add a “where” statement in all the queries or scope in the model;
• If you use a third-party package inside an existing project, you’ll need to modify the DB and the models;
• You can’t easily horizontally scale on multiple servers without introducing a “shard” from the beginning;
• Could be difficult to export or delete all the data of a specific client.

Photo by Jan Antonin Kolar on Unsplash

Multiple Database Approach

Using this method you’ll create a new DB instance or schema for each client that signs up.

It could be hard to start with this approach, but the higher start-up cost will be rewarded in the long run.

In this way you install a package, configure it and it’s finished: no changes in your queries or your models.

There are plenty of third-party packages that can help you set up all the things. To find one usually a search on Google with “multi-tenancy {your framework}” in enough.

The main pros of this approach are about data security:

• All client data is in a separate instance of the DB, so less probability to show someone else data;
• It’s easier to export all client data, just dump and you’re done;

Even scalability is improved:

• Client data has become too heavy compared to other clients? Put it on another server!
• Having different client DB on multiple servers improves fault tolerance: server goes down? Only that specific client is affected.

Data portability:

• As told, exports are easier, just query client DB;
• Backups could be done per client (tenant) and restore could be done per tenant;
• Enterprise clients can have their on-premise version;
• Client data could be deleted easily: just drop the DB instance;
• You could choose where to host the DB to be “nearer” your client customers or to meet laws needing (see GDPR);

Photo by Scott Graham on Unsplash

Side notes

As a Laravel developer, I just created a SaaS product for a customer.
I’m creating a guide on how to set up a multi-tenant environment with Laravel and which packages are available.
I’ll post the link here when will be ready.
If you are interested, sign the form at the bottom and I’ll alert you.
Thank you!