Multi-Tenancy: The Core of SaaS Architecture

Multi-tenancy is what separates a SaaS product from hosted software. A multi-tenant system serves multiple customers (tenants) from a single deployment, sharing infrastructure while keeping each tenant's data isolated. At Nexis Limited, all four of our SaaS products — Bondorix, Ultimate HRM, Digital Menu, and Digital School — use multi-tenant architectures, each with a pattern chosen to match the product's requirements.

Pattern 1: Database-Per-Tenant

Each tenant gets their own database. The application routes requests to the correct database based on the tenant identifier (subdomain, JWT claim, or request header).

Advantages

  • Strongest data isolation — a tenant's data never accidentally leaks to another tenant
  • Per-tenant backup and restore
  • Per-tenant performance tuning and scaling
  • Simplest to reason about for compliance (GDPR, HIPAA)

Disadvantages

  • High operational overhead — managing hundreds of databases
  • Cross-tenant queries and analytics are complex
  • Schema migrations must be applied to every database

Pattern 2: Schema-Per-Tenant

All tenants share a single database, but each tenant has their own schema (namespace). PostgreSQL's schema support makes this pattern practical and performant.

Advantages

  • Strong isolation with lower operational cost than database-per-tenant
  • Single database to back up and monitor
  • PostgreSQL's search_path makes tenant context switching straightforward

Disadvantages

  • Schema migrations still need to run per-tenant (but in one database)
  • Connection pool management across schemas requires care
  • Not natively supported by all ORMs

Pattern 3: Shared Schema (Row-Level Isolation)

All tenants share the same database, same schema, same tables. Each table has a tenant_id column, and all queries include a tenant_id filter. PostgreSQL Row-Level Security policies can enforce this at the database level as a safety net.

Advantages

  • Lowest infrastructure cost — one database, one set of tables
  • Simplest to operate — single migration path, single backup
  • Cross-tenant analytics are straightforward
  • Easiest to scale horizontally with application-level sharding later

Disadvantages

  • Risk of data leakage if tenant_id filtering is missed in a query
  • Noisy neighbor problems — one tenant's heavy queries can affect others
  • Per-tenant backup and restore is complex

Our Approach

At Nexis Limited, we use shared schema with Row-Level Security for most products. It provides the best balance of operational simplicity, cost efficiency, and developer productivity. Row-Level Security in PostgreSQL acts as a safety net — even if application code misses a tenant_id filter, the database rejects unauthorized access.

Tenant Context Resolution

We resolve tenant context through a middleware that extracts the tenant identifier from the JWT token or subdomain, validates it, and sets the database session context (SET app.current_tenant). PostgreSQL RLS policies then use this context to filter rows automatically.

Conclusion

Choose your multi-tenancy pattern based on isolation requirements, operational capabilities, and scale expectations. Most SaaS products can start with shared schema and evolve to schema-per-tenant or database-per-tenant if stronger isolation is needed.

Building a SaaS product? Our team has built four production SaaS platforms — let us help with your architecture.