Multi-tenant Architecture
Term 6 of 68 in the ERPStack technical glossary
What is Multi-tenant Architecture?
Multi-tenant architecture is a software architecture pattern where a single physical instance of an application serves multiple distinct client organizations (tenants), while ensuring complete logical separation of user profiles and data.
Multi-tenant Architecture at a glance
- Isolation models
- 3 options: database-per-tenant, schema-per-tenant, or 1 shared schema with a tenant column
- Enforcement
- PostgreSQL 18 Row-Level Security policies, so isolation survives a forgotten WHERE clause
- Cost curve
- 1 shared cluster for many tenants; database-per-tenant multiplies connections and backups
- Migration cost
- N schema migrations to coordinate instead of 1, once tenants have separate databases
- Built with
- PostgreSQL 18 Row-Level Security through Drizzle ORM 0.45, Next.js 16 server actions setting tenant context, SSO and RBAC in front, Redis for per-tenant limits, deployed on AWS or Vercel
- Numbers that matter
- 3 isolation models; 1 forgotten filter is enough to leak; N migrations once tenants have N databases; 2 limits to set, connections and per-tenant rate
- Compare with
- Single-tenant deployments, and seat-priced SaaS such as Salesforce or HubSpot
- Commonly paired with
- RBAC, SSO, JWT sessions, Redis rate limits, PostgreSQL 18 policies and SOC 2 or ISO 27001 evidence
How Multi-tenant Architecture works in production
The ERPStack approach to Multi-tenant Architecture
We implement Schema-per-Tenant and Database-per-Tenant isolation patterns using Drizzle ORM and PostgreSQL. This guarantees complete data isolation for corporate clients while maintaining the scaling benefits of a shared codebase.
Frequently asked questions about Multi-tenant Architecture
Which Multi-tenant Architecture isolation model should you choose?
Start from the compliance requirement, not the code. In a Multi-tenant Architecture, database-per-tenant gives the strongest boundary and the simplest story for a regulator, at the cost of running N migrations and N backup schedules. A shared schema with Row-Level Security scales to far more tenants on 1 cluster and keeps operations simple, but every isolation guarantee now lives in policy that must be tested. Schema-per-tenant sits between the two.
How does Row-Level Security make Multi-tenant Architecture safer?
It moves the boundary from application code into the database. In a shared-schema Multi-tenant Architecture, isolation normally depends on every query remembering a tenant filter, and 1 omission leaks data across customers. A Row-Level Security policy attached to the table applies that filter unconditionally, including for ad-hoc queries and background jobs, which is exactly where hand-written filters get forgotten.
What breaks first as tenant count grows?
Connections and noisy neighbours. A Multi-tenant Architecture with 1 database per tenant hits connection limits long before it hits storage limits, which is why pooling matters more than raw hardware. On a shared cluster the earlier problem is 1 large tenant consuming shared resources, so per-tenant rate limits and query budgets belong in the design rather than in an incident review.
Can you change isolation model later?
Moving from shared schema to database-per-tenant is achievable because you are splitting data apart. Going the other way is much harder, since 2 databases can hold conflicting primary keys and divergent schema versions. That asymmetry is why the Multi-tenant Architecture decision deserves real thought at the start: pick the model your largest realistic customer will require, not the one your first customer needs.