A multi-tenant SaaS platform runs a single application instance for multiple customers, keeping each customer's data and configuration isolated while sharing the underlying infrastructure. The model works commercially because one codebase, one deployment pipeline, and one set of servers support thousands of paying organisations simultaneously. The complexity is real, though: every layer of the stack — database, API, authentication, background jobs — must be tenant-aware from the beginning. Retrofit it later and you are rewriting core infrastructure while trying to ship features.
What multi-tenancy actually means in a product
Multi-tenancy is often described as an infrastructure decision. It is more precisely a data architecture and application design decision. You can run a multi-tenant application on a single server or across hundreds. The isolation model lives in the data layer and the application logic, not in how many machines the product runs on.
The practical consequence is that tenancy needs to be a first-class concept in the domain model from day one. Every piece of data belongs to exactly one tenant. Every request carries a tenant context. Every read and write path enforces that context. Every authorisation decision is evaluated within the tenant's boundary, not globally. [2]
A clean starting schema reflects this directly. There is a tenants table at the top level. Users are global identities. A memberships join table connects users to tenants, because one user can belong to multiple organisations. Every other entity — projects, invoices, documents — carries a tenant_id foreign key that is required, indexed, and part of any uniqueness constraint that spans tenant scope. [2]
Understanding this layer is foundational whether you are evaluating how to build a marketplace platform with SaaS characteristics or scoping a standalone B2B product. The data model shapes everything else.
The three data isolation patterns — and how to choose
The most consequential architectural decision in a multi-tenant build is how tenant data is isolated at the database layer. There are three canonical patterns, each a different trade-off between cost, isolation strength, and operational complexity.
Shared database, shared schema (pool model)
All tenants share the same tables. A tenant_id column on every row distinguishes ownership, and the application filters every query by that column. This is the cheapest pattern to operate: one database to manage, back up, and monitor. Migrations run once and apply to all tenants simultaneously. New tenant onboarding is a single row insert — fast and atomic with no infrastructure changes required.
The risk is the one most likely to cause a real incident. A missing WHERE tenant_id = ? clause does not throw an error. It returns data — the wrong tenant's data. Tests pass, CI is green, and confidential information is leaking. [2] The mitigation is PostgreSQL's Row-Level Security (RLS), which enforces tenant filtering at the database level so that even if application code omits the filter, the database itself applies the boundary. RLS should be treated as a non-negotiable safety net on any shared-schema platform handling sensitive data.
Best suited to: platforms expecting a high volume of tenants with similar data profiles and standard compliance requirements — project management tools, CRMs, internal portals.
Shared database, separate schemas (bridge model)
One database server, but each tenant gets their own schema. In PostgreSQL this means tenant_a.invoices and tenant_b.invoices are logically separated table sets within one database instance — stronger logical isolation than the shared-schema approach, without the operational overhead of separate database instances. Per-tenant data export and deletion are operationally cleaner as a result.
The cost surfaces at scale. Schema migrations become a coordination problem: applying a change across five hundred tenant schemas without downtime is a genuinely hard engineering challenge, and failures in the middle leave tenants on different schema versions in ways that are not always immediately visible. [6] Noisy-neighbour effects also persist at the compute and I/O level because the database instance is still shared.
Best suited to: mid-market SaaS with ten to five hundred tenants where per-tenant customisation is a real product requirement and the team has the operational maturity to manage migration complexity.
Database per tenant (silo model)
Each tenant gets a dedicated database instance. There is zero risk of cross-tenant data leakage at the database level, per-tenant backups and restores are straightforward, and compliance audits are significantly cleaner because physical separation is demonstrable rather than argued from application-level filtering. [7]
Infrastructure cost and operational complexity scale linearly with tenant count. Schema migrations must be orchestrated across every database instance. Cross-tenant analytics requires a separate aggregation layer. This model makes economic sense for enterprise SaaS serving fewer than a hundred high-value customers with strict compliance requirements — regulated sectors, government contracts, or clients who contractually require physical data isolation.
Microsoft's Azure documentation identifies this database-per-tenant pattern as a multitenant application where a new database is provisioned for each new tenant, with the consequence that individual tenant restores have no impact on other tenants. [5]
Choosing and combining patterns
Most mature SaaS platforms do not stay with a single pattern. The hybrid approach — standard tenants on shared schema for cost efficiency, enterprise tenants on dedicated databases for isolation and compliance — is the architecture most professional teams land on once they have enough tenants and revenue to justify the additional routing complexity.
| Pattern | Cost efficiency | Isolation strength | Migration complexity | Best for |
|---|---|---|---|---|
| Shared schema | Highest | Application-enforced | Low | 100+ tenants, standard compliance |
| Separate schemas | High | Schema-enforced (logical) | Medium | 10–500 tenants, moderate compliance |
| Database per tenant | Lowest | Physical | High (per-instance) | Under 100 high-value enterprise tenants |
| Hybrid | Flexible | Tiered | Medium–high | All scales, tiered pricing model |
Tenant resolution: how every request finds its scope
Once data isolation is decided, the application needs a reliable way to identify which tenant a request belongs to before doing anything else. The main approaches each carry different implications for infrastructure and user experience.
- Subdomain (
acme.yourproduct.com): Intuitive for users and simplifies cookie isolation, but requires wildcard SSL certificate management and DNS configuration. Custom domains — where a tenant points their own domain at the platform — add another layer of complexity at the edge. - JWT claims: Embedding tenant context in authentication tokens is the mainstream approach. Tenant identification completes alongside authentication, tampering is prevented by signature verification, and the design is stateless. The trade-off is that tokens need refreshing and re-authentication is required when switching tenants. [3]
- HTTP header: Includes the tenant ID in a header on every request. Clean and decoupled from the URL, this works well for API-based communication between services but is unsuitable for browser sessions accessed directly by users.
- Path-based (
yourproduct.com/t/acme/): Requires no DNS configuration and works across single domains, but is less ergonomic for end users and can make routing logic more complex.
Most teams combine approaches: subdomain routing for the user-facing application, JWT claims for the API layer. The important principle is that once tenant context is established, it must propagate through every downstream service and must never be optional — if a service can operate without a tenant ID, it eventually will, by accident. [2]
Domain and branding isolation: white-label requirements
Some multi-tenant products go further than data isolation and offer tenants their own branded surface — a distinct domain, logo, colour scheme, and sometimes a fully white-labelled experience. This is common in platforms that sell to businesses who in turn serve their own customers.
Wall & Fifth built SellYourBoat.io as exactly this kind of platform: a multi-tenant brokerage system where each tenant operates under their own brand and domain, with a separate public marketplace aggregating all published inventory across every tenant. Two distinct product experiences — one B2B, one B2C — run from a single codebase. The B2B layer handles listing workflow, media management, and brokerage operations per tenant. The B2C layer aggregates and presents that inventory to buyers, with no tenant branding visible at that surface.
White-label requirements add meaningfully to the build scope. Per-tenant configuration needs to be stored and resolved on every request. Email templates, notification copy, and UI tokens all need to be tenant-scoped. Custom domain mapping requires infrastructure work at the edge, separate from the application routing logic. These are decisions that belong in scoping, not as later additions — the underlying commercial and technical decisions behind building a marketplace apply just as strongly to multi-tenant SaaS with a marketplace layer.
Access control inside a tenant
Multi-tenancy solves the boundary between tenants. Access control solves the boundary within one. Most B2B SaaS products need a role hierarchy per tenant: an administrator who can manage users and settings, a standard member who can use the product, and possibly additional roles with narrower permissions — read-only, department-scoped, or resource-specific.
The important design principle is that roles are always evaluated within the tenant context, never globally. A user who is an administrator of tenant A has no elevated permissions in tenant B. The membership join table carries the role assignment: memberships(tenant_id, user_id, role). Authorisation middleware checks both tenant membership and role before any sensitive operation is permitted.
A common mistake is implementing role logic at the UI layer only — hiding buttons the user should not see — without enforcing the same check at the API level. An unauthorised API call can reach the database without a UI-level control stopping it. Every sensitive route needs server-side authorisation that checks tenant membership and role independently of what the frontend renders.
When to build multi-tenant from the start versus when to retrofit
Retrofitting multi-tenancy into a codebase built as a single-tenant application is expensive and disruptive. It means adding tenant_id to every table, auditing every query, rebuilding the authentication layer, and migrating all existing data. Teams that have done this describe it as months of infrastructure work that delivers nothing visible to users.
The signals that indicate a founder needs multi-tenancy at MVP stage are specific:
- The business model involves selling access to multiple separate organisations, not a single company's users
- Each customer's data must be invisible to other customers — not merely protected by permissions
- The product offers white-labelling or custom domains as part of the proposition
- The monetisation model is subscription-based per organisation, not per user or per transaction
- You expect compliance questions about data isolation from prospective customers before launch
If the product is a single company's internal tool, a consumer app, or a marketplace where the platform sees all data, standard single-tenant architecture is appropriate. The distinction matters for the build scope and the cost estimate. Understanding how marketplace monetisation models affect the build is a useful parallel — the monetisation choice determines what the product must do structurally, just as the tenancy model does.
A hypothetical example: scoping a multi-tenant SaaS MVP
This is a hypothetical example to illustrate the scoping decisions involved.
Suppose a founder is building a B2B compliance management tool for financial services firms. Each customer is a separate firm whose compliance data must be completely invisible to other firms. The product will be sold on a per-firm subscription. Some enterprise customers have already asked whether their data is stored separately.
The right starting architecture is shared schema with RLS enabled and a clear migration path to database-per-tenant for enterprise customers. Subdomain routing handles tenant resolution at the web layer (firm-a.compliancetool.com), with JWT claims carrying tenant context through the API. Roles within each tenant are: admin, compliance officer, and read-only auditor. Custom domains are deferred to phase two.
At scoping, this translates to: a tenants table, memberships with role columns, RLS policies across all sensitive tables, subdomain middleware, tenant-scoped JWT issuance, and a billing integration that activates or deactivates tenant access based on subscription status. None of this is optional — leaving any part out creates either a security gap or a costly rebuild when the first enterprise customer asks the isolation question.
Frequently asked questions
How much does a multi-tenant SaaS platform cost to build?
At Wall & Fifth, custom software builds start from £30,000 for a focused MVP and are quoted on a fixed-price basis once the scope is defined. Multi-tenant platforms with white-labelling, custom domains, role hierarchies, and billing integration are typically more complex than a standard single-tenant SaaS MVP and fall into the larger build tier, scoped individually. The scope conversation is where the real cost is set.
Can I add multi-tenancy after launch if I start single-tenant?
Technically yes, but it is one of the more disruptive refactors a codebase can go through. Every table needs a tenant_id column, every query needs auditing, the authentication layer needs rebuilding, and existing data needs migrating. If multi-tenancy is a near-term requirement, building it in from the start is almost always cheaper in total than retrofitting it six months in.
What is the difference between multi-tenancy and multi-instance?
Multi-tenancy means multiple customers share one running application and one database (or a logically partitioned database), with isolation enforced in code. Multi-instance means each customer gets their own copy of the application running separately — sometimes called single-tenant per customer. Multi-instance provides stronger isolation by default but costs more to operate because infrastructure scales linearly with customer count. Most SaaS products start multi-tenant and graduate selected enterprise customers to dedicated instances as their contract value justifies it.
How do schema migrations work when you have hundreds of tenants?
In a shared-schema model, migrations run once and apply immediately to all tenants — this is one of the pattern's main operational advantages. In a schema-per-tenant or database-per-tenant model, migrations must be orchestrated across every tenant separately. The standard approach is a management database that tracks the current migration version per tenant, with the deployment pipeline identifying tenants below the current version and running migrations in batches with rollback handling for failures.
What is the noisy-neighbour problem and how is it mitigated?
The noisy-neighbour problem occurs when one tenant's heavy workload — a large data import, a complex analytics query, a batch job — degrades performance for all other tenants sharing the same database or compute resources. In a shared-schema model, a single tenant running an expensive query can saturate the database CPU and cause timeouts for every other tenant. Mitigations include per-tenant connection pooling limits, query timeout enforcement by tenant tier, routing analytics and reporting queries to read replicas, and rate limiting at the API level. In a database-per-tenant model, the problem does not exist at the data tier but the infrastructure cost is correspondingly higher.
Does Wall & Fifth have experience building multi-tenant platforms?
Yes. SellYourBoat.io was designed and built as a multi-tenant brokerage platform with a public marketplace aggregating all tenant inventory. Each brokerage tenant operates under their own brand and domain; the public-facing marketplace surfaces their listings without exposing tenant identity. This kind of two-layer architecture — private B2B tooling per tenant, shared B2C discovery layer across all tenants — is a common pattern for marketplace operators and specialist SaaS products serving industry professionals.