How do I implement multitenancy in Spring Boot?

Resolve the tenant on each request, isolate data per tenant rather than filtering in queries, and manage tenant schema with versioned migrations. This repository implements that shape: organisation entities with mappers, datasource records per tenant, JPA repositories, and Flyway migrations checked into source control.

Is it schema-per-tenant or database-per-tenant?

The service models tenant datasources as first-class records, so where a tenant's data physically lives is a configuration decision rather than something hardcoded into the application logic.

Can I use it as a starting point for a commercial product?

It was written to be forked — which is what most people do with it. Clone it, point the configuration at your database, and replace the organisation model with yours.

Multitenancy in Spring Boot

Overview

Every B2B product eventually needs to keep one customer's data away from another's, and multitenancy done casually is how that becomes a data leak. This is the version I would want to start from: a Spring Boot service with tenant organisation entities, datasource records per tenant, JPA repositories and mappers, and Flyway migrations — the structural decisions made once, properly.

What it does

Tenant organisation entities with DTOs and mappers, kept separate from request handling
Datasource records per tenant, so isolation is a data concern rather than scattered conditionals
Flyway migrations checked into the repository for reproducible tenant schema setup
A base REST controller other services can extend rather than copy
The most-forked of my repositories — teams use it as a starting point, not a demo

Quickstart

Clone and build

git clone https://github.com/dibyapp/mt-base-service.git
cd mt-base-service
./mvnw clean install

Configure and run

Point src/main/resources/application.yml at your database, then start the service.

./mvnw spring-boot:run

How it is structured

The service separates the tenant model from the request layer. Organisation entities and their DTOs are mapped explicitly rather than exposed straight out of JPA, datasource records describe where each tenant's data lives, and repositories keep the lookup in one place.

A base REST controller gives downstream services a common starting point, so tenant handling is inherited rather than reimplemented per endpoint.

Why multitenancy is worth getting right early

Retrofitting isolation into a service that assumed one customer is among the more expensive migrations in enterprise software, because the assumption is rarely in one place. It is in queries, in caches, in background jobs, and in every endpoint written before anyone thought about it.

Deciding tenant resolution and data isolation up front costs a few days. Deciding it after the second customer signs costs a quarter.