The three practical tenancy models trade isolation against operational cost. Shared schema with row-level security suits most products; separate databases are worth their overhead only when residency or contractual isolation demands it.
The short answer
For most SaaS products, a shared schema with tenant identifiers and database-enforced row-level security is the right starting point. It gives one migration path, efficient resource use, and isolation that does not depend on every query being written correctly.
Database-per-tenant becomes the better choice when customers contractually require physical separation, when data residency differs per customer, or when a small number of very large tenants would otherwise dominate shared resources.
Why the decision is hard to reverse
Tenancy is not a feature; it is an assumption embedded in every query, every migration, every backup procedure and every support tool. Changing it later means rewriting the data access layer, re-validating every access path, and migrating live customer data without downtime.
This is why it is worth an explicit architecture decision before the first table is created, even when the product has one customer and the question feels premature.
Shared schema with row-level security
Every tenant-owned table carries a tenant identifier, and the database enforces that a session may only see rows belonging to its tenant. The application sets the tenant context once per request; individual queries do not carry the filter.
The advantage over filtering in application code is decisive: a developer who forgets a `WHERE tenant_id = ...` clause gets no rows rather than everybody’s rows. Isolation stops depending on reviewer vigilance.
The costs are real but manageable. Noisy-neighbour effects need query limits and indexing discipline. Per-tenant restore is harder, because you are extracting rows rather than restoring a database. And some enterprise buyers will ask whether their data shares a table with a competitor’s.
Schema per tenant
Each tenant gets its own schema within one database, with identical table structures. Isolation is clearer, per-tenant backup is simpler, and the data stays within one instance.
The cost appears in migrations. A schema change must be applied to every tenant schema, and with several hundred tenants this becomes a job to orchestrate, monitor and make resumable. Connection pooling also becomes more involved.
This model suits products with tens to low hundreds of tenants where isolation matters more than operational simplicity. Above that, migrations dominate.
Database per tenant
Complete separation: separate database, separate credentials, separate backup lifecycle, potentially separate region. This is what enterprise and public sector buyers usually mean when they ask about isolation, and it is the only model that answers data residency per customer cleanly.
It is also the most expensive to operate. Provisioning becomes part of onboarding, migrations must be orchestrated across the estate, monitoring is per-instance, and the fixed cost per tenant sets a floor on viable pricing.
Reserve it for cases where the requirement is explicit and the pricing supports it.
A hybrid is often the honest answer
A common mature pattern: shared schema for the self-serve tier, dedicated databases for enterprise customers who pay for it. This works only if the data access layer is built to resolve a tenant to a connection from the start — which is a modest amount of work early and a substantial one later.
If you expect to sell to enterprise eventually, build that indirection now even if every tenant currently lands on the same database.
Questions that decide it
Will any customer contractually require physical data separation? Will customers in different jurisdictions require their data stored locally? How many tenants do you expect in three years — tens, hundreds or thousands? Is any single tenant likely to be an order of magnitude larger than the rest?
Answer those four and the model usually selects itself.
Written by the Webnatrix engineering team. This is evergreen technical writing, maintained as our practice changes rather than published to a date.