Building a Multi-Tenant SaaS Backend with Node.js

What Is Multi-Tenancy?

Multi-tenancy means multiple customers (tenants) share the same application infrastructure while keeping their data isolated from each other. A SaaS project management tool with hundreds of companies using it is multi-tenant — Company A's projects never appear in Company B's dashboard. How you implement isolation is one of the most critical architectural decisions in SaaS backend development.

Tenant Isolation Strategies

Three main strategies: separate databases (strongest isolation, highest cost — each tenant gets their own database), separate schemas (PostgreSQL schemas or MongoDB databases — medium isolation, moderate cost), and shared tables with tenant ID (all tenants in the same tables, filtered by a tenantId column — lowest isolation, lowest cost). Most SaaS startups begin with shared tables and migrate to stricter isolation as they grow.

Tenant Identification and Routing

Identify tenants via subdomain (company.yourapp.com), custom domain (company.com), or a tenant ID in the JWT. In Node.js middleware, extract the tenant identifier from the request and attach it to the request object for use in all downstream handlers. In shared-table multi-tenancy, always include tenantId in every database query — create a wrapper around your database queries that automatically adds the tenant filter.

Data Isolation with Row-Level Security

In PostgreSQL, Row-Level Security (RLS) policies enforce tenant isolation at the database level — queries automatically filter to the current tenant's rows without application-level filtering. Set the current tenant ID as a session variable (SET app.tenant_id = 'xxx') and write RLS policies that check this variable. This is the most secure isolation approach — even a bug in application code cannot expose cross-tenant data.

Authentication in Multi-Tenant Apps

Include the tenant ID in your JWT payload. When a user authenticates, resolve their tenant from their email domain or a stored association, and embed the tenantId in the access token. Validate in middleware that the tenant in the token matches the tenant in the request (from subdomain or header). Prevent cross-tenant access by rejecting requests where these don't match.

Billing and Plan Limits

Enforce per-tenant plan limits in your service layer: check the tenant's subscription plan before allowing actions that consume resources. Store plan limits in a configuration object (starter: 3 projects, pro: unlimited) and check against the current count before creating new resources. Use Stripe to manage subscriptions and sync plan changes via webhooks to your tenant record in the database.