What is Multi-Tenancy? Definition & Architecture

What Multi-Tenancy Means in SaaS Architecture

Multi-tenancy is a software architecture in which a solution is used by multiple customers or organizational groups called tenants. A tenant is not the same as a user: one tenant commonly contains many users, roles, workspaces, or departments, and a user may belong to more than one tenant.

The definition does not require one application process or one shared database. Microsoft's multitenant architecture guidance treats compute, networking, storage, data, identity, messaging, deployment, governance, and cost as separate design areas. A solution can pool some components, partition others, and dedicate selected resources.

For an embedded analytics platform, the practical requirement is that every analytical request, cache entry, export, schedule, and administrative action stays within the approved tenant boundary.

Tenant, User, and Role Are Different Claims

Authentication answers who the user is. Tenant membership answers which organizations or accounts that user belongs to. Authorization answers what the user can do and which resources or data they may access within the selected tenant.

A trusted backend should derive tenant and role scope from server-side membership data. A browser-provided tenant ID, route parameter, dashboard filter, theme, or email domain can help select context, but it should not be the authority that grants access.

Hierarchical products may need several boundaries: partner, customer, workspace, department, project, or region. Define which level owns data and which roles can aggregate across descendants. “Supports multi-tenancy” is too broad to prove this model.

Multi-Tenant Topology Patterns for Shared and Dedicated Infrastructure

Pooled Application and Pooled Data

Tenants share application and data infrastructure, with tenant scope enforced in service and data layers. This can improve utilization and simplify uniform releases. It also raises the importance of correct policies, cache keys, quotas, and noisy-neighbor controls.

Pooled Application with Partitioned Data

The application is shared while data is separated by schema, database, account, bucket, partition, or encryption key. Routing becomes a security-sensitive control: the correct identity must resolve to the correct destination, and untrusted input must not override it.

Deployment Stamps or Dedicated Components

Groups of tenants can be assigned to separate deployment stamps, or selected tenants can receive dedicated compute and data resources. This can support scale, residency, customization, or isolation requirements. It introduces fleet management, version skew, capacity placement, backup, and migration work.

Hybrid Topology

Many real systems combine these patterns. For example, the control plane may be pooled, application compute stamped by region, standard tenants stored in shared databases, and regulated tenants assigned dedicated data stores. Document the boundary per component instead of applying one label to the whole system.

The headless BI guide covers API and semantic-layer boundaries, while the white-label analytics guide covers tenant-specific presentation. Neither branding nor API shape proves isolation.

Four Isolation Planes That Protect Tenant Boundaries

Identity Plane

Map authenticated subjects to memberships and roles. Test missing membership, deactivated accounts, changed roles, multiple memberships, support impersonation, service accounts, and expired sessions.

Routing Plane

Resolve the approved tenant to the correct workspace, deployment, database, schema, partition, or key. Test modified routes, identifiers, headers, tokens, and stale routing caches. Fail closed when routing metadata is unavailable or contradictory.

Data Plane

Enforce access with the controls appropriate to the topology: service authorization, model or workspace permissions, database grants, row-level and column controls, views, encryption keys, or separate stores. Access control across these layers is the subject of the embedded analytics security guide. Apply the same scope to direct links, drill paths, exports, schedules, search, and AI or agent tools.

Operations Plane

Prevent one tenant from consuming unbounded shared resources, expose tenant-aware monitoring and audit, and preserve isolation in backups, restores, logs, support tools, and incidents. A restore or troubleshooting workflow can cross boundaries even when live queries do not.

For implementation patterns, see embedded analytics security and multi-tenant analytics architecture.

Pooling Improves Utilization but Does Not Guarantee Lower Cost

Pooling can improve resource utilization and let a team deploy shared fixes consistently. It does not guarantee lower cost or effortless scale: isolation controls, capacity management, tenant-aware observability, migrations, and compliance can add substantial work.

Dedicated resources can reduce some shared-failure and noisy-neighbor risks. They do not automatically make the solution secure, because identity, authorization, operations, support, and supply-chain controls still matter. They can also increase fleet and upgrade complexity.

Choose topology from requirements such as workload variability, data volume, residency, compliance, customization, recovery objectives, performance, blast radius, and cost, not from an assumption that every SaaS product should use one database pattern.

An Embedded Workflow Has to Prove the Complete Request Path

An embedded workflow should prove the complete request path:

1. Authenticate a user in the host product.
2. Resolve approved tenant membership and role in trusted services.
3. Issue or exchange a scoped, expiring credential.
4. Route to the correct analytics workspace and data resources.
5. Enforce permissions and data scope before query execution.
6. Carry the same scope into caches, exports, links, schedules, and audit.

The same dashboard definition can render different permitted results for different tenants. That is one useful pattern, not the definition of multi-tenancy. Some products legitimately maintain separate definitions or workspaces because customers have different schemas, contracts, versions, or customization.

Pooled Infrastructure Means One Tenant's Query Is Another Tenant's Latency

Isolation planes describe who may reach what. They say nothing about who slows down whom, and on pooled infrastructure that is a separate problem with separate controls.

An authorised query can still consume shared capacity: a customer exporting three years of detail, a scheduled report landing at the same minute for every tenant, or one account whose data volume is an order of magnitude larger than the median. None of that is a security failure and all of it is felt by everyone else as the product being slow.

The controls are ordinary once the problem is named: per-tenant limits on concurrency and result size, timeouts that fail a query rather than a page, scheduled work spread rather than aligned to the hour, and a queue that cannot let one tenant occupy every worker.

Without Per-Tenant Attribution You Can Neither Diagnose Nor Price

Pooling makes the infrastructure cheaper and the accounting harder. If queries, storage, and compute carry no tenant identifier through to your observability, then two questions become unanswerable: which customer is responsible for a load spike, and what does serving any particular customer actually cost.

The second one matters commercially. A usage-based or tiered price set without per-tenant cost data is a guess, and the accounts that lose money are invisible inside an average. Carry the tenant identifier through logs, traces, query metadata and billing records from the start, because adding it retroactively means instrumenting paths that are already in production.

Related Multi-Tenancy Concepts and Security Guides

• Headless BI guide: the metrics layer underneath all of this, and what each exposure route leaves you owning.

• White-label analytics, for tenant-specific product identity

• Embedded analytics guide, for the delivery model this architecture serves

• Embedded analytics security, for the enforcement mechanisms and where each one sits

• Customization past the logo, for what per-tenant branding has to reach