Implement Elasticsearch Multi-Tenancy with Indices or Clusters (2026)

You can achieve true multi-tenancy in Elasticsearch by either dedicating separate clusters to each tenant or by isolating tenants within a single cluster using indices.

Here’s a simple example of how you might structure data for two tenants, "tenantA" and "tenantB", within a single cluster using indices:

// Data for tenantA
PUT tenantA_logs/_doc/1
{
  "message": "User login successful",
  "user_id": "user123",
  "timestamp": "2023-10-27T10:00:00Z"
}

// Data for tenantB
PUT tenantB_logs/_doc/1
{
  "message": "Order placed",
  "customer_id": "cust456",
  "timestamp": "2023-10-27T10:05:00Z"
}

This approach involves creating distinct indices for each tenant. For instance, you might name your indices tenantA_logs, tenantB_logs, and so on. When a tenant queries for their data, they would target their specific index. This is straightforward and provides strong isolation.

However, if you have a large number of tenants, managing thousands of individual indices can become cumbersome. In such scenarios, you might use a single index per tenant type and include a tenant ID as a field within the documents.

PUT shared_logs/_doc/1
{
  "tenant_id": "tenantA",
  "message": "User login successful",
  "user_id": "user123",
  "timestamp": "2023-10-27T10:00:00Z"
}

PUT shared_logs/_doc/2
{
  "tenant_id": "tenantB",
  "message": "Order placed",
  "customer_id": "cust456",
  "timestamp": "2023-10-27T10:05:00Z"
}

To retrieve data for "tenantA" from this shared_logs index, your query would look like this:

GET shared_logs/_search
{
  "query": {
    "term": {
      "tenant_id": "tenantA"
    }
  }
}

This "shared index" approach is more scalable in terms of the number of tenants you can handle with fewer indices, but it requires careful management of access control to ensure tenants can only see their own data.

The decision between using separate clusters, separate indices per tenant, or a single index with a tenant ID field depends on your specific requirements for isolation, scalability, and operational complexity. Separate clusters offer the highest level of isolation but are the most resource-intensive. Separate indices provide good isolation and are manageable for a moderate number of tenants. The shared index approach is the most resource-efficient for a large number of tenants but demands robust security configurations.

When using the shared index approach, applying security measures is paramount. You can leverage Elasticsearch’s Role-Based Access Control (RBAC) to restrict access. For example, you could define a role for tenantA that grants read-only access to documents where the tenant_id field matches "tenantA". This is typically done by creating a role that includes a document_level_security clause.

PUT _security/role/tenantA_reader
{
  "cluster": ["monitor"],
  "indices": [
    {
      "names": ["shared_logs"],
      "privileges": ["read"],
      "field_security": {
        "except": ["_unknown_"]
      },
      "query": "{\"term\": {\"tenant_id\": \"tenantA\"}}"
    }
  ]
}

This role definition ensures that any user assigned this role can only query the shared_logs index and will only see documents where the tenant_id is "tenantA". Without this, a simple GET shared_logs/_search would expose all data to everyone with read access to the index.

The primary advantage of the separate indices approach is that it leverages Elasticsearch’s built-in index-level permissions. You can grant a user or role access to only tenantA_logs and nothing else. This is often simpler to manage from a security perspective than implementing document-level security across a shared index.

When it comes to indexing performance, the shared index approach can sometimes benefit from larger index sizes and fewer shards to manage, potentially leading to better overall throughput if sharding isn’t a bottleneck. However, it also means that a single noisy tenant could impact the performance for all other tenants sharing the index, as resource contention on CPU, memory, and I/O becomes more likely. With separate indices, a problem tenant is more contained to their own index’s shards.

The most surprising true thing about implementing multi-tenancy with a single index and document-level security is that the query performance for a tenant is often better than with separate indices, provided the tenant’s data volume is not excessively large. This is because Elasticsearch can perform more efficient segment merging and caching across fewer, larger indices, and the filtering happens at the Lucene segment level during the search phase rather than at the index selection phase.

Regardless of the chosen method, managing tenant lifecycle (creation, deletion, data retention) becomes a significant operational concern. Automating these processes through APIs or custom scripts is crucial for any production multi-tenant Elasticsearch deployment.

The next logical step after implementing a secure multi-tenancy strategy is to consider how to optimize search performance for individual tenants.