From 6d6030e802d335299967c3d5b365e7c8024878a7 Mon Sep 17 00:00:00 2001 From: ktalmor <193799742+ktalmor@users.noreply.github.com> Date: Sun, 10 May 2026 12:22:28 +0300 Subject: [PATCH 1/5] Update ADX multi-tenant to add Eventhouse support --- data-explorer/multi-tenant.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/data-explorer/multi-tenant.md b/data-explorer/multi-tenant.md index 9867ad755e..faeab1d13f 100644 --- a/data-explorer/multi-tenant.md +++ b/data-explorer/multi-tenant.md @@ -3,7 +3,7 @@ title: Comparing different multi-tenant solutions with Azure Data Explorer description: Learn about the different ways to architect a multi-tenant solution in Azure Data Explorer. ms.reviewer: vplauzon ms.topic: how-to -ms.date: 06/20/2023 +ms.date: 05/10/2026 --- # How to architect a multi-tenant solution with Azure Data Explorer @@ -15,6 +15,10 @@ An important factor is the way end-users access their tenant data. When end-user This article describes some deployment architectures and provides characteristics for each. You can use the characteristics to help you decide which architecture works best for your solution. +> [!IMPORTANT] +> +> A multi-tenant solution is also supported in Microsoft Fabric's [Real-Time Intelligence](/fabric/real-time-intelligence/overview), using KQL databases inside an [Eventhouse](/fabric/real-time-intelligence/eventhouse). + ## Noisy neighbor In general, sharing a cluster among many tenants, regardless of the architecture used, means different tenants share the cluster's resources. This can lead to the [noisy neighbor](/azure/architecture/antipatterns/noisy-neighbor/noisy-neighbor) antipattern. From 7f6f538108bfddcc1f9cd942c11142627e73a7cc Mon Sep 17 00:00:00 2001 From: ktalmor <193799742+ktalmor@users.noreply.github.com> Date: Sun, 10 May 2026 12:25:33 +0300 Subject: [PATCH 2/5] Update documentation via Content Mentor Quick Workspace --- data-explorer/multi-tenant.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/data-explorer/multi-tenant.md b/data-explorer/multi-tenant.md index faeab1d13f..5f26dfd656 100644 --- a/data-explorer/multi-tenant.md +++ b/data-explorer/multi-tenant.md @@ -9,16 +9,16 @@ ms.date: 05/10/2026 The concept of multi-tenancy in Azure Data Explorer refers to serving different tenants and storing their data in a single cluster. +> [!IMPORTANT] +> +> A multi-tenant solution is also supported in Microsoft Fabric's [Real-Time Intelligence](/fabric/real-time-intelligence/overview) workload, using KQL databases inside an [Eventhouse](/fabric/real-time-intelligence/eventhouse). + A *tenant* can represent a customer, a group of users, or any classifications of users where data needs to be segregated along the tenants' boundaries. You can also have multi-level multi-tenancy scenario, such as multiple applications that each have multiple tenants. This scenario isn't covered by this article but similar principles apply. An important factor is the way end-users access their tenant data. When end-users access Azure Data Explorer directly, access control must be configured in Azure Data Explorer to isolate the user's view to their own data. When a proxy application accesses their data in Azure Data Explorer, the application can do the isolation. This article describes some deployment architectures and provides characteristics for each. You can use the characteristics to help you decide which architecture works best for your solution. -> [!IMPORTANT] -> -> A multi-tenant solution is also supported in Microsoft Fabric's [Real-Time Intelligence](/fabric/real-time-intelligence/overview), using KQL databases inside an [Eventhouse](/fabric/real-time-intelligence/eventhouse). - ## Noisy neighbor In general, sharing a cluster among many tenants, regardless of the architecture used, means different tenants share the cluster's resources. This can lead to the [noisy neighbor](/azure/architecture/antipatterns/noisy-neighbor/noisy-neighbor) antipattern. From b7e7a295580d3e19d9b004fd2669c520943ae3c9 Mon Sep 17 00:00:00 2001 From: ktalmor <193799742+ktalmor@users.noreply.github.com> Date: Sun, 10 May 2026 12:31:45 +0300 Subject: [PATCH 3/5] Update documentation via Content Mentor Quick Workspace --- data-explorer/multi-tenant.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/data-explorer/multi-tenant.md b/data-explorer/multi-tenant.md index 5f26dfd656..724e5d9363 100644 --- a/data-explorer/multi-tenant.md +++ b/data-explorer/multi-tenant.md @@ -11,7 +11,7 @@ The concept of multi-tenancy in Azure Data Explorer refers to serving different > [!IMPORTANT] > -> A multi-tenant solution is also supported in Microsoft Fabric's [Real-Time Intelligence](/fabric/real-time-intelligence/overview) workload, using KQL databases inside an [Eventhouse](/fabric/real-time-intelligence/eventhouse). +> A multi-tenant solution can also be architected in Microsoft Fabric's [Real-Time Intelligence](/fabric/real-time-intelligence/overview) workload, using KQL databases inside an [Eventhouse](/fabric/real-time-intelligence/eventhouse). A *tenant* can represent a customer, a group of users, or any classifications of users where data needs to be segregated along the tenants' boundaries. You can also have multi-level multi-tenancy scenario, such as multiple applications that each have multiple tenants. This scenario isn't covered by this article but similar principles apply. From b4504867c821ceb280781c9da8301f8899f28a4d Mon Sep 17 00:00:00 2001 From: ktalmor <193799742+ktalmor@users.noreply.github.com> Date: Mon, 11 May 2026 11:56:52 +0300 Subject: [PATCH 4/5] change all narrative-text occurrences of multi-tenant to multitenant (delete the hyphen) --- .github/agents/blogs.agent.md | 2 +- .../materialized-view-policies.md | 2 +- .../management/row-level-security-policy.md | 2 +- data-explorer/managed-identities-overview.md | 2 +- data-explorer/multi-tenant.md | 22 +++++++++---------- data-explorer/purview.md | 2 +- 6 files changed, 16 insertions(+), 16 deletions(-) diff --git a/.github/agents/blogs.agent.md b/.github/agents/blogs.agent.md index 8578fee121..076ecb0492 100644 --- a/.github/agents/blogs.agent.md +++ b/.github/agents/blogs.agent.md @@ -71,7 +71,7 @@ Take into account the following structures: - Problem/scenario (2-3 paragraphs): What challenges does this address? - How it works (2-4 paragraphs): Explain the feature's functionality - Use cases (2-3 scenarios): Specific examples of when to use this feature - - Multi-tenant environments + - Multitenant environments - Department-based access - Role-based permissions - Compliance requirements diff --git a/data-explorer/kusto/management/materialized-views/materialized-view-policies.md b/data-explorer/kusto/management/materialized-views/materialized-view-policies.md index ab06d3a8e7..67c9254a05 100644 --- a/data-explorer/kusto/management/materialized-views/materialized-view-policies.md +++ b/data-explorer/kusto/management/materialized-views/materialized-view-policies.md @@ -30,7 +30,7 @@ The retention and caching policies both depend on [Extent Creation time](../exte ## Partitioning policy -A [partitioning policy](../partitioning-policy.md) can be applied on a materialized view. We recommend configuring a partitioning policy on a materialized view only when most or all of the view queries filter by one of the materialized view's group-by keys. This situation is common in multi-tenant solutions, where one of the materialized view's group-by keys is the tenant's identifier (for example, `tenantId`, `customerId`). For more information, see the first use case described in the [partitioning policy supported scenarios](../partitioning-policy.md#supported-scenarios) page. +A [partitioning policy](../partitioning-policy.md) can be applied on a materialized view. We recommend configuring a partitioning policy on a materialized view only when most or all of the view queries filter by one of the materialized view's group-by keys. This situation is common in multitenant solutions, where one of the materialized view's group-by keys is the tenant's identifier (for example, `tenantId`, `customerId`). For more information, see the first use case described in the [partitioning policy supported scenarios](../partitioning-policy.md#supported-scenarios) page. For the commands to alter a materialized view's partitioning policy, see [partitioning policy commands](../show-table-partitioning-policy-command.md). diff --git a/data-explorer/kusto/management/row-level-security-policy.md b/data-explorer/kusto/management/row-level-security-policy.md index 302b91ed59..def4fd723b 100644 --- a/data-explorer/kusto/management/row-level-security-policy.md +++ b/data-explorer/kusto/management/row-level-security-policy.md @@ -174,7 +174,7 @@ For example: * Set an RLS policy that masks personally identifiable information (PII), and enables developers to query production environments for troubleshooting purposes without violating compliance regulations. * A hospital can set an RLS policy that allows nurses to view data rows for their patients only. * A bank can set an RLS policy to restrict access to financial data rows based on an employee's business division or role. -* A multi-tenant application can store data from many tenants in a single tableset (which is efficient). They would use an RLS policy to enforce a logical separation of each tenant's data rows from every other tenant's rows, so each tenant can see only its data rows. +* A multitenant application can store data from many tenants in a single tableset (which is efficient). They would use an RLS policy to enforce a logical separation of each tenant's data rows from every other tenant's rows, so each tenant can see only its data rows. ## Performance impact on queries diff --git a/data-explorer/managed-identities-overview.md b/data-explorer/managed-identities-overview.md index 13a53965c2..0e01e63644 100644 --- a/data-explorer/managed-identities-overview.md +++ b/data-explorer/managed-identities-overview.md @@ -21,7 +21,7 @@ Your Azure Data Explorer cluster can be granted two types of identities: Single-tenant Microsoft Entra resources can only use managed identities to communicate with resources in the same tenant. This limitation restricts the use of managed identities in certain authentication scenarios. For example, you can't use an Azure Data Explorer managed identity to access an event hub located in a different tenant. In such cases, use account-key based authentication. -Azure Data Explorer is multi-tenant capable, which means that you can grant access to managed identities from different tenants. To accomplish this, assign the relevant [security roles](/kusto/management/security-roles). When assigning the roles, refer to the managed identity as described in [Referencing security principals](/kusto/management/reference-security-principals?view=azure-data-explorer&preserve-view=true#referencing-azure-ad-principals-and-groups). +Azure Data Explorer is multitenant capable, which means that you can grant access to managed identities from different tenants. To accomplish this, assign the relevant [security roles](/kusto/management/security-roles). When assigning the roles, refer to the managed identity as described in [Referencing security principals](/kusto/management/reference-security-principals?view=azure-data-explorer&preserve-view=true#referencing-azure-ad-principals-and-groups). To authenticate with managed identities, follow these steps: diff --git a/data-explorer/multi-tenant.md b/data-explorer/multi-tenant.md index 724e5d9363..461b7ef8e0 100644 --- a/data-explorer/multi-tenant.md +++ b/data-explorer/multi-tenant.md @@ -1,17 +1,17 @@ --- -title: Comparing different multi-tenant solutions with Azure Data Explorer -description: Learn about the different ways to architect a multi-tenant solution in Azure Data Explorer. +title: Comparing different multitenant solutions with Azure Data Explorer +description: Learn about the different ways to architect a multitenant solution in Azure Data Explorer. ms.reviewer: vplauzon ms.topic: how-to -ms.date: 05/10/2026 +ms.date: 05/11/2026 --- -# How to architect a multi-tenant solution with Azure Data Explorer +# How to architect a multitenant solution with Azure Data Explorer The concept of multi-tenancy in Azure Data Explorer refers to serving different tenants and storing their data in a single cluster. > [!IMPORTANT] > -> A multi-tenant solution can also be architected in Microsoft Fabric's [Real-Time Intelligence](/fabric/real-time-intelligence/overview) workload, using KQL databases inside an [Eventhouse](/fabric/real-time-intelligence/eventhouse). +> A multitenant solution can also be architected in Microsoft Fabric's [Real-Time Intelligence](/fabric/real-time-intelligence/overview) workload, using KQL databases inside an [Eventhouse](/fabric/real-time-intelligence/eventhouse). A *tenant* can represent a customer, a group of users, or any classifications of users where data needs to be segregated along the tenants' boundaries. You can also have multi-level multi-tenancy scenario, such as multiple applications that each have multiple tenants. This scenario isn't covered by this article but similar principles apply. @@ -37,7 +37,7 @@ The next sections explore deployment architectures in detail. This section cont ## Architecture: One tenant per database -:::image type="content" source="media/multi-tenant/one-tenant-per-db.png" alt-text="Diagram showing the architecture for one tenant per database."::: +:::image type="content" source="media/multitenant/one-tenant-per-db.png" alt-text="Diagram showing the architecture for one tenant per database."::: This is a popular and straight forward architecture. Each tenant gets its own database. Each database has the same schema. @@ -52,7 +52,7 @@ The characteristics of this architecture are: * **Retention and caching policies**: Each tenant can have its own unique policies, which enable you to provide custom retention and caching policies to your customers. * **Security boundary per tenant**: - * For multi-tenant application (proxy): Configure your application to target the relevant database. Use [access restriction](/kusto/query/cross-cluster-or-database-queries?view=azure-data-explorer&preserve-view=true#qualified-names-and-restrict-access-statements) on queries to prohibit [cross-database queries](/kusto/query/cross-cluster-or-database-queries?view=azure-data-explorer&preserve-view=true). + * For multitenant application (proxy): Configure your application to target the relevant database. Use [access restriction](/kusto/query/cross-cluster-or-database-queries?view=azure-data-explorer&preserve-view=true#qualified-names-and-restrict-access-statements) on queries to prohibit [cross-database queries](/kusto/query/cross-cluster-or-database-queries?view=azure-data-explorer&preserve-view=true). * For users with direct access: Users can be granted access at the [database level](/kusto/access-control/role-based-access-control?view=azure-data-explorer&preserve-view=true). Giving users direct access to their database creates a dependency for the implementation details, making it difficult to change the implementation. Therefore, we strongly recommend using the proxy approach for accessing the database. * **Aggregating data from multiple tenants at scale**: Use the [union operator](/kusto/query/union-operator?view=azure-data-explorer&preserve-view=true) to aggregate data between databases. However, this method can become cumbersome as the number of tenants increases. Even though aggregating data from multiple tenants might be a design goal from the tenant's perspective, it might be of interest for solution owner to aggregate data from all tenants to gather statistics. @@ -65,7 +65,7 @@ The characteristics of this architecture are: ## Architecture: One table for many tenants -:::image type="content" source="media/multi-tenant/one-db-for-many-tenants.png" alt-text="Diagram showing the architecture for one database for many tenants."::: +:::image type="content" source="media/multitenant/one-db-for-many-tenants.png" alt-text="Diagram showing the architecture for one database for many tenants."::: This architecture is more aggressive in its consolidation, using a single database for all tenants. Each table in the database has a **Tenant ID** column, or equivalent, which allows for filtering for a single tenant's data. You can [partition](/kusto/management/partitioning-policy?view=azure-data-explorer&preserve-view=true) tables by tenant to improve query performance, since most queries are likely to filter by tenant. Where possible, you should consider partition with another column using a *compound* partition key. For example, you can create a *compound* partition key concatenating the **tenant ID** and another columns' values. @@ -82,20 +82,20 @@ The characteristics of this architecture are: * **Retention and caching policies**: The policies are the same for all tenants since they all share the same table. * **Security boundary per tenant**: - * For multi-tenant application (proxy): Use the [Restrict statement](/kusto/query/restrict-statement?view=azure-data-explorer&preserve-view=true) + * For multitenant application (proxy): Use the [Restrict statement](/kusto/query/restrict-statement?view=azure-data-explorer&preserve-view=true) * For users with direct access: Use the [Row Level Security Policy](/kusto/management/row-level-security-policy) and familiarize yourself with its [limitations](/kusto/management/row-level-security-policy?view=azure-data-explorer&preserve-view=true#limitations). Giving users direct access to their database creates a dependency for the implementation details, making it difficult to change the implementation. Therefore, we strongly recommend using the proxy approach for accessing the database. * **Aggregating data from multiple tenants at scale**: Users with the sufficient access permissions can run a standard aggregation query on multiple tenants' data. * **Extents fragmentation**: Since all tenants ingest data into the same table, data can usually be consolidated and efficiently ingested in one, or a few, extents. -* **Materialized views and partitioning policy**: These can be used on multi-tenant table. You can improve performance by partitioning on the **Tenant ID**, or equivalent, column. For more information, see [Scenarios for partition policies](/kusto/management/partitioning-policy?view=azure-data-explorer&preserve-view=true#supported-scenarios). +* **Materialized views and partitioning policy**: These can be used on multitenant table. You can improve performance by partitioning on the **Tenant ID**, or equivalent, column. For more information, see [Scenarios for partition policies](/kusto/management/partitioning-policy?view=azure-data-explorer&preserve-view=true#supported-scenarios). * **Event Grid and Event Hubs data connections**: You consolidated data connections since data for all tenants ends up in one table. ## Architecture: One tenant per table in a single database -:::image type="content" source="media/multi-tenant/one-tenant-per-table.png" alt-text="Diagram showing the architecture for one tenant per table."::: +:::image type="content" source="media/multitenant/one-tenant-per-table.png" alt-text="Diagram showing the architecture for one tenant per table."::: This architecture is a combination of the previous architectures where the data of all tenants ends up in a single database but separate tables. This architecture fails to capture all the advantages of the other architectures. diff --git a/data-explorer/purview.md b/data-explorer/purview.md index 081df7298d..5d4d53866f 100644 --- a/data-explorer/purview.md +++ b/data-explorer/purview.md @@ -25,7 +25,7 @@ For information on how to connect to Azure Data Explorer in Purview, see the fol The following section describes an example use case for integrating Azure Data Explorer with Purview. -### View resource properties in multi-tenant deployment +### View resource properties in multitenant deployment In Purview, you can configure scans on multiple clusters to gain insights into various cluster resources and their properties. This feature allows you to easily move between scans and get a summary of different cluster resources. For example, you can identify which databases are located in specific regions across multiple clusters. From b4ab33f87b0165e6faa8d95ce3026169e9ad93ae Mon Sep 17 00:00:00 2001 From: ktalmor <193799742+ktalmor@users.noreply.github.com> Date: Mon, 11 May 2026 12:05:42 +0300 Subject: [PATCH 5/5] media folder name change --- .../one-db-for-many-tenants.png | Bin .../one-tenant-per-db.png | Bin .../one-tenant-per-table.png | Bin data-explorer/multi-tenant.md | 2 +- 4 files changed, 1 insertion(+), 1 deletion(-) rename data-explorer/media/{multi-tenant => multitenant}/one-db-for-many-tenants.png (100%) rename data-explorer/media/{multi-tenant => multitenant}/one-tenant-per-db.png (100%) rename data-explorer/media/{multi-tenant => multitenant}/one-tenant-per-table.png (100%) diff --git a/data-explorer/media/multi-tenant/one-db-for-many-tenants.png b/data-explorer/media/multitenant/one-db-for-many-tenants.png similarity index 100% rename from data-explorer/media/multi-tenant/one-db-for-many-tenants.png rename to data-explorer/media/multitenant/one-db-for-many-tenants.png diff --git a/data-explorer/media/multi-tenant/one-tenant-per-db.png b/data-explorer/media/multitenant/one-tenant-per-db.png similarity index 100% rename from data-explorer/media/multi-tenant/one-tenant-per-db.png rename to data-explorer/media/multitenant/one-tenant-per-db.png diff --git a/data-explorer/media/multi-tenant/one-tenant-per-table.png b/data-explorer/media/multitenant/one-tenant-per-table.png similarity index 100% rename from data-explorer/media/multi-tenant/one-tenant-per-table.png rename to data-explorer/media/multitenant/one-tenant-per-table.png diff --git a/data-explorer/multi-tenant.md b/data-explorer/multi-tenant.md index 461b7ef8e0..301c4a1ea7 100644 --- a/data-explorer/multi-tenant.md +++ b/data-explorer/multi-tenant.md @@ -73,7 +73,7 @@ The characteristics of this architecture are: * **Provisioning a new tenant**: Provisioning a new tenant doesn't require any database creation or schema adjustment. The new **tenant ID** is used in new records. -* **Removing a tenant**: Requires a [soft delete](/kusto/concepts/data-soft-delete?view=azure-data-explorer&preserve-view=true) or [purge](/kusto/concepts/data-purge?view=azure-data-explorer&preserve-view=true) of the tenant's data. The former is more efficient, while the latter supports GDPR obligations. You can batch multiple purges together, for example, at the end of week to limit the impact on resource consumption. +* **Removing a tenant**: Requires a [soft delete](/kusto/concepts/data-soft-delete?view=azure-data-explorer&preserve-view=true) or [purge](/kusto/concepts/data-purge?view=azure-data-explorer&preserve-view=true) of the tenant's data. A soft delete is more efficient, while purge supports GDPR obligations. You can batch multiple purges together, for example, at the end of week to limit the impact on resource consumption. [!INCLUDE [gdpr-intro-sentence](includes/gdpr-intro-sentence.md)]