Skip to main contentMain content

Boardroom Answers · Technology & Platform · Technical Architecture & Scalability

You run all tenants in one shared database. Why should I accept that over a dedicated instance per customer?

The question a Chief Enterprise Architect (CEA) asks.

The short answer

Pooled tenancy with isolation enforced on every query, a CI gate that fails the build if a query loses its organisation filter, row-level security as a second line, and cell architecture that offers dedicated deployment as the premium path.

The full executive answer

Shared-schema multi-tenancy is the mainstream architecture for enterprise SaaS — it is what Salesforce runs — and the trade-off analysis is codified in the AWS SaaS Lens: silo per customer gives isolation at the cost of operational sprawl, version skew, and per-tenant cost; pooled tenancy gives uniform operations and economics, and the isolation question moves to how rigorously the boundary is enforced. Our answer has two layers, and I will be precise about which does what. On a live request, isolation is enforced in application code: every query is filtered to the organisation resolved from your verified sign-in, and an automated cross-tenant test fails the build if a tenant-table read ships without that filter. Underneath it, row-level security — RLS — is enabled on every tenant table, so anything connecting to the database directly, such as a leaked public key, cannot read another tenant's rows; a two-tenant leakage test proves those policies against a real Postgres in CI.

Two properties make our implementation defensible to an architect. First, the tenant identity comes only from the verified sign-in token, resolved server-side — never from anything a client sends — so the boundary cannot be forged from outside. Second, and this is the part I have not seen elsewhere: both layers are enforced on our engineers by the build pipeline. One test fails the build if a tenant-table read loses its organisation filter; another scans every database migration and fails the build if any table carrying tenant data lacks an RLS policy. The next engineer cannot quietly forget either; the pipeline will not let them.

And the models are not mutually exclusive in our architecture: it is already cell-based — the EU and India cells are defined in configuration — and a cell is also the mechanism for a dedicated single-tenant deployment at the top tier. So pooled economics by default, silo as a premium, on the same codebase. That is the SaaS Lens playbook, deliberately followed.

Grounded in: AWS Well-Architected SaaS Lens (silo/pool/bridge tenancy models)

Want this answered live, on your data?