Multi-Tenancy

Multi-tenancy is an architecture in which a single, shared platform serves multiple independent tenants — separate customers, business units, or applications — with each tenant logically isolated so that none can see or affect another. The tenants share the same underlying hardware and software, but each behaves as if it had a private system of its own.

The whole point is doing this safely and efficiently at once: one platform to buy, run and scale (rather than a separate silo per tenant), combined with strict isolation of each tenant's data, identity and namespace. Multi-tenancy is what lets a service provider host hundreds of customers on shared infrastructure, or an enterprise cleanly separate departments, without anyone's data leaking into anyone else's.

What multi-tenancy means

A tenant is a group of users and resources that belong together and must stay separate from everyone else — typically a customer, a department, or an application environment. Multi-tenancy isolates each tenant along several dimensions at once:

• Data and namespace. Each tenant has its own buckets and object namespace. Two tenants can even use the same object or bucket names without collision.
• Identity and access. Each tenant has its own accounts, users and credentials; one tenant's keys grant no access to another's data.
• Capacity and performance. Quotas and controls keep one tenant from exhausting the shared pool or starving others of throughput (the "noisy neighbor" problem).
• Management. Administrative scope is bounded, so a tenant admin manages only their own tenant.

Shared underneath, isolated on top: that combination is the defining feature of a multi-tenant system.

Multi-tenant vs. single-tenant

The alternative to multi-tenancy is single-tenancy, where each tenant gets its own dedicated instance of the platform.

• Single-tenant (dedicated). Maximum isolation and customization, and the smallest blast radius if something goes wrong — but higher cost, more hardware, and more instances to operate and patch.
• Multi-tenant (shared). Far greater efficiency and density: one platform serves everyone, capacity is pooled, and operations are centralized. The trade-off is that isolation must be enforced in software rather than by physical separation.

Most large-scale storage and cloud services are multi-tenant because the efficiency is decisive; the engineering effort then goes into making the logical isolation as strong as physical separation would have been.

How isolation is enforced

In object storage, tenant isolation is built primarily on identity and namespace controls:

• Accounts and IAM. Each tenant maps to its own account, with its own users, groups, roles and policies governing exactly what each identity may do.
• Separate namespaces and credentials. Buckets and access keys are scoped to the tenant, so requests are authenticated and authorized against that tenant alone.
• Quotas and QoS. Capacity limits and rate controls contain the noisy-neighbor effect and keep one tenant from consuming the whole pool.
• Per-tenant encryption. Separate keys — often customer-managed keys — ensure that even shared storage media yields nothing usable across tenant boundaries.
• Network and audit. Segmented endpoints and per-tenant logging complete the separation and provide accountability.

Who uses multi-tenancy, and why

Multi-tenancy is the default for anyone serving many consumers from shared infrastructure:

• Service providers offering storage-as-a-service or backup-as-a-service host many customers on one platform, with per-tenant metering and chargeback.
• Enterprises separate departments, subsidiaries or projects on a single system while keeping each one's data and access distinct.
• SaaS and platform teams give each customer or environment an isolated slice of a common backend.

The benefits are efficiency, density and simpler operations; the risks to manage are data leakage between tenants, the noisy-neighbor effect, and a larger blast radius — all of which the isolation controls above exist to contain.

Multi-tenancy and ARTESCA

ARTESCA is built for secure multi-tenancy through an AWS-compatible IAM model. Scality's documentation describes this model as ensuring "strong security and application compatibility with multi-tenancy for backup-as-a-service offerings."

In practice, each tenant is represented by its own accounts, with users, groups, roles and policies controlling access; buckets, namespaces and credentials are scoped per tenant, so two tenants can share the same pool and S3 endpoints yet remain completely invisible to one another. Identities can be local to ARTESCA or federated from an existing AD/LDAP directory, admin roles bound what each administrator can manage, and multi-factor authentication can be enforced. Combined with per-tenant customer-managed keys, this lets a provider or enterprise consolidate many tenants on one platform without compromising isolation or data sovereignty.

Multi-tenancy FAQs

What is the difference between multi-tenant and single-tenant?

In a single-tenant system, each tenant gets its own dedicated instance. In a multi-tenant system, many tenants share one instance but are logically isolated. Multi-tenancy is more efficient; single-tenancy offers the strongest physical separation.

Can tenants see each other's data in a multi-tenant system?

No — that is the entire point. Isolation of accounts, namespaces and credentials means each tenant can only access its own data, even though the underlying platform is shared.

What is a "noisy neighbor"?

A noisy neighbor is a tenant whose heavy usage degrades performance or consumes capacity that others need. Quotas and quality-of-service controls exist to contain this effect.

How is a tenant isolated in object storage?

Primarily through accounts and IAM: each tenant has its own account, users, roles and policies, plus separate buckets, credentials and often its own encryption keys.

Does ARTESCA support multi-tenancy?

Yes. ARTESCA provides secure multi-tenancy through an AWS-compatible IAM model of accounts, users, groups, roles and policies, designed for backup-as-a-service and multi-department deployments.