Blog Overview
Shared schema, schema per tenant, or database per tenant? What each costs, and how to choose based on the contract rather than team size.
The first architectural decision in a SaaS product is not the language or the framework. It is how each customer's data is isolated from every other. That decision sets operating cost, upgrade difficulty, and what you can later sell to enterprise customers. If it is made by habit rather than thought, it gets rebuilt after the first customer asks for special requirements.
This article explains the three common models, what each costs, and how to choose between them based on customer type rather than team size. There is no model that is always better. There is a model that fits the product stage and the customer segment.
The three models
Each model answers one question: where does tenant one's data end and tenant two's begin? The decision changes everything after it: backups, upgrades, pricing, and even how queries are written.
| Model | Isolation | Cost | When it fits |
|---|---|---|---|
| Shared schema with tenant_id | Logical, at row level | Lowest: one database, one backup | Early product, small and mid-size customers |
| Schema per tenant | Stronger: separate namespaces | Medium: multiple migrations and backups | Mid-market customers needing isolation or customisation |
| Database per tenant | Strongest: full isolation | Highest: operations and monitoring per database | Government, finance, or contractual requirements |
Why nobody starts with a database per tenant
Because the cost does not appear in the first build. It appears at upgrade number two. When you need to add a column to a table, you run it across fifty databases, verify each one, and plan a rollback for each. When one tenant fails, you need separate monitoring to know before they call you.
Full isolation is not free. It buys contractual reassurance and sells at a higher price. If your customers are small companies, they will not pay for that isolation. If they are government entities, they may accept nothing else. The decision follows the contract, not engineering alone.
Isolation is not just a column
Adding tenant_id to every table is the beginning, not the solution. Every query must pass through the tenant context, and the access layer must block writes outside it. The common failure is forgetting the tenant condition in one query, and one customer sees another's data. That is not a minor bug. It is a security incident and potentially a notification under the data protection law.
Use three layers of defence. First, a request context that carries the tenant and cannot be changed by the client. Second, a policy at the database or access layer that enforces the condition automatically. Third, integration tests that create two tenants and verify that no query crosses the boundary. The third layer is what catches the bug before the customer does.
Customisation without forking the code
From reading to shipping
Want this built, not just explained?
Bring us the problem behind the article. We will tell you what it takes, what it costs, and whether we are the right team.
Enterprise customers ask for customisation: extra fields, different workflows, and special reports. If you meet every request with a code branch, after a year you will run five versions you cannot upgrade. The answer is customisation through configuration and data, not conditionals in code.
Custom fields in separate tables. Do not add columns to the core table for each customer.
Configurable workflow. States and transitions defined in data, not in code.
Feature flags. A feature enabled for one tenant without a separate code version.
Report templates. The tenant builds from available fields, not from an engineering request.
Clear limits. A written list of what is not customisable, inside the contract.
A test environment per tenant. So a customer does not test a change on live data.
Upgrades and backups
In a shared schema, an upgrade is one operation. In schema-per-tenant, you need a script that walks every schema and records the result. In database-per-tenant, you need orchestration and monitoring per database. The more isolation, the more automation is required. A manual upgrade across fifty databases is not a plan; it is a risk.
Backups need the same testing. A backup never restored once is not a backup. Test restoring one tenant to a specific point in time, and measure the duration. That number is what you tell the customer when they ask about recovery. To see how this decision fits the project scope, read the SaaS MVP plan.
Cross-tenant analytics
Every SaaS product needs a reporting layer. In a shared schema, aggregating across tenants is easy but risky: one query without the tenant condition exposes everyone's data. In database-per-tenant, aggregation needs a separate job, which is safer because it does not touch raw customer data. Choose where aggregation happens before you need the first management report.
A decision in six questions
Who is your first customer? A small company or an enterprise? The contract sets isolation.
Is there a hosting requirement? In-Kingdom or in a specific region?
How many tenants in three years? Ten or a thousand? The number changes operating cost.
Will each customer need customisation? If yes, customise through data, not code.
Who runs the system? Your team or a managed provider? Isolation increases operational load.
What is the exit plan? How does a customer extract data if they leave? Put it in the contract.
Frequently asked questions
Can we start shared and move later? Yes, but the move affects keys, relations, and backups. Design so the tenant is a first-class dimension from the start.
Is tenant_id enough for isolation? No. It needs request context, policy, and tests. The column alone does not prevent mistakes.
What is the most expensive part of operations? Monitoring, backups, and upgrades, not servers.
Does full isolation raise the price? Yes, and it is sold to customers who need it. Do not pay for it on behalf of customers who do not.
Can both models coexist? Yes, with some tenants on a shared schema and others on a separate database. It adds complexity and needs a mature team.
Sources
- Microsoft Azure: multitenant approaches — a comparison of isolation models.
- AWS SaaS — architecture and operations for SaaS products.
- PDPL implementing regulation — isolation, disclosure, and notification.
- SaaS platforms — how we build and operate.
- The SaaS MVP plan — where the architecture decision sits.
