---
title: "Separating customer data in a multi-tenant SaaS — Orvun Labs"
description: "Tenant isolation is a boundary to design and verify, not a field added to a table at the end."
canonical: "https://orvunlabs.com/en/journal/saas-tenant-data-isolation"
language: "en"
last_modified: "2026-09-13"
---

# Separating customer data in a multi-tenant SaaS

Tenant isolation is a boundary to design and verify, not a field added to a table at the end.

![Separating customer data in a multi-tenant SaaS](https://orvunlabs.com/images/blog/saas.svg)

- Published: 2026-09-13T09:00:00.000Z

- [Building SaaS](https://orvunlabs.com/en/journal/topic/saas.md)

## The decision

Tenant isolation is a boundary to design and verify, not a field added to a table at the end. Start by defining what a tenant owns, who may cross that boundary and whether individual customers need independent recovery or infrastructure. Microsoft’s architecture guidance describes shared and isolated storage approaches; the choice remains specific to your operating model.

## A worked example

Imagine a SaaS used by separate repair companies. A technician at company A must not retrieve company B's job by guessing its identifier. Exercise list pages, search, attachments, exports, background jobs and support access as separate paths. One protected detail page does not establish isolation everywhere.

## Define the tenant boundary in ordinary work

List the records that belong to a company and the records deliberately shared across companies. A public product catalogue may be shared while prices, customer contacts and work orders remain private. Define what happens when a person belongs to two companies: switching the active company should change the entire working context, including search, file downloads and exports. Do not rely on a visual company label to provide that boundary. The server must establish the user's membership for the operation being requested. Document any privileged support path separately, including its authorisation, duration and record of use.

## Test leakage through indirect paths

Use two synthetic companies with deliberately similar records and users with different permissions. Try identifiers from the other company in detail routes, exported reports, attachments and background operations. Warm a cache under one company, then request similar information under the other. Remove a user's membership while work is waiting and decide whether the queued job should continue under an explicitly authorised service identity or be cancelled. These tests are about the intended authority at execution time, not just whether the initial screen hid a button. Review negative cases when new search, export or integration features are added.

## Treat recovery and deletion as isolation requirements

Ask how the team will restore one customer's accidentally deleted records without rewinding every other customer's work. A separate database may make some operational tasks easier, but each restore still needs verification of attachments, identifiers and dependent systems. With shared storage, selective recovery requires a deliberate procedure and safe staging environment. Rehearse the chosen method with synthetic data before promising it to customers. Similarly, define export and deletion boundaries, including derived indexes and backups under the applicable retention process. The design decision is complete only when normal access, privileged access and recovery all follow an understandable tenant boundary that the operating team can demonstrate.

## Alternatives worth weighing

- Shared tables can simplify operating a small product but require consistent tenant-aware access. Separate databases give a stronger operational boundary and add migration, connection and backup work. A hybrid can serve different customer needs, provided the support team understands both arrangements.

## Where the plan breaks

Do not trust a tenant identifier supplied by the browser without checking membership. Include tenant context in cache keys and file access decisions. Test a user changing organisations and losing access while a queued job is still pending.

## Before you commission the work

Can one customer's data be restored or exported independently? Who authorises support access, and is it recorded? Discuss those requirements during SaaS design; a storage diagram alone cannot settle them.

## Sources & further reading

- [Microsoft Azure Architecture Center: multitenant storage and data](https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/approaches/storage-data)

## SaaS development

A product people can use, subscribe to and depend on.

- [Discuss this service](https://orvunlabs.com/en/services/saas-development.md)

## Related reading

- [Designing SaaS subscriptions as a lifecycle](https://orvunlabs.com/en/journal/saas-subscription-billing-decisions.md)
- [SaaS onboarding: reach the first useful outcome](https://orvunlabs.com/en/journal/saas-onboarding-first-value.md)

## Let's make something useful.

A first product, a difficult workflow or software that needs a fresh start. Tell us where you are.

- [Tell us about your project](https://orvunlabs.com/en/contact)

## Structured data

```json
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://orvunlabs.com/#organization",
      "name": "Orvun Labs",
      "url": "https://orvunlabs.com",
      "logo": "https://orvunlabs.com/orvunlabs-icon-512.png",
      "description": "Custom software, SaaS products and AI-powered tools — designed around your business.",
      "knowsAbout": [
        "Custom software",
        "SaaS product development",
        "AI integration"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://orvunlabs.com/#website",
      "name": "Orvun Labs",
      "url": "https://orvunlabs.com",
      "inLanguage": [
        "en",
        "es",
        "de",
        "fr",
        "pt",
        "ja",
        "hi",
        "ar",
        "id",
        "tr",
        "pl"
      ],
      "publisher": {
        "@id": "https://orvunlabs.com/#organization"
      }
    },
    {
      "@type": "WebPage",
      "@id": "https://orvunlabs.com/en/journal/saas-tenant-data-isolation#webpage",
      "url": "https://orvunlabs.com/en/journal/saas-tenant-data-isolation",
      "name": "Separating customer data in a multi-tenant SaaS",
      "description": "Tenant isolation is a boundary to design and verify, not a field added to a table at the end.",
      "inLanguage": "en",
      "isPartOf": {
        "@id": "https://orvunlabs.com/#website"
      },
      "about": {
        "@id": "https://orvunlabs.com/#organization"
      },
      "breadcrumb": {
        "@id": "https://orvunlabs.com/en/journal/saas-tenant-data-isolation#breadcrumb"
      }
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://orvunlabs.com/en/journal/saas-tenant-data-isolation#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Orvun Labs",
          "item": "https://orvunlabs.com/en"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "Separating customer data in a multi-tenant SaaS",
          "item": "https://orvunlabs.com/en/journal/saas-tenant-data-isolation"
        }
      ]
    },
    {
      "@type": "BlogPosting",
      "headline": "Separating customer data in a multi-tenant SaaS",
      "description": "Tenant isolation is a boundary to design and verify, not a field added to a table at the end.",
      "datePublished": "2026-09-13T09:00:00.000Z",
      "dateModified": "2026-09-13T09:00:00.000Z",
      "inLanguage": "en",
      "author": {
        "@id": "https://orvunlabs.com/#organization"
      },
      "publisher": {
        "@id": "https://orvunlabs.com/#organization"
      },
      "image": [
        "https://orvunlabs.com/images/blog/saas.svg"
      ],
      "mainEntityOfPage": {
        "@id": "https://orvunlabs.com/en/journal/saas-tenant-data-isolation#webpage"
      }
    }
  ]
}
```
