One Forgotten WHERE Clause Away From a Breach: Choosing Multi-Tenancy in Spring Boot

Spring Boot Multi Tenancy

Your SaaS has 400 customers. A developer writes SELECT * FROM orders and forgets the WHERE tenant_id = ?. How many customers just saw each other's invoices?

In the setup I tested below, the answer was all of them: 3,000 rows from three tenants, returned to one.

Multi-tenancy is the decision about where that bug is made impossible. There are three common places: in the row, in the schema, or in the database. By the end of this post you will know what each costs, with numbers I measured on a real PostgreSQL 16 server, the Spring and Hibernate hooks that implement each, and a decision guide you can use.

What You Are Choosing

Forget the labels for a moment. All three options answer one question: when a developer makes a mistake, what stops tenant A from reading tenant B’s data?

• Row-level (shared tables). Every row carries a tenant_id. The thing stopping a leak is a filter, in Hibernate or in the database.
• Schema-per-tenant. One database, one schema per tenant, identical tables in each. The stop is which schema the connection points at.
• Database-per-tenant. One database per tenant. The stop is a separate connection pool and credentials.