Schema-based multi-tenant architecture using Quarkus & Hibernate-ORM

How should I decide which resource to keep separate and which to be shared?

The decision should be made on each resource after looking at its constraints for scaling up. It’s good if each of your resources scales individually based on the utilization rather than complete application scaling up and remaining underutilized.

Multi-tenant database patterns

There are three types of patterns:

What we will build?

We will build an app that will store the information of the users of the tenants.

schema-based multi-tenancy database pattern
table details

Implementation

One important factor while approaching this solution is whether or not frameworks or tools are available that support this architecture and pattern.

Application configuration
Selected extensions
mvn compile quarkus:dev
http://localhost:8080/hello
CREATE TABLE public.pricing_details
(
id integer,
product_name character varying NOT NULL,
price integer NOT NULL,
created_at date,
updated_at date,
PRIMARY KEY (id)
);
CREATE SCHEMA googl
AUTHORIZATION postgres;

CREATE SCHEMA aapl
AUTHORIZATION postgres;
CREATE TABLE googl.user_details
(
id integer,
first_name character varying NOT NULL,
last_name character varying NOT NULL,
created_at date,
updated_at date,
PRIMARY KEY (id)
);
CREATE TABLE aapl.user_details
(
id integer,
first_name character varying NOT NULL,
last_name character varying NOT NULL,
created_at date,
updated_at date,
PRIMARY KEY (id)
);
Inside the package containing the entities of the ‘public’ schema
Inside the package containing the entities of tenant-specific schema
public String resolveTenantId() {
String tenantName = context.request().getHeader("tenant");
return tenantName;
}
public schema
googl schema
aapl schema
list of pricing details from public schema
list of users from googl schema
list of users from aapl schema

Important

For the simplicity of the implementation, we passed the tenant identifier in the header. It should not be passed in the header. A better approach will be to include it in the JWT tokens which can’t be modified and retrieve that by intercepting the HTTP request and storing the identifier in a TenantContext.

Source code

You can find the source code here.

Pros

  1. Efficient use of resources.
  2. A better architecture for multi-tenancy compared to the row per tenant approach in terms of data isolation.
  3. Low infrastructure costs.
  4. Can easily scale.

Cons

  1. Development complexity is high.
  2. High customization per tenant will be difficult.
  3. Data backup for each tenant is not possible.
  4. Monitoring for each tenant may not be supported.
  5. Frameworks supporting this pattern may not be available in all languages.

--

--

CoffeeBeans empowers organizations to transform their business through the use of advanced technologies. Building data-driven solutions that drive innovation.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
CoffeeBeans_BrewingInnovations

CoffeeBeans_BrewingInnovations

CoffeeBeans empowers organizations to transform their business through the use of advanced technologies. Building data-driven solutions that drive innovation.