Multi-tenant architecture

A multi-tenant architecture serves many customers (tenants) from a single running codebase and, usually, a shared database. Every request carries a tenant identity, and every query, cache key, background job and file path is scoped by it. The alternative, single-tenant, gives each customer their own stack; it is simpler to reason about and far more expensive to operate once you pass a handful of customers.

The practical decisions are where the tenant boundary lives. Common models are a shared schema with a tenant_id column on every table, a schema per tenant in one database, or a database per tenant. Shared schema is cheapest and scales to thousands of small tenants; database-per-tenant suits a few large regulated customers who want their own backups and encryption keys. Many mature products mix them: shared by default, dedicated for enterprise tiers.

Multi-tenancy is not the same as tenant isolation. The architecture makes sharing possible; isolation is the set of controls that stop one tenant seeing or slowing another. A product can be multi-tenant and badly isolated, which is the failure enterprise security reviews look for.

• CTO / Head of Engineering: the tenancy model is the hardest thing to change later; getting it wrong is the most common reason a SaaS product needs a rewrite at scale.
• CFO: shared infrastructure is what makes gross margin work; per-customer stacks turn hosting into a cost that grows linearly with revenue.
• Founder / CEO: enterprise buyers will ask which tenancy model you offer and whether they can have a dedicated one, so it shapes what you can sell.
• CISO: the tenant boundary is the primary security control in a SaaS product and must be enforced in code, not just policy.

Multi-tenancy exists because running a separate copy of software for every customer does not scale in cost, upgrades or support. One deployment means one release to test, one set of dashboards to watch and one bill to optimise. The trade-off is blast radius: a bad migration, a noisy tenant or a scoping bug affects everyone at once, so the design has to invest in isolation, rate limits and per-tenant observability from the start rather than bolting them on when the first large customer arrives.

• A B2B SaaS product onboarding hundreds of SMEs onto one shared database with a tenant_id on every row.
• A FinTech lending platform offering a dedicated database tier to NBFC customers who require separate backups for RBI audits.
• An education platform hosting many schools on one deployment while each keeps its own branding, roles and academic calendar.
• A logistics SaaS serving multiple transport companies whose drivers, routes and settlements must never cross over.
• A healthcare scheduling product where each clinic chain is a tenant with its own consent and retention settings.

Technique / practiceAn architectural pattern you design into a product rather than a tool you install. Eazyware's SaaS development service starts every new product with the tenancy decision and migrates single-tenant products to multi-tenant under the modernization service.

Eazyware service that covers it: SaaS / Cloud-native Application Development. Starting prices are on the pricing page.