Designing Tenant Isolation for a Growing B2B SaaS Platform

This is a BRIVOX reference engineering case study. It examines a representative B2B SaaS scenario, not a named client engagement or a claim of measured production results.

Scenario and business constraint#

Imagine a service-management platform used by independent customer organizations. Each organization has managers and staff, and some people work with more than one customer. The product needs shared infrastructure while keeping requests, attachments and exports inside the correct organization.

The architectural goal is an explainable access boundary across the complete workflow. A tenant identifier added to a few database tables would not, by itself, establish that boundary.

Model identity and membership separately#

A user account identifies a person. A membership connects that person to an organization and a role. A request selects an organization, but the server verifies an active membership before using that selection.

The proposed model includes organizations, users, memberships and tenant-owned business records. Record identifiers must not grant access merely because a caller knows them. Authorization checks cover reads, changes, downloads and exports.

For relationships between tenant-owned records, a tenant-aware composite key can help prevent an appointment from referring to another organization's customer. PostgreSQL's constraint documentation describes the underlying uniqueness and foreign-key mechanisms; the exact schema still needs review for the product's relationships.

Carry the boundary through asynchronous work#

An export job records the organization, requesting actor and intended operation. The worker runs with an explicit tenant context and the required authorization policy, rather than inheriting an ambient “current customer.”

Cache keys include the relevant tenant and permission context. File downloads pass through access checks or appropriately limited delivery mechanisms. Support access is a separate, attributable capability, not an undocumented exception in ordinary customer endpoints.

Row-level security can provide another database boundary in PostgreSQL, but it requires careful role and policy design. Owners and privileged roles have important bypass behavior documented by PostgreSQL. It should not be enabled casually and then treated as proof of isolation.

Proposed verification plan#

Create two organizations with similar-looking records and one user who belongs to both. Then exercise these failures:

• Replace an object ID with the other organization's ID in every relevant endpoint.
• Remove membership while an export is waiting to run.
• Request a file using a copied link from a different account.
• Reuse a cache entry after switching organizations.
• Supply a related record from another tenant during creation and update.

Specify the intended result for each test, including the policy for already-approved queued work. Verify that error responses do not leak the restricted record's contents.

Trade-offs and acceptance evidence#

Shared tables can simplify deployment while increasing the importance of consistently enforced tenant scope. Separate databases can provide different isolation and recovery options but add provisioning and operations work. The right choice depends on customer requirements and operational capacity.

The proposed handover evidence is a tenant data map, access-policy matrix, negative test results and a runbook for support access. This reference scenario does not claim those tests have been run for an actual customer.

Discuss your own requirements through BRIVOX's custom software and SaaS service and application security service.

Technical references#

PostgreSQL constraints and row security policies.