The verdict in three sentences
Multi-tenancy lets a single deployment serve all your customers, dividing infra cost per customer but adding a 20 to 40 % development premium. The isolation model (shared DB, schema per tenant, DB per tenant) trades off cost, security and scalability. In 2026, a shared DB suits launch; a DB per tenant becomes relevant for customers demanding strong data isolation.
Three isolation models
The core of a multi-tenant architecture is the level of data isolation between customers. The stronger the isolation, the higher the security, but the higher the cost and complexity.
| Model | Isolation | Infra cost / customer | Complexity |
|---|---|---|---|
| Shared DB (tenant_id column) | Low | Very low | Low |
| Schema per tenant | Medium | Medium | Medium |
| DB per tenant | Strong | High | High |
| Dedicated cluster (large accounts) | Maximal | Very high | Very high |
Development and infra premium
Multi-tenancy isn't only paid at initial design: you must handle automated onboarding, per-tenant routing, multi-tenant migrations and observability. This premium pays off as soon as you pass a few dozen customers.
| Line item (2026 order of magnitude) | Single-tenant | Multi-tenant |
|---|---|---|
| Initial development premium | Baseline | +20 to +40 % |
| Infra cost for 50 customers | 50 x infra | 1 x pooled infra |
| Onboarding a new customer | Manual, heavy | Automated |
| Schema migration | Simple | Orchestrated multi-tenant |
| GDPR data isolation | Native | Explicitly designed |
Switching thresholds and GDPR
The model evolves with growth. Below 20-30 customers, a well-designed shared DB (with strict tenant_id filtering) is enough. Beyond that, or facing regulated customers (health, finance) demanding strong isolation, you shift to schema per tenant, or even DB per tenant. On GDPR, isolation must be demonstrable: a cross-tenant leak is a SaaS's most severe incident.
Need a professional website?
Kolonell builds websites that attract clients, optimized for the Sénégalese market. Free quote in 2 minutes.
Mini case study
Julien, CTO of an HR SaaS in Bordeaux, must pick his model for 40 target customers in year one. Shared DB: dev premium +25 % (i.e. +EUR 14,000 on a EUR 56,000 base), pooled infra EUR 600/month. Alternative DB per tenant: dev premium +40 % and infra 40 x 90 = EUR 3,600/month. Across 40 customers, the shared DB saves ~EUR 3,000/month in infra, i.e. EUR 36,000/year. Julien chooses the shared DB with strict filtering, reserving DB per tenant for his 3 large accounts demanding contractual isolation.
FAQ
What premium does multi-tenancy add? A 20 to 40 % initial development premium over single-tenant, offset by pooled infrastructure cost from a few dozen customers onward.
Which isolation model at launch? A shared DB with strict tenant_id filtering for most B2B SaaS in the early phase. It offers the best cost/simplicity ratio under 20-30 customers.
When move to a DB per tenant? When regulated customers (health, finance) demand strong isolation, or when one tenant's volume justifies a dedicated cluster.
Is multi-tenancy a GDPR risk? It becomes one if isolation is poorly designed. A cross-tenant leak is a SaaS's most severe incident; isolation must be tested and demonstrable.
Can you mix models? Yes, and it's recommended: shared DB for most customers, dedicated DB for large accounts demanding contractual isolation.
Let's scope your project. Share your target customer count, your sector (regulated or not) and your budget: we'll frame the multi-tenant model and its infra cost. Detailed quote within 48 h. WhatsApp +221 77 596 93 33.
Mohamed Bah
Fondateur, Kolonell
Passionate about digital and entrepreneurship in Africa, Mohamed has been helping Sénégalese businesses with their digital transformation since 2020. Founder of Kolonell, he believes every SME deserves a professional and accessible online présence.
