Three multi-tenancy models, and how to choose between them

Tenancy touches every query, every permission check, every migration and every backup procedure. Changing it after launch is one of the most invasive migrations a SaaS platform can undertake — not impossible, but far more expensive than deciding carefully at the start.

The decision is driven by three things: how strongly tenants must be isolated, how many tenants you expect, and how much operational overhead your team can absorb.

Every table carries a tenant identifier, and every query filters on it. This is the cheapest model to operate: one database, one migration, one connection pool, and straightforward cross-tenant analytics.

The risk is that isolation depends on application correctness. One missing filter leaks data. Row-level security in PostgreSQL moves that guarantee into the database, which is a meaningful improvement — but only if you also test it.

Each tenant gets its own schema within a shared database. Isolation is stronger and per-tenant backup and restore becomes straightforward.

The cost appears in migrations. Applying a change across thousands of schemas requires orchestration, and connection pooling becomes more complicated. This model works well up to the low hundreds of tenants and becomes painful beyond that.

Complete isolation: separate database, separate credentials, potentially separate region. This is what heavily regulated customers frequently ask for, and it makes data residency straightforward.

It is also the most expensive to run. Every tenant carries baseline infrastructure cost, and cross-tenant reporting requires a separate aggregation path. Provisioning must be fully automated from day one or it becomes a permanent operational drain.

Many mature platforms run more than one. Self-serve customers sit in a shared schema; enterprise customers who require it get a dedicated database. This is workable, but only if the application resolves tenant connection details through one consistent abstraction from the beginning.

Retrofitting a second tenancy model into a codebase that assumed a single one is a substantial piece of work. If you think you will eventually need it, build the abstraction early even while only using one model.

Start with the isolation requirement, because it is usually non-negotiable — a contract either demands physical separation or it does not. Then consider tenant count, since it determines operational cost. Only then weigh engineering preference.

For most products serving many small and medium customers, shared schema with row-level security and tested isolation is the correct answer, and the extra complexity of the alternatives is not repaid.