Multi-tenancy – Dealing With Multiple Contexts on a Single Platform

Have you ever stumbled across two e-commerces that looked very similar? An instance of a software that can serve multiple customers? Thats allows them to be customized and personalized but the structure of the page looked awfully familiar? Well, the chances are you stumbled across two Multi-tenancy based e-commerces!

"What is a Multi-Tenant?" I hear you asking. Well, that's what we're going to cover in this article today!

Ok, but first, what is a tenant? The tenant, as the name suggests, is a customer who will "rent" our software. Thinking of more tangible issues, we can think of an example of a multi-tenancy system, as a condominium of houses where we have a set of buildings intended for residential living, built in the form of autonomous units and belonging to several owners. In other words, a single project can be purchased by several families, this is where we can apply the multi-tenancy architecture.


As such, an example of a single-tenancy system could be a house where a family will live, it is a single project isolated in its own needs and consuming its own resources. Any other family can't use this house (in our case, project).

You can build a house with the same concepts and ideas nevertheless they will differ civil projects.


Multitenancy? What do you mean?

It's high likely that you have heard the term SAAS (or Software As A Service) somewhere. It basically means that instead of developing/buying the desired software yourself, you would rent the service so that it's developed/maintained for you by other people. That's how the concept of multi-tenancy came about.

Going a little deeper on the subject, multi-tenancy architecture is an architecture used on platforms that offer software as a service, such as, a website builder. In this type of architecture, you have an application that serves several customers. It's as if that infrastructure is leased to you.

A multi-tenancy architecture supports multiple users or groups of users where each one has its own separate data, its own settings and works independently without affecting each other. The biggest concern you should keep in mind when building your multi-tenancy application is that one tenant cannot affect the other, just as the data from one cannot be exposed to the other.

There's some confusion between applications distributed with the definition of multi-tenancy, but the concept is due to the application being developed to keep users or groups of users separated from each other. It is opposed to the application running in a totally isolated way for several users. If you do completely separate installations, even running on the same machine, that's not multi-tenancy.

In short, multi-tenancy is an architecture in which your system accepts multiple users where each user access the system in isolation.

Single vs Multi DB

Single DB

A single DB means that all data from all customers is on the same database. That means the system uses a single database where we must never leak data from one tenant to another. To be sure of this, we use a foreign key to represent each tenant, so when a user accesses their application, it must verify the tenant linked to that user and return only the data in the database that has the associated tenant's foreign key.

One advantage using this method is the ease of metrics and reports generation, but be careful: the performance can be seriously compromised if a tenant has a large volume of data or if there are too many tenants. Another point to be concerned about is whether a tenant performing a heavy operation on the database will likely cause other tenants to perceive a drop in performance on their end. Consider using multi DB if the tenants have very large volumes of data.

In the graphic below, you can see how the application and the database would be connected:

Multi DB

Differently from the Single DB approach, for a Multi DB Multi-Tenancy system, each customer will have their own database instance in the application. Although the implementation is a bit more complex, the main advantage is the logical isolation of the data from different tenants reduces the possibility of one tenant impacting the usage for other tenants, in addition, it makes export data for a specific tenant easier.

Advantages and Costs

  • Cost reduction, as resources are shared among customers. We can see the advantage of a lower cost with multi-tenancy since, in a single-tenancy, we would have to duplicate the entire system for each customer, while in multi-tenancy we will use a single system to isolate customers;

  • An economy with infrastructure. Lower cost than having several different instances serving multiple customers;

  • Reduction in the complexity of software management;

  • Facilitates the deployment and delivery of new versions;

  • Facilitates obtaining metrics since we are talking about a single instance.


Some cases of web applications that are multi-tenancy:

  • Wix

  • GoDaddy

  • StackCommerce

  • SquareSpace

  • WordPress

Have you worked on projects with multi-tenancy? Leave in the comments your experience and approaches used 🙂

We want to work with you! Check out our "What We Do" page.