Skip to content

Architecture · 3 Sep 2026 · 6 min read

Tenant isolation on a multi-tenant SaaS

Thousands of organizations on one codebase only works if every query is scoped to the tenant that owns the row.

A multi-tenant suite fails in one quiet way: a report, a cache key or a job that forgets the tenant. The row is valid. It just belongs to someone else.

On the enterprise SaaS platform I treated the tenant as part of the query, not as a filter added at the end. Billing through Stripe, role checks and reporting all receive the tenant id from the authenticated context. Background jobs carry it in the payload instead of looking it up later from global state.

The platform scaled to thousands of tenant organizations with 99.9%+ uptime, on AWS with Azure for selected workloads. Isolation is what made that growth safe to operate.

When a new feature ships, the review question is simple. Can this query return a row for a tenant the caller does not belong to? If the answer is yes, it does not merge.

More notes