Multitenancy and RLS: How to Design Customer Data Boundaries

Multitenancy Is a Data Contract, Not a UI Distinction

In subscription-based services, multiple customer organizations use the same application and database. Merely displaying an organization name on screen does not provide isolation. Every read and write must be checked to determine which tenant the request belongs to, and rows the requester is not authorized to access must also be inaccessible at the database level.

SAG treats the tenant that represents an organization separately from the user's role. When a user logs in, the server verifies the session and membership, then checks that the requested resource belongs to that tenant. It does not blindly trust the organization identifier sent by the browser.

Why Use Server-Side Authorization and RLS Together

Server-side authorization checks make business rules easy to understand and express explicitly. RLS (Row Level Security) adds another boundary at the database level, helping prevent rows belonging to other organizations from being exposed even if a query contains a mistake. Using both layers reduces the chance that an omission in either one will directly expose customer data.

The key principles are:

• Give tables that require tenant scoping a clear tenant identifier.
• Apply the same ownership checks to both reads and writes.
• Separate platform administrator permissions from customer operator permissions.
• Record who changed which resource in audit logs.
• Do not store secret values such as API keys and passwords in ordinary operational records.

Distinguish Shared Data from Customer-Specific Data

Some targets, such as competitor domains, can be observed by multiple customers. Other data, such as customer questions, improvement suggestions, and approval records, must be protected on an organization-by-organization basis. Unconditionally duplicating the former increases operational costs, while sharing the latter without due care creates security risks. SAG defines data ownership and access scope first, then decides on the storage structure.

Failure Scenarios to Verify

Passing normal read tests is not enough. You must also check that using another tenant's ID results in a 404 or a permission error, that users with lower-level roles cannot call mutation APIs, and that conflicts are detected when an attempt is made to overwrite a newer version with an older one. Data boundaries are not promises written in documentation; they are operational requirements proven through repeatable tests.

Also Check the Execution Role to Which RLS Applies

Even with RLS policies in place, table owners and roles with BYPASSRLS can bypass them. SAG maintains its server-side membership and tenant-condition checks independently of this. You need to verify both the database connection role and policy enforcement to determine the scope of isolation.

Technical References by Topic

• PostgreSQL Row Security Policies

Further Reading on This Topic

Explore tenant permissions, job retries, caching, and approval history.

• Designing a Reliable Customer Workspace
• Feature Guide FAQ