Design patterns for multitenant SaaS applications and Azure AI Search

A multitenant application is one that provides the same services and capabilities to any number of tenants who can't see or share the data of any other tenant. This article discusses tenant isolation strategies for multitenant applications built with Azure AI Search.

Azure AI Search concepts

As a search-as-a-service solution, Azure AI Search allows developers to add rich search experiences to applications without managing any infrastructure or becoming an expert in information retrieval. Data is uploaded to the service and then stored in the cloud. Using simple requests to the Azure AI Search API, the data can then be modified and searched.

Search services, indexes, fields, and documents

Before discussing design patterns, it's important to understand a few basic concepts.

An Azure AI Search service contains one or more indexes. Each index is an independent searchable data structure with its own schema. The index schema defines the fields and search behaviors for the content. You load data into an index as documents that conform to the index's schema.

Indexing and query operations target a single index. When an application submits a query, Azure AI Search searches the selected index and returns matching documents. The schema uses the field data types supported by Azure AI Search. When tenants share an index, their documents must fit the same schema.

Scalability and service-managed partitioning

In the Dedicated pricing model, an Azure AI Search service scales in two dimensions:

• Add partitions to increase storage and indexing capacity.
• Add replicas to increase query throughput and availability.

Azure AI Search distributes the documents in each index across service partitions. Service partitions are capacity units, not tenant-isolation boundaries. You don't provide a custom partition key or control the placement of documents on service partitions. When you add partitions or replicas, you change the capacity of the entire service, which is shared by all indexes in that service.

Choose a pricing tier and capacity based on projected aggregate and per-tenant storage, indexing, and query workloads. The tier sets service, index, document, and storage limits. For more information, see Estimate and manage capacity and Service limits in Azure AI Search.

For a Dedicated service to qualify for the availability SLA, configure at least two replicas for query-only workloads or three replicas for workloads that include indexing. Partitions don't affect SLA eligibility.

Service and index limits in Azure AI Search

Azure AI Search offers several pricing tiers, with different limits and quotas. Some limits apply to the service, while others apply to indexes or partitions.

S3 High Density

Standard 3 High Density (S3 HD) is a hosting mode suitable for multitenant scenarios that require many small indexes in one search service. It can reduce the per-tenant cost and operational overhead when an index-per-tenant model serves a large number of smaller tenants.

S3 HD supports substantially more indexes than other Dedicated tiers. Adding partitions increases the number of indexes that the service can host, but each index has a fixed maximum size. Review the current S3 HD index, feature, and indexer limits before you select this mode. For more information, see Service limits in Azure AI Search.

Considerations for multitenant applications

Multitenant applications must effectively distribute resources among the tenants while preserving some level of privacy between the various tenants. There are a few considerations when designing the architecture for such an application:

• Tenant isolation: Application developers need to take appropriate measures to ensure that no tenants have unauthorized or unwanted access to the data of other tenants. Beyond the perspective of data privacy, tenant isolation strategies require effective management of shared resources and protection from noisy neighbors.

• Cloud resource cost: As with any other application, software solutions must remain cost competitive as a component of a multitenant application.

• Ease of Operations: When developing a multitenant architecture, the impact on the application's operations and complexity is an important consideration. Azure AI Search has a 99.9% SLA.

• Global footprint: Multitenant applications often need to serve tenants who are distributed across the globe. Plan how regional placement, data synchronization, and request routing affect each tenancy model. For more information, see Multi-region deployments in Azure AI Search.

• Scalability: Application developers need to consider how they reconcile between maintaining a sufficiently low level of application complexity and designing the application to scale with number of tenants and the size of tenants' data and workload.

Azure AI Search offers a few boundaries that can be used to isolate tenants’ data and workload.

Modeling multitenancy with Azure AI Search

In the case of a multitenant scenario, the application developer consumes one or more search services and divides their tenants among services, indexes, or both. Azure AI Search has a few common patterns when modeling a multitenant scenario:

• One index per tenant: Each tenant has its own index within a search service that is shared with other tenants.

• One service per tenant: Each tenant has its own dedicated Azure AI Search service, offering highest level of data and workload separation.

• Mix of both: Larger, more-active tenants are assigned dedicated services while smaller tenants are assigned individual indexes within shared services.

• One index for multiple tenants: Multiple tenants share an index, and each document includes a tenant identifier that the application uses to filter results.

Model 1: One index per tenant

In an index-per-tenant model, multiple tenants occupy a single Azure AI Search service where each tenant has their own index.

All search requests and document operations target an index. However, the index name in a request isn't an authorization boundary. If tenants connect directly to Azure AI Search, use index-scoped roles to restrict each tenant to its own index. Otherwise, route requests through a trusted application tier that derives the tenant's index from the authenticated context and prevents callers from selecting another tenant's index. Don't provide tenants with API keys for a shared service because API keys grant service-level access.

A key attribute of the index-per-tenant model is the ability for the application developer to oversubscribe the capacity of a search service among the application’s tenants. If the tenants have an uneven distribution of workload, the optimal combination of tenants can be distributed across a search service’s indexes to accommodate a number of highly active, resource-intensive tenants while simultaneously serving a long tail of less active tenants. The trade-off is the inability of the model to handle situations where each tenant is concurrently highly active.

The index-per-tenant model provides the basis for a variable cost model, where an entire Azure AI Search service is bought up-front and then subsequently filled with tenants. This allows for unused capacity to be designated for trials and free accounts.

For applications with a global footprint, the index-per-tenant model might not be the most efficient. If an application's tenants are distributed across the globe, you might need a separate shared service in each region, which duplicates capacity and increases operational complexity. For more information, see Multi-region deployments in Azure AI Search.

Azure AI Search allows for the scale of both the individual indexes and the total number of indexes to grow. If an appropriate pricing tier is chosen, partitions and replicas can be added to the entire search service when an individual index within the service grows too large in terms of storage or traffic.

If the total number of indexes grows too large for a single service, another service has to be provisioned to accommodate the new tenants. If indexes have to be moved between search services as new services are added, the data from the index has to be manually copied from one index to the other as Azure AI Search doesn't allow for an index to be moved.

Model 2: One service per tenant

In a service-per-tenant architecture, each tenant has its own search service.

In this model, the application achieves the maximum level of isolation for its tenants. Each service has dedicated storage and throughput for handling search requests. Use Microsoft Entra authentication and role-based access control to authorize application components and operators. If tenant users access search through an application tier, keep service credentials in that tier and enforce tenant-to-service routing there. API keys provide service-level access and aren't tenant-aware authorization boundaries.

Each search service counts against the service limit for its tier, subscription, and region. Before you adopt this model at scale, estimate the required number of services and plan for quota increases, regional distribution, or multiple Azure subscriptions.

For applications where each tenant has a large footprint or the workload has little variability from tenant to tenant, the service-per-tenant model is an effective choice as resources aren't shared across various tenants’ workloads.

A service per tenant model also offers the benefit of a predictable, fixed cost model. There's no up-front investment in an entire search service until there's a tenant to fill it, however the cost-per-tenant is higher than an index-per-tenant model.

The service-per-tenant model can support applications with a global footprint because each tenant's service can be placed in a region appropriate to that tenant. A search service is a single-region resource, so use separate regional deployments if you also require resilience to a regional outage. For more information, see Multi-region deployments in Azure AI Search.

The challenges in scaling this pattern arise when individual tenants outgrow their service. Existing services can switch between Basic and Standard S1, S2, and S3 tiers if the current configuration fits within the target tier's limits and the region has capacity. To move to another tier, create a new service and reload or copy the index content. For more information, see Change your pricing tier.

Model 3: Hybrid

Another pattern for modeling multitenancy is mixing both index-per-tenant and service-per-tenant strategies.

By mixing the two patterns, an application's largest tenants can occupy dedicated services while the long tail of less active, smaller tenants can occupy indexes in a shared service. This model ensures that the largest tenants have consistently high performance from the service while helping to protect the smaller tenants from any noisy neighbors.

However, implementing this strategy relies on foresight in predicting which tenants will require a dedicated service versus an index in a shared service. Application complexity increases with the need to manage both of these multitenancy models.

Maintain a tenant-placement catalog that maps each tenant to its search service and index. Use the catalog to route requests, and automate service and index provisioning. When you move a tenant, coordinate data synchronization and routing updates, and plan how to handle stale mappings, failed cutovers, and rollback.

Model 4: One index for multiple tenants

In a shared-index model, documents from multiple tenants use the same index and schema. This model provides the highest tenant density, but it offers less data and performance isolation than the other models. All tenants share index capacity, schema, and relevance-scoring behavior.

To isolate tenants within one index, add a filterable field that identifies the tenant that owns each document. A trusted application layer must derive the tenant identifier from authenticated context and apply the corresponding filter to every query. Don't accept a tenant identifier supplied by an untrusted client. For document uploads, updates, and deletions, validate that the operation is authorized for the document's tenant. For more information, see Security filters for trimming results.

Use this model when tenant density and cost efficiency are more important than tenant-specific schemas or strong workload isolation, and when the application can reliably enforce tenant filters on every operation.

Next steps

Azure AI Search is a compelling choice for many applications. When evaluating the various design patterns for multitenant applications, consider the various pricing tiers and the respective service limits to best tailor Azure AI Search to fit application workloads and architectures of all sizes.

Read this article together with Architectural approaches for storage and data in multitenant solutions, which describes general considerations and approaches that apply across data services.