The most common use case for multi-tenant systems is SaaS-based applications, which use different levels of data isolation depending on the domain of the application.
Let’s say, you have a product that you want to provide to several organisations, so that their users can login to the platform and use the service.
The simplest solution would be to copy your codebase for each organisation and deploy them separately. It seems intuitive but hard to maintain as there is an overhead of managing multiple servers.
Whenever your dev team needs to add a new feature, there needs to be a series of deployments to be followed. With a multi-tenant architecture, this problem could easily be addressed resulting in a consistent codebase as now the team has to maintain only a single codebase. In line with our example, the tenants could be the organisations using our product.
There are several architectures that could be followed to achieve multi-tenancy at the database layer including:
- Separate database per tenant
- Separate schema per tenant
- Shared schema for tenantsThere are tons of articles available over the internet to help to understand the concept of multi-tenancy. Here we are going to talk about one specific type of multi-tenancy i.e. Schema-based Multi-Tenancy and how exactly PostgreSQL implements it.
In this type of multi-tenancy, we create multiple schemas in the same database to provide data isolation to the tenants. At runtime, depending on the criteria to resolve the tenant, requests are redirected to the specific schema. There could be a number of ways to do it for example unique subdomains etc.
