Multi-Tenancy in Hibernate — Schema, Database & Discriminator Strategies

// Relying on EVERY developer remembering this filter, EVERY time:
@Query("SELECT o FROM Order o WHERE o.tenantId = :tenantId AND o.status = :status")
List<Order> findByStatus(@Param("tenantId") String tenantId, @Param("status") String status);
// Miss this filter ONE time, in ONE query, and tenant A can see tenant B's data.

Here's Hibernate's built-in fix — @TenantId (Hibernate ORM 6.4+), enforced structurally:

public class TenantResolver implements CurrentTenantIdentifierResolver<String> {
    @Override
    public String resolveCurrentTenantIdentifier() {
        return TenantContext.getCurrentTenant();   // from the authenticated request
    }

    @Override
    public boolean validateExistingCurrentSessions() {
        return true;
    }
}

hibernate.tenant_identifier_resolver=com.example.TenantResolver

@Entity
public class Order {
    @Id @GeneratedValue
    private Long id;

    @TenantId
    private String tenantId;   // Hibernate sets this on insert AND filters every query by it — you never touch it

    private String status;
}

Now EVERY query Hibernate generates for Order — derived methods, JPQL, all of it — automatically gets tenant_id = ? appended to its WHERE clause using whatever TenantResolver returns for the current request, and every new Order gets its tenantId field populated automatically on insert. There is zero risk of a developer forgetting it in some new query, because there's no per-query opt-in step at all — it applies unconditionally to every statement Hibernate generates for this entity.

For the discriminator strategy, a @TenantId-annotated field is treated by Hibernate's query translation layer as an implicit, unconditional restriction: it's appended to the WHERE clause of every generated SQL statement for that entity (SELECT, UPDATE, DELETE alike) and included in every generated INSERT — in both cases using whatever value your CurrentTenantIdentifierResolver (this chapter's TenantResolver example) returns for the current request, resolved once per session. This is different from Hibernate's older @Filter mechanism, which has to be explicitly enabled per session before it does anything — @TenantId has no such opt-in step, which is precisely what makes it safe to rely on structurally rather than trust every developer to remember.