Back to knowledge base
Data

Multi-tenancy and customer isolation

Useful for

SaaS architectureData protectionPlatform governanceCustomer trust

Introduction

For SaaS, tenant isolation is both an architecture decision and a governance decision. It affects data models, authorisation, logging, backups, support tooling and customer trust.

The decision does not have to be final during the POC, but it should not be ignored. Once external users and real customer data exist, retrofitting tenant isolation becomes expensive and risky.

The core decision

The company needs to decide whether the product is:

  • Single tenant: each customer has its own isolated deployment or data store.
  • Multi-tenant: customers share a platform and are separated logically.
  • Hybrid: some customers are isolated while others use the shared platform.

Each model has trade-offs. Single tenant can be easier to reason about for isolation, but more expensive to operate. Multi-tenant can be more efficient, but it requires stronger engineering discipline. Hybrid can support enterprise sales, but increases operational complexity.

Design implications

Tenant isolation affects:

  • Tenant ID in every data model.
  • Authorisation checks.
  • Noisy-neighbour risk.
  • Per-tenant backup and restore implications.
  • Per-tenant deletion and export.
  • Tenant-aware logging without PII.
  • Support access to customer data.
  • Background jobs and scheduled processes.
  • Analytics and reporting.
  • Test data and staging environments.

Detailed isolation questions

Before external users enter real data, the team should be able to answer:

  • How is a tenant identified?
  • Where is tenant context enforced?
  • Can one tenant access another tenant's data by mistake?
  • How are admin and support users scoped?
  • Can a tenant be exported?
  • Can a tenant be deleted?
  • What happens if one tenant generates heavy load?
  • How would a per-tenant restore work?

How this evolves as the company grows

  • At POC, tenant isolation may be deferred if the decision and risk are explicit.
  • Before Pilot, customer isolation must be understood where external users or customer-sensitive data are involved.
  • Before Production, isolation choices should align with support access, backups, logging, contracts and customer assurance.
  • At scale, isolation strategy affects enterprise sales, operational complexity, cost, restore patterns and incident blast radius.

What an agent should look for

  • What is the blast radius of a tenant issue?
  • Can support access be scoped?
  • How do backups and restores work per tenant?

What good looks like

The company can explain the decision, show the evidence behind it and identify the next point where the control needs to mature.

How Brokenhouse helps

Turn this into a practical plan.

I help technology teams turn this guidance into decisions, implementation plans, governance evidence and production-ready operating models.

Talk through your situation

Next guidance

Related decisions to work through

AI

Agentic software delivery governance

Agents used by the delivery team need a different governance model from AI models embedded in the product. Delivery agents may not be part of the customer-facing service, but they can still create risk because they may read code, write code, inspect logs, summarise documents, generate infrastructure changes or draft customer-facing material.