Cost & Budgeting
Engineering Practice3 min read
Choosing a multi-tenant model before your first enterprise customer does it for you
Shared schema, schema-per-tenant, or database-per-tenant. The decision is cheap now and expensive in eighteen months.
Working on something like this?
Get an estimateThe short version
- Tenancy is one of the few decisions genuinely expensive to reverse. Make it deliberately.
- Shared schema is right for most products until a customer's requirements say otherwise.
- Isolation must be enforced in one place. Scattered WHERE clauses are how data leaks.
- Whatever you pick, make tenant identity explicit in the data model from day one.
Most SaaS products choose their tenancy model by accident: a customer_id column added early, and a set of assumptions that harden over two years. The bill arrives when an enterprise buyer asks how their data is isolated and the honest answer is a WHERE clause.
The three models
Shared schema
One database, one set of tables, every row carrying a tenant identifier. Cheapest to run and simplest to migrate — one schema change covers everyone. It is the right default for volume and self-serve products, and it is what most successful SaaS businesses run.
The risk is that isolation depends on every query being correct forever. The mitigation is to stop relying on discipline: enforce the tenant filter in one place — row-level security in PostgreSQL, or a data-access layer no query can bypass — rather than in a hundred call sites.
Schema per tenant
One database, a schema per customer. Isolation becomes structural rather than conditional, and per-tenant backup and restore become straightforward. The cost is operational: migrations now run per schema, and connection and catalogue overhead grow with tenant count.
This suits mid-market products with dozens or low hundreds of tenants, particularly where customers expect some data-model variation. It becomes painful in the thousands.
Database per tenant
Strongest isolation, easiest per-tenant restore, and the answer that satisfies the most demanding procurement questions. It also gives you the option of hosting a specific customer in a specific region — occasionally the only way to close a deal with residency requirements.
The cost is real: provisioning, migration orchestration, monitoring, and per-database overhead all scale with customer count, and you need the operational tooling to match. This is a deliberate choice for regulated or high-value enterprise products, not a default.
How to decide
1
Ask who your third customer is
Not your first. If your target market is regulated or enterprise, the isolation question arrives early and shared schema will be challenged — usually by a security questionnaire rather than by an architect.
2
Ask whether tenants need different data models
Genuine per-customer schema variation pushes you away from shared schema. Configurable fields within one model do not.
3
Ask what a per-tenant restore would take
If a customer asks you to roll back their data to yesterday, what happens? Shared schema makes this genuinely hard, and it comes up more often than teams expect.
4
Ask what your ops capacity is
Database per tenant with no automation is a support burden that grows linearly with sales. Be honest about whether you will build the tooling.
The hedge that actually works
Start with shared schema, but design as though you might move: tenant identity explicit everywhere, all access through one enforced path, no cross-tenant joins, and no assumption anywhere that all tenants live in one place. Products built that way can extract a large customer into their own database later. Products that were not, cannot — and that is the migration people describe as a rewrite.
Our SaaS platform build page covers how we make this decision with clients alongside billing and identity, which are the other two choices that are expensive to reverse.
Working through this on a real project?
Tell us what you are building. You will get a scoped estimate and an architecture you own, not a capability deck.
Common questions
One running application serving many customers, with each customer's data separated from the others. The models differ in how far that separation goes: a shared database with tenant-scoped rows, a schema per tenant, or a database per tenant — trading cost and operational simplicity against isolation strength.
Shared schema unless something specific pushes you off it — regulated customers, residency requirements, genuine per-tenant data-model variation, or a per-tenant restore obligation. It is the cheapest to run and simplest to evolve, and most successful SaaS products use it.
Moving from shared to more isolated is possible if the codebase was built for it — tenant identity explicit, all access through one enforced path. Where those assumptions were never held, extracting a tenant means touching every query, which is why teams describe it as a rewrite.
Show where it is enforced and how it is tested. Row-level security or a data-access layer no query bypasses, plus automated tests that attempt cross-tenant access and assert failure. Buyers who ask this question are looking for a mechanism, not a policy statement.