Most architecture decisions are cheaper to revisit than to agonise over. You can swap a queue, replace a framework, move from one cloud to another — expensive, disruptive, survivable.
Tenancy is different. How you separate one customer's data from another's touches every query you will ever write, every migration you will ever run, every backup and restore procedure, and every enterprise security questionnaire you will ever answer. Changing it later means rewriting the data layer of a live system while customers depend on it.
So it is worth an hour now. Here are the three models, honestly compared.
Model 1: Shared Schema
One database, one set of tables, a tenant_id column on everything. Every query filters by tenant.
- Cost: the lowest by a wide margin. One database to run, one to back up, one to tune.
- Operations: the simplest. One migration, applied once, and every tenant is on the current schema.
- Scaling: excellent for many small tenants. This is how you serve ten thousand customers profitably.
- Isolation: the weakest. A single missing
WHERE tenant_id = ?is a cross-tenant data leak. - Noisy neighbours: real. One tenant's heavy report can degrade everyone's experience.
- Per-tenant restore: genuinely hard. Restoring one customer's data from a shared backup is surgery.
The isolation risk is manageable but it must be managed structurally rather than by discipline. Enforce tenancy at the lowest possible layer — row-level security in the database, or a data-access layer that makes an unscoped query impossible to write — never by relying on every developer remembering. Code review does not scale as a security control.
If you take one thing from this article: make the unscoped query unwriteable, not merely discouraged. Every shared-schema breach we have read about was a query someone forgot to filter.
Model 2: Schema per Tenant
One database, a separate schema per tenant. Same server, separate namespaces.
- Cost: still low — one database instance.
- Isolation: meaningfully better. Cross-tenant access requires a deliberate mistake rather than a forgotten clause.
- Per-tenant restore: feasible, which shared schema is not.
- Operations: here is the catch. Migrations must run per schema, and they must be resilient to running against hundreds of them. A migration that half-succeeds across 400 schemas is a genuinely bad afternoon.
- Scaling ceiling: databases start to strain in the low thousands of schemas — connection pooling and the catalogue itself become the constraint.
This is the pragmatic middle, and it suits platforms with tens to low hundreds of tenants where each is commercially significant. It is also the model most likely to be adopted for the wrong reason — because it feels safer than shared schema without anyone having priced the migration tooling it demands.
Model 3: Database per Tenant
Each tenant gets their own database, sometimes their own infrastructure entirely.
- Isolation: the strongest available, and the easiest to explain to a security reviewer.
- Compliance: the model that answers data-residency requirements cleanly — this tenant's database lives in Frankfurt, that one's in Virginia.
- Per-tenant backup, restore and export: trivial. So is deleting a customer entirely when they leave, which matters more than teams expect.
- Noisy neighbours: eliminated. One tenant cannot affect another's performance.
- Cost: the highest, and it scales linearly with tenants rather than with usage.
- Operations: the heaviest. Migrations, monitoring, backups and upgrades all multiply, and you will need real automation before you have real tenant numbers.
This model earns its cost in exactly one situation: enterprise customers whose procurement process demands it. If your buyers send security questionnaires asking where their data physically resides and whether it shares infrastructure with anyone else, this is the answer they want, and it may be the difference between winning and losing the deal.
Choosing
Work through these in order:
- Who is the customer? Thousands of small tenants points to shared schema. Dozens of large enterprises points to database per tenant. A mix points to a hybrid — see below.
- What does compliance actually require? Not what feels safest. Read the obligations. Data residency and no shared infrastructure are specific requirements with specific answers; generalised anxiety is not.
- What price point are you selling at? Database per tenant has a floor cost per customer. If that floor is a meaningful fraction of your monthly price, the model is wrong for that segment.
- How much operations capability do you have? Choosing an isolation model your team cannot automate is choosing an outage.
- How likely is a per-tenant restore? If a customer deleting their own data by accident is plausible, shared schema will hurt.
The Hybrid, and Why It Usually Wins
Most successful platforms end up mixed: shared schema for the self-serve tier, dedicated databases for enterprise customers who pay for it. This is a legitimate and common destination.
It is also far easier to reach if you plan for it early. Building a tenant-resolution layer that can route to a shared database or a dedicated one costs very little at the start and is the thing that makes the hybrid possible later. Retrofitting it into a codebase that assumed one connection string is where the real expense lives.
If you are unsure, build shared schema behind an abstraction that can route per tenant. You get the cheap model now and the expensive one available later — which is the opposite of the position most teams end up in.
What Ties You Down Regardless
Whichever model you pick, these decisions calcify alongside it and deserve the same scrutiny:
- Tenant identity in your authentication layer. Retrofitting multi-tenancy into a single-tenant auth model is painful, so decide up front whether a user can belong to more than one tenant.
- Whether tenant IDs are exposed in URLs and APIs. Changing this later breaks integrations your customers built.
- Where per-tenant configuration lives. In the tenant's data or in a central registry? Both work; mixing them does not.
- How you handle a tenant merge or split. Rare, and brutal if the data model never anticipated it — customers do acquire each other.
- Your background job model. Per-tenant queues, fair scheduling and per-tenant rate limits are much harder to add than to design in.
The Question Behind the Question
Teams usually arrive at this decision because someone asked is our data secure? — and reach for the strongest isolation available as reassurance. That instinct is understandable and it is expensive.
Isolation is one control among several. A database-per-tenant platform with weak access control, no audit logging and a shared administrative back door is less safe than a well-built shared-schema platform with row-level security and proper authorisation. Choose the tenancy model on requirements and economics; buy security separately, deliberately, and in more than one layer.
This is the kind of decision we work through before a line of code is written — see what a custom Node.js platform really costs for how it feeds the budget. Our Node.js platform practice and our full-stack team do this alongside clients rather than for them, because the answer depends on commercial facts only they hold. Where the buyers are regulated — as in finance and healthcare — the compliance requirements usually decide it.
Frequently asked questions
Which tenancy model should a new SaaS start with?
Shared schema, behind a tenant-resolution layer capable of routing to a dedicated database later. That gives you the cheapest model now and preserves the expensive one as an option — which is the opposite of the corner most teams paint themselves into.
How do we prevent cross-tenant data leaks in a shared schema?
Enforce tenancy below the application: row-level security in the database, or a data-access layer where writing an unscoped query is impossible. Relying on developers remembering a WHERE clause is not a control, and code review does not scale as one.
When is database-per-tenant worth the cost?
When enterprise procurement demands it — data residency in a named jurisdiction, or a documented guarantee of no shared infrastructure. If your buyers send security questionnaires asking those questions, this model is what wins the deal. Otherwise it is expensive reassurance.
Can we change the tenancy model later?
Yes, at considerable cost. It means rewriting the data-access layer, migrating live customer data and revalidating every query, while the platform is in use. Building a routing abstraction early makes it far cheaper; not having one is what makes the decision feel irreversible.
Does multi-tenancy affect performance?
In shared schema, yes — one tenant's heavy workload can degrade others, which is why per-tenant rate limits and fair job scheduling matter. Dedicated databases eliminate the problem and replace it with a larger operational surface to keep healthy.
Get the Decision Reviewed Before You Build
Tell us who your customers are and what their procurement asks for, and we will tell you which model your business actually needs — usually the cheaper one. Talk to our team; we reply within a business day.