Building a Secure Multi-Tenant SaaS Backend with Spring Boot 4, Hibernate 7, and PostgreSQL RLS

Building a multi-tenant Software-as-a-Service (SaaS) backend is a major architectural challenge. Modern enterprise platforms must serve thousands of distinct business customers on shared cloud infrastructure. Each customer is called a tenant. Tenants expect their business data to remain completely private, secure, and isolated from other tenants. At the same time, engineering teams must keep cloud hosting costs low and database maintenance simple.

A classic dilemma in multi-tenant engineering is choosing between data isolation and resource efficiency. Isolating each tenant into a dedicated database provides high isolation. However, managing thousands of database instances increases cloud costs and makes schema migrations difficult. Conversely, storing all tenants in a single shared schema lowers hosting bills. But a single missing SQL filter can leak confidential customer records across tenants.

In this comprehensive architectural guide, we will implement a defense-in-depth multi-tenant architecture using Spring Boot 4, Hibernate 7, and PostgreSQL 16 Row-Level Security (RLS). By combining application-level query filtering with database kernel policies, we achieve absolute tenant data isolation without sacrificing cost efficiency.

Table of Contents

• The Multi-Tenancy Challenge: Isolation vs Resource Efficiency
• Comparative Analysis: Multi-Tenant Architecture Strategies
• The Defense-in-Depth Architecture: Dual-Layer Security
• End-to-End System Architecture Overview
• Layer 1: Hibernate 7 @TenantId Application-Level Isolation
• Layer 2: PostgreSQL Row-Level Security (RLS) Database Enforcement
• Bridging Application and Database: Spring AOP and Session Variables
• Connection Pooling & Virtual Threads: Safe Session Scoping with HikariCP
• Integration Testing with PostgreSQL Testcontainers
• Enterprise Use Cases: FinTech, Healthcare, and B2B SaaS
• Production Readiness and Operational Guardrails
• Common Pitfalls and How to Fix Them
• Frequently Asked Questions (FAQ)
• Conclusion and Next Steps
• References and Companion Code

The Multi-Tenancy Challenge: Isolation vs Resource Efficiency

When software teams build multi-tenant SaaS products, they face trade-offs across three primary architectural dimensions: data isolation, operational complexity, and resource utilization. In traditional single-tenant architectures, each client runs on dedicated servers with a dedicated database. While this model offers clean data boundaries, it scales poorly as your customer base expands from tens to thousands of organizations.

Consider a SaaS product serving 5,000 corporate clients. Deploying 5,000 separate database instances creates severe operational friction. Database connection pools overwhelm server memory, database schema migrations require complex automation across thousands of endpoints, and compute resources sit idle during off-peak hours. Conversely, sharing database tables introduces the terrifying risk of cross-tenant data leakage. If an application developer writes a native SQL query and forgets to append WHERE tenant_id = :tenantId, confidential business data is exposed.

To eliminate this compromise, modern cloud architectures adopt the Shared Database, Shared Schema pattern enhanced with Defense-in-Depth. By pairing application-level automation in Hibernate 7 with native PostgreSQL Row-Level Security, software engineers achieve the operational simplicity and cost savings of shared tables while enforcing mathematical isolation inside the database engine.

Comparative Analysis: Multi-Tenant Architecture Strategies

To choose the correct multi-tenancy model for your engineering organization, review the comparative matrix below. It details six mainstream architectural approaches across isolation strength, operational overhead, infrastructure expenditure, connection utilization, and production scale fit.

The Defense-in-Depth Architecture: Dual-Layer Security

The core philosophy of Defense-in-Depth states that no single security control should bear full responsibility for system safety. If one security mechanism fails or suffers from human error, a secondary, independent security boundary immediately prevents unauthorized access. In our multi-tenant SaaS architecture, we enforce two completely independent isolation layers:

1. Application Layer (Hibernate 7): When developers execute standard JPA queries, Spring Data repository calls, or Criteria API lookups, Hibernate 7 automatically intercepts the Abstract Syntax Tree (AST) of the query. It injects the active tenant identifier into the generated SQL statement before sending it across the network. Developers cannot accidentally forget the tenant filter because the ORM injects it automatically.
2. Database Kernel Layer (PostgreSQL 16 RLS): Even with ORM automation, developers occasionally execute native SQL queries, administrative batch scripts, or raw JDBC reporting statements. If someone executes SELECT * FROM tasks without a WHERE clause, the PostgreSQL storage engine evaluates the table’s Row-Level Security policy. The database engine drops all rows whose tenant_id does not match the active session variable. The query returns only the caller’s data.

By coupling Hibernate 7 with PostgreSQL RLS, your application achieves military-grade data segregation. The database protects itself against flawed application code, while the application prevents unnecessary load on the database engine.

End-to-End System Architecture Overview

Let us examine the complete lifecycle of a tenant request flowing through our Spring Boot 4 service down to the PostgreSQL database engine. Figure 2 illustrates the five operational tiers.

The request progression follows five distinct phases:

1. Edge & Ingress: The client sends an HTTP request containing an Authorization: Bearer <JWT> token and an optional X-Tenant-ID: acme header.
2. Web Filter & Context Binding: A servlet filter (TenantFilter) extracts the tenant identifier from the validated JWT token claims. It stores the identifier in a thread-safe context (TenantContext) powered by Java 25 Scoped Values or ThreadLocal.
3. Hibernate 7 ORM Resolution: When a repository method executes, Hibernate’s CurrentTenantIdentifierResolver reads the tenant ID from TenantContext. Hibernate appends WHERE tenant_id = 'acme' to all generated SQL statements.
4. Spring AOP Session Bridge: Before the transaction executes, a Spring AOP aspect executes SET LOCAL app.current_tenant = 'acme' on the checked-out JDBC connection. The session variable is strictly scoped to the active transaction.
5. PostgreSQL Kernel Enforcement: PostgreSQL evaluates the RLS policy. If any row does not match current_setting('app.current_tenant'), the row is discarded at the storage layer.

Layer 1: Hibernate 7 @TenantId Application-Level Isolation

Hibernate 7 introduces native, first-class support for single-table multi-tenancy through the standard @TenantId annotation. In previous versions of Hibernate, developers had to configure custom bytecode interceptors or complex filter definitions. As explored in our deep dive on Hibernate 7 and Spring Data JPA 4, modern persistence APIs drastically eliminate boilerplate.

To enable application-level multi-tenancy, annotate your entity’s tenant field with @TenantId:

package com.webcodein.saas.model;

import jakarta.persistence.*;
import org.hibernate.annotations.TenantId;
import java.util.UUID;

@Entity
@Table(name = "tasks")
public class Task {

    @Id
    private UUID id = UUID.randomUUID();

    @Column(nullable = false)
    private String title;

    @TenantId
    @Column(name = "tenant_id", nullable = false, updatable = false)
    private String tenantId;

    @Column(nullable = false)
    private String status = "PENDING";

    public Task() {}

    public Task(String title) {
        this.title = title;
    }

    public UUID getId() { return id; }
    public String getTitle() { return title; }
    public void setTitle(String title) { this.title = title; }
    public String getTenantId() { return tenantId; }
    public String getStatus() { return status; }
    public void setStatus(String status) { this.status = status; }
}

When an entity has a @TenantId field, Hibernate 7 performs two vital tasks automatically:

• Automatic Insert Injection: When persisting a new entity (taskRepository.save(new Task("Deploy v2"))), Hibernate automatically populates the tenantId property with the current tenant identifier resolved by the application context.
• Automatic Query Rewriting: For every SELECT, UPDATE, and DELETE statement, Hibernate inspects the AST and appends a predicate: AND tenant_id = ?.

To tell Hibernate which tenant is active for the current request, implement the CurrentTenantIdentifierResolver SPI:

package com.webcodein.saas.config;

import org.hibernate.context.spi.CurrentTenantIdentifierResolver;
import org.springframework.stereotype.Component;

@Component
public class TenantIdentifierResolver implements CurrentTenantIdentifierResolver<String> {

    @Override
    public String resolveCurrentTenantIdentifier() {
        String tenant = TenantContext.getCurrentTenant();
        return (tenant != null && !tenant.isBlank()) ? tenant : "UNKNOWN";
    }

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

The TenantContext class encapsulates the active tenant identifier. It provides safe thread-local storage across the service layer:

package com.webcodein.saas.config;

public final class TenantContext {

    private static final ThreadLocal<String> CURRENT_TENANT = new ThreadLocal<>();

    private TenantContext() {}

    public static void setCurrentTenant(String tenantId) {
        CURRENT_TENANT.set(tenantId);
    }

    public static String getCurrentTenant() {
        return CURRENT_TENANT.get();
    }

    public static void clear() {
        CURRENT_TENANT.remove();
    }
}

Layer 2: PostgreSQL Row-Level Security (RLS) Database Enforcement

While Hibernate 7 handles application queries beautifully, we need a safety net. What happens if a developer creates a reporting microservice using Spring JDBC Client or jOOQ? Or what if a database administrator executes a manual maintenance query? Without database-level isolation, human error can result in disastrous data leaks.

PostgreSQL Row-Level Security (RLS) provides kernel-level row filtering. For an in-depth breakdown of PostgreSQL security internals, see our guide on PostgreSQL Row-Level Security with Spring Boot 4. Using Flyway database migrations, we enable RLS and create an isolation policy on the tasks table.

-- src/main/resources/db/migration/V1__init.sql
CREATE TABLE tasks (
    id UUID PRIMARY KEY,
    title VARCHAR(255) NOT NULL,
    tenant_id VARCHAR(50) NOT NULL,
    status VARCHAR(50) NOT NULL DEFAULT 'PENDING'
);

-- Step 1: Create an index on tenant_id for high query throughput
CREATE INDEX idx_tasks_tenant_id ON tasks(tenant_id);

-- Step 2: Enable Row-Level Security on the table
ALTER TABLE tasks ENABLE ROW LEVEL SECURITY;

-- Step 3: Define the tenant isolation policy
CREATE POLICY tenant_isolation_policy ON tasks
    FOR ALL
    USING (tenant_id = current_setting('app.current_tenant', true))
    WITH CHECK (tenant_id = current_setting('app.current_tenant', true));

-- Step 4: Force RLS even for table owners (Defense-in-Depth)
ALTER TABLE tasks FORCE ROW LEVEL SECURITY;

Let us analyze the critical elements of this SQL migration script:

• current_setting('app.current_tenant', true): Reads the custom PostgreSQL configuration setting named app.current_tenant. The second parameter true is crucial: it instructs PostgreSQL to return NULL instead of raising a fatal SQL error if the variable has not been initialized.
• USING (...): Enforces read access. When a query executes, PostgreSQL evaluates this expression for each existing row. If the expression evaluates to false or NULL, the row is excluded from the query result set.
• WITH CHECK (...): Enforces write access. When a client executes an INSERT or UPDATE, PostgreSQL validates the new row against this policy. If the row’s tenant_id does not match the active session variable, the database rejects the write with a security exception.
• FORCE ROW LEVEL SECURITY: By default, PostgreSQL bypasses RLS for the user who owns the table. In Spring Boot microservices, applications often connect using the database owner user. Adding FORCE ROW LEVEL SECURITY ensures that PostgreSQL applies the policy to everyone, including table owners.

Bridging Application and Database: Spring AOP and Session Variables

To link the application’s TenantContext to PostgreSQL’s current_setting('app.current_tenant'), we must execute a SQL command at the start of each database transaction: SET LOCAL app.current_tenant = 'tenant-id'. The SET LOCAL command configures the session variable only for the duration of the current transaction block. When the transaction commits or aborts, PostgreSQL automatically resets the setting.

The cleanest, non-intrusive way to inject this session variable in Spring Boot 4 is using Spring AOP (Aspect-Oriented Programming). We create an aspect that intercepts any method annotated with @Transactional.

package com.webcodein.saas.config;

import jakarta.persistence.EntityManager;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;
import org.hibernate.Session;
import org.springframework.stereotype.Component;

@Aspect
@Component
public class RlsAspect {

    private final EntityManager entityManager;

    public RlsAspect(EntityManager entityManager) {
        this.entityManager = entityManager;
    }

    @Before("@annotation(org.springframework.transaction.annotation.Transactional) || " +
            "@within(org.springframework.transaction.annotation.Transactional)")
    public void applyRowLevelSecurity() {
        String tenantId = TenantContext.getCurrentTenant();

        if (tenantId != null && !tenantId.isBlank() && !"UNKNOWN".equalsIgnoreCase(tenantId)) {
            // Unwrap the Hibernate Session to access the raw JDBC connection safely
            entityManager.unwrap(Session.class).doWork(connection -> {
                try (var stmt = connection.createStatement()) {
                    // Use SET LOCAL to guarantee transaction-scoped cleanup
                    stmt.execute("SET LOCAL app.current_tenant = '" + tenantId.replace("'", "''") + "'");
                }
            });
        }
    }
}

Using entityManager.unwrap(Session.class).doWork(...) provides two enormous architectural advantages:

1. Exact Connection Binding: It executes the SET LOCAL command on the exact JDBC connection checked out for the active transaction, guaranteeing that subsequent JPA statements run in the same session context.
2. Zero Pool Contamination: Because SET LOCAL is scoped strictly to the PostgreSQL transaction block, the connection returns to the connection pool in a pristine, unassigned state.

Connection Pooling & Virtual Threads: Safe Session Scoping with HikariCP

When operating high-throughput multi-tenant systems in Spring Boot 4 on Java 25, understanding the database connection lifecycle is critical. Modern applications use virtual threads to handle tens of thousands of concurrent HTTP requests. If database session state leaks between connection reuses, Tenant B could accidentally read Tenant A’s private data.

Figure 5 visualizes the four lifecycle phases of a HikariCP connection under PostgreSQL RLS scoping.

Let us review each lifecycle stage:

• Phase 1: Connection Checkout: A worker thread or Java 25 Virtual Thread checks out an idle physical connection (e.g., Conn #14) from HikariCP. At this stage, app.current_tenant is unset.
• Phase 2: Transaction Scoping: The Spring AOP aspect executes SET LOCAL app.current_tenant = 'tenant-123' inside a BEGIN ... COMMIT block. The setting lives exclusively in transaction memory.
• Phase 3: Kernel Filtering: Queries run against PostgreSQL. The RLS engine enforces the policy: USING (tenant_id = current_setting('app.current_tenant')). Any rows belonging to other tenants are invisible.
• Phase 4: Automatic Teardown: When the transaction completes with COMMIT or ROLLBACK, PostgreSQL drops the LOCAL variable automatically. The connection returns to HikariCP in a clean state, ready for another tenant.

To learn more about mastering high-concurrency Java 25 applications, explore our architectural guide on Java 25 Virtual Threads: Production Pitfalls and Best Practices.

Integration Testing with PostgreSQL Testcontainers

A multi-tenant architecture cannot be considered production-ready without automated integration tests verifying data isolation. Unit tests and in-memory databases like H2 cannot test PostgreSQL Row-Level Security policies because H2 does not support PostgreSQL’s RLS engine or current_setting() function.

As documented in our guide on TDD with Spring Boot 4 and Testcontainers: Zero-Mocking Approach and our deep dive on Modern Local Development with Testcontainers & Docker Compose, we test our SaaS backend against real PostgreSQL 16 containers using Spring Boot 4’s @ServiceConnection.

package com.webcodein.saas;

import com.webcodein.saas.model.Task;
import com.webcodein.saas.repository.TaskRepository;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.testcontainers.service.connection.ServiceConnection;
import org.springframework.boot.test.web.server.LocalServerPort;
import org.springframework.http.ResponseEntity;
import org.springframework.web.client.RestClient;
import org.testcontainers.containers.PostgreSQLContainer;
import org.testcontainers.junit.jupiter.Container;
import org.testcontainers.junit.jupiter.Testcontainers;
import org.springframework.core.ParameterizedTypeReference;

import java.util.List;

import static org.assertj.core.api.Assertions.assertThat;

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@Testcontainers
class SaasApplicationTests {

    @Container
    @ServiceConnection
    static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:16-alpine");

    @LocalServerPort
    private int port;

    private RestClient restClient;

    @Autowired
    private TaskRepository taskRepository;

    @BeforeEach
    void setup() {
        taskRepository.deleteAll();
        restClient = RestClient.builder().baseUrl("http://localhost:" + port).build();
    }

    @Test
    void shouldIsolateTenants() {
        // 1. Create task for Tenant Alpha
        ResponseEntity<Task> responseA = restClient.post()
                .uri("/api/tasks")
                .header("X-Tenant-ID", "tenant-a")
                .body(new Task("Task for Alpha"))
                .retrieve()
                .toEntity(Task.class);
        assertThat(responseA.getStatusCode().is2xxSuccessful()).isTrue();

        // 2. Create task for Tenant Beta
        ResponseEntity<Task> responseB = restClient.post()
                .uri("/api/tasks")
                .header("X-Tenant-ID", "tenant-b")
                .body(new Task("Task for Beta"))
                .retrieve()
                .toEntity(Task.class);
        assertThat(responseB.getStatusCode().is2xxSuccessful()).isTrue();

        // 3. Fetch tasks for Tenant Alpha -> MUST only return Alpha's task
        List<Task> fetchA = restClient.get()
                .uri("/api/tasks")
                .header("X-Tenant-ID", "tenant-a")
                .retrieve()
                .body(new ParameterizedTypeReference<List<Task>>() {});
        assertThat(fetchA).hasSize(1);
        assertThat(fetchA.get(0).getTitle()).isEqualTo("Task for Alpha");

        // 4. Fetch tasks for Tenant Beta -> MUST only return Beta's task
        List<Task> fetchB = restClient.get()
                .uri("/api/tasks")
                .header("X-Tenant-ID", "tenant-b")
                .retrieve()
                .body(new ParameterizedTypeReference<List<Task>>() {});
        assertThat(fetchB).hasSize(1);
        assertThat(fetchB.get(0).getTitle()).isEqualTo("Task for Beta");
    }
}

When this test suite runs, Spring Boot spins up a real, temporary PostgreSQL 16 container, applies Flyway migrations, configures the RLS policies, and asserts that tenant-a can never view or manipulate tenant-b records. Running mvn test verifies this complete isolation in seconds.

Enterprise Use Cases: FinTech, Healthcare, and B2B SaaS

The defense-in-depth architecture described in this guide powers thousands of enterprise platforms globally. Here are three typical production architectures:

1. FinTech Multi-Tenant Payment Platforms

In payment gateway applications, merchant transactions must be segregated strictly. Financial regulatory standards (such as PCI-DSS Level 1) require strict evidence that merchant accounts cannot access another merchant’s ledger entries. By enforcing PostgreSQL RLS alongside Hibernate 7, payment platforms guarantee that even complex analytical batch jobs or reporting queries cannot mix merchant balances.

2. Healthcare Patient Management (HIPAA Compliance)

Electronic Health Record (EHR) providers serve hospitals and regional clinics from shared cloud infrastructure. HIPAA regulations mandate severe financial penalties for unauthorized disclosure of Protected Health Information (PHI). Combining @TenantId with PostgreSQL RLS ensures that clinic medical records, doctor notes, and prescription logs are sealed strictly at the database kernel level.

3. White-Label B2B SaaS Enterprise Suites

Enterprise SaaS platforms providing CRM, HR, or supply chain tools frequently offer custom domain branding (e.g., acme.myplatform.com). The ingress layer resolves the tenant from the Host domain header, binds the tenant context in a servlet filter, and provides immediate, multi-tenant isolation across shared compute instances, reducing infrastructure overhead by up to 80% compared to dedicated database clusters.

Production Readiness and Operational Guardrails

Deploying multi-tenant PostgreSQL systems to production requires adherence to several strict operational rules:

• Connection Pooler Mode (PgBouncer): If you deploy PgBouncer in front of PostgreSQL, configure it in Transaction Pooling mode (pool_mode = transaction). In transaction pooling, a connection is checked out only for the duration of a transaction block. Because we use SET LOCAL, the session variable is automatically discarded upon COMMIT. Never use Session Pooling with long-lived idle connections without explicit reset scripts.
• Dedicated Database User: Avoid connecting Spring Boot to PostgreSQL using the database superuser (postgres). PostgreSQL superusers bypass Row-Level Security policies by default! Create a dedicated application user (app_user) with restricted table privileges.
• Enforce Indexing on tenant_id: Always create compound B-tree indexes beginning with tenant_id on frequently queried tables (e.g., CREATE INDEX idx_orders_tenant_created ON orders (tenant_id, created_at DESC)). This ensures PostgreSQL quickly prunes out-of-tenant index branches before reading table data.
• Auditing and Soft Deletes: Ensure soft-delete columns (like deleted_at) and auditing fields (like created_by) work harmoniously with RLS. The RLS policy should strictly evaluate tenant_id first before evaluating secondary filtering predicates.

Common Pitfalls and How to Fix Them

Pitfall 1: Connecting as PostgreSQL Superuser

The Problem: Developers set up PostgreSQL RLS, but queries still return rows from other tenants during tests.

The Cause: The application is connected using the PostgreSQL superuser account. PostgreSQL superusers bypass RLS policies by default.

The Fix: Create an unprivileged application role for Spring Boot, or explicitly execute ALTER TABLE tasks FORCE ROW LEVEL SECURITY; so that the policy applies to table owners.

Pitfall 2: Using Session-Scoped SET Instead of SET LOCAL

The Problem: Executing SET app.current_tenant = 'tenant-a' causes subsequent HTTP requests on the same physical connection to inherit Tenant A’s identity if the request does not provide a tenant header.

The Cause: Plain SET persists across transactions until the physical connection terminates.

The Fix: Always use SET LOCAL app.current_tenant = ... within a transaction block. When the transaction commits, PostgreSQL automatically cleans up the variable.

Pitfall 3: Leaking TenantContext Across Thread Pools

The Problem: When processing asynchronous tasks using @Async or reactive publishers, the background thread runs with an empty or stale TenantContext.

The Cause: Standard ThreadLocal variables do not propagate automatically to child worker threads in executor services.

The Fix: Use a custom TaskDecorator to propagate the tenant identifier from the parent thread to the executor task, or utilize Java 25 Scoped Values with structured concurrency.

Frequently Asked Questions (FAQ)

What is the difference between Schema-per-Tenant and Shared-Schema with RLS?

Schema-per-tenant creates a separate PostgreSQL schema for each customer. While it offers good isolation, it suffers from severe operational bottlenecks: running schema migrations across thousands of schemas causes database catalog bloat and slow deployments. Shared-schema with RLS stores all tenant data in unified tables and uses database kernel policies to isolate records, allowing instant migrations and optimal connection pool sharing.

Does PostgreSQL Row-Level Security introduce a performance penalty?

The performance impact of RLS is minimal (typically under 1% overhead) when tables have proper indexes on tenant_id. PostgreSQL appends the RLS policy directly into the query execution planner. If your index starts with tenant_id, PostgreSQL uses an index scan to retrieve only the active tenant’s rows, avoiding table scans entirely.

Can I use Hibernate 7 @TenantId without PostgreSQL RLS?

Yes. Hibernate 7’s @TenantId provides complete query rewriting for standard JPA queries. However, using Hibernate alone leaves you vulnerable if developers execute raw native SQL queries, use unmanaged JDBC clients, or run manual database scripts. Pairing Hibernate with PostgreSQL RLS provides Defense-in-Depth, ensuring the database engine acts as a permanent safety net.

How do I handle background batch jobs for all tenants?

For administrative batch jobs (such as nightly billing runs), the background processor should loop through active tenants sequentially, binding each tenant identifier into TenantContext before executing the tenant’s transaction. Alternatively, administrative maintenance tools can connect using a dedicated superuser role that has RLS bypass privileges.

How does this architecture behave with Java 25 Virtual Threads?

Spring Boot 4 running on Java 25 Virtual Threads works seamlessly with this architecture. Because database connections are checked out only during active transactions and SET LOCAL variables are discarded upon transaction commit, virtual threads can safely share a standard HikariCP connection pool without risk of cross-tenant session contamination.

Conclusion and Next Steps

Building a secure, scalable multi-tenant SaaS application does not require choosing between exorbitant cloud hosting costs and dangerous data leakage risks. By uniting Spring Boot 4, Hibernate 7, and PostgreSQL 16 Row-Level Security, you construct an enterprise-grade defense-in-depth architecture.

Hibernate 7 eliminates boilerplate by automating application-level tenant resolution and query rewriting. Meanwhile, PostgreSQL RLS acts as an unyielding database firewall, dropping unauthorized rows at the storage engine level. Combined with HikariCP transaction-scoped session variables and full Testcontainers integration testing, your SaaS backend is fast, secure, and ready for millions of users.

References and Companion Code

• Workshop Companion Code: Multi-Tenant SaaS with Hibernate 7 and Spring Boot 4
• Hibernate 7 and Spring Data JPA 4: Features, Migration, and Performance
• PostgreSQL Row-Level Security with Spring Boot 4: Advanced Data Isolation
• Modern Local Development: Testcontainers & Docker Compose in Spring Boot 4
• TDD with Spring Boot 4 and Testcontainers: The Zero-Mocking Approach
• Official Hibernate 7.1 Multi-Tenancy User Guide
• PostgreSQL Official Documentation: Row Security Policies