Three customers on the same app, same database, same nightly cron. The fourth launches a huge CSV import; the others see timeouts. Nobody planned noise isolation — only "we'll scale the server".
Multi-tenant SaaS shares infrastructure and code between customers. It is economical — but without data, performance and operations isolation from the start, every large customer becomes a risk to the others. Postponing isolation "until the enterprise deal" often means refactoring under pressure after the incident.
Three isolation levels
| Level | Isolation | Operational cost |
|---|---|---|
| Logical (tenant ID) | Good if code is rigorous | Low |
| DB schema per tenant | Better separation | Medium |
| Instance or cluster per tenant | Strong (enterprise) | High |
Start with logical isolation and automated tests proving tenant A never reads tenant B's data — non-negotiable. Every query without a tenant filter is a waiting breach.
Hosting: realistic choices
Avoid WordPress-like shared hosting: shared processes, opaque resources, no dedicated workers. Serious minimum: VPS or cloud with dedicated resources, managed DB or tuned PostgreSQL/MySQL, distinct staging environment (not one clone per customer), tested backups with per-tenant restore if your model allows.
For unpredictable spikes, see marketplace hosting. White-label hosting stays out of scope unless you have proven operational skill.
Data, GDPR and large customers
PostgreSQL allows row-level security or strict application equivalents. Plan export and deletion per tenant for data-subject rights. A DPA per B2B customer is standard. On data residency, a large French customer may require France — compare data in France and EU pool. Anticipate an enterprise tenant on dedicated infrastructure without rewriting the whole app.
Monitoring per tenant
At minimum measure slow queries by tenant ID, CPU/IO per account, 5xx error rate per tenant, and job queue depth per tenant. Alert before the neighbour complains — not when the enterprise contract is already threatened.
The climax: multi-tenant delays isolation until the big bill
Decide and move forward without blind spots
First model tenants with an ID everywhere and automated leak tests. Choose VPS or cloud hosting — not shared. Add rate limits and quotas from the first commercial version. Deploy per-tenant monitoring with a runbook for the "noisy customer". Finally document the enterprise plan (dedicated schema or cluster) before a prospect asks urgently. Compare infrastructure via the compare tool and guides.
Frequently asked questions
Multi-tenant from MVP?
Yes with strict tenant ID and isolation tests — a poorly designed shared schema is expensive to fix later.
One database per customer or shared?
Shared with tenant ID for SMB B2B; schema or instance for compliance or very large accounts.
Shared hosting or VPS?
VPS or cloud with several paying customers — WordPress-like shared is unsuitable.
Noisy customer?
Quotas, rate limits, per-account monitoring, contract allowing throttling or upgrade.
Next time you add a tenant without isolation tests, remember: one customer's CSV is already an incident for the others.