Vertexa Technologies
Engineering

Designing multi-tenant SaaS architecture that survives its first ten customers

AV Adaeze Vertexa 2 min read Updated Aug 10, 2026
Designing multi-tenant SaaS architecture that survives its first ten customers

Nearly every multi-tenant platform we are asked to rescue has the same root cause: an isolation model chosen when there were three customers, none of whom had a compliance department.

The three models

Shared schema with a tenant column

Cheapest to build and to run. One missing where tenant_id = ? exposes one customer’s data to another. Viable, but only with query-level enforcement that cannot be bypassed — a global scope plus row-level security, not developer discipline.

Schema per tenant

Strong logical isolation, straightforward per-tenant backup and restore. Migrations become an orchestration problem, and connection pooling gets interesting somewhere north of a few hundred tenants.

Database per tenant

The strongest isolation and the only model that answers "can we host this customer in their own region" cleanly. Highest operational cost, so reserve it for the tier that pays for it.

The framework

Ask three questions before choosing:

  1. What is the regulatory floor? If any prospective customer will require data residency or physical separation, shared schema is already ruled out for that tier.
  2. What is the largest plausible tenant? A single tenant at 40% of total volume ruins shared-schema query planning for everybody else.
  3. What does restore look like? If a customer asks you to roll back their data to yesterday, a shared schema makes that a bespoke engineering project.

Hybrid is usually the answer

Shared schema for self-serve tiers, dedicated databases for enterprise. Build the tenant resolution layer so it does not care which model a given tenant uses, and you can move customers between tiers without a rewrite.

// Tenant resolution stays identical regardless of the underlying model.
$tenant = Tenant::resolveFromRequest($request);
$tenant->configureConnection();

What to build on day one regardless

  • A tenant context that is impossible to forget — resolved in middleware, enforced by a global scope.
  • Per-tenant usage metering, even if nothing bills on it yet.
  • An automated test that asserts tenant A cannot read tenant B. Run it on every commit forever.

Related reading

Chat on WhatsApp