Share via

How to Identify Unique Database Services Across Multiple Azure Subscriptions

Selvam Sekar 100 Reputation points
2026-05-06T16:26:12.69+00:00

Hi everyone,

I’m looking for guidance on how to analyze database usage across a large Azure environment.

Scenario

We currently manage 100+ Azure subscriptions, and we want to understand the types of database services being used across all these subscriptions.

Requirement

Our goal is not to count individual database instances. Instead, we want to identify unique database service types being consumed.

For example, we want an output like:

Azure SQL Database

Azure Database for PostgreSQL

Azure Cosmos DB

(any other database service in use)

So essentially, we are trying to answer:

“What different database services are in use across all subscriptions?”

What We Don’t Need

Total number of SQL servers or databases

Instance-level counts

Resource-level inventory

What We Need

A consolidated view of unique DB service types across all subscriptions

Ideally aggregated at a tenant or management group level

Ask

What is the best way to achieve this in Azure?

Some approaches I’m considering:

Azure Resource Graph queries

Azure CLI / PowerShell scripts

Azure Policy or tagging strategy

But I’m not sure what would be the most efficient and scalable approach for this use case.

Thanks,

Selvam.

Azure Monitor
Azure Monitor

An Azure service that is used to collect, analyze, and act on telemetry data from Azure and on-premises environments.

Answer accepted by question author

AI answer

2026-05-06T16:26:25+00:00

Use Azure Resource Graph to query all subscriptions in the tenant and return the distinct database-related resource types. This is efficient and scalable because Resource Graph is designed for cross-subscription inventory and supports tenant/management group scope.

A practical approach is:

  1. In Azure Resource Graph (via Azure CLI, PowerShell, or Portal), query the Resources table.
  2. Filter on known database-related resource types (for example, Azure SQL Database, Azure Database for PostgreSQL, Azure Cosmos DB, etc.).
  3. Project only the type field and use distinct to get the unique service types.

Example Kusto query pattern (simplified):

Resources
| where type in~ (
    'microsoft.sql/servers/databases',
    'microsoft.sql/servers',
    'microsoft.documentdb/databaseaccounts',
    'microsoft.dbforpostgresql/servers',
    'microsoft.dbformysql/servers',
    'microsoft.dbforpostgresql/flexibleservers',
    'microsoft.dbformysql/flexibleservers'
)
| summarize by type

Run this at:

  • Tenant or management group scope (via Azure CLI az graph query, Azure PowerShell Search-AzGraph, or Azure Portal → Resource Graph Explorer) to cover all 100+ subscriptions.
  • The result is a list of unique type values, which correspond to the different database services in use.

If only a high-level list is needed (for example, “Azure SQL Database”, “Azure Cosmos DB”), map each type to its product name after the query (for example, microsoft.documentdb/databaseaccounts → Azure Cosmos DB).

This method avoids counting instances and focuses purely on the distinct service types, while remaining scalable across large environments.

References:

AI-generated content may be incorrect. Read our transparency notes for more information.

Was this answer helpful?

1 person found this answer helpful.

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Suchitra Suregaunkar 14,420 Reputation points Microsoft External Staff Moderator
    2026-05-06T17:50:51.37+00:00

    Hello Selvam Sekar

    The most efficient and scalable way to identify unique database service types across 100+ subscriptions is Azure Resource Graph. It queries a pre-built resource index (not live ARM API calls), so it returns results in seconds — even at massive scale without throttling concerns.

    You can run these queries from the Azure portal (Resource Graph Explorer), Azure CLI, or Azure PowerShell.

    Option 1 — Azure Portal (Resource Graph Explorer)

    1. Go to the Azure portal → search for Resource Graph Explorer.
    2. Set the scope to your Tenant or Management Group (top-left dropdown).
    3. Run the following KQL query: 
    Resources
| where type contains "sql"
    or type contains "cosmos"
    or type contains "documentdb"
    or type contains "postgresql"
    or type contains "mysql"
    or type contains "mariadb"
    or type contains "redis"
    or type contains "cache"
    or type contains "kusto"
| distinct type
| order by type asc

    This will return only the unique database-related resource types actually deployed across all your subscriptions no instance counts, no resource-level inventory, just the distinct service types.

    Option 2 — Azure CLI

    First, ensure the Resource Graph extension is installed:

    az extension add --name resource-graph

    Then run:

    az graph query -q "Resources | where type contains 'sql' or type contains 'cosmos' or type contains 'documentdb' or type contains 'postgresql' or type contains 'mysql' or type contains 'mariadb' or type contains 'redis' or type contains 'cache' or type contains 'kusto' | distinct type | order by type asc" --output table

    By default, az graph query runs against all subscriptions your identity has access to. To scope it to a specific management group, use: 

    az graph query -q "<your query>" --management-groups "YourManagementGroupId"

    Option 3 — Azure PowerShell

    Install the module (if not already present): 

    Install-Module -Name Az.ResourceGraph -Repository PSGallery -Scope CurrentUser

    Then run:

    Search-AzGraph -Query "Resources | where type contains 'sql' or type contains 'cosmos' or type contains 'documentdb' or type contains 'postgresql' or type contains 'mysql' or type contains 'mariadb' or type contains 'redis' or type contains 'cache' or type contains 'kusto' | distinct type | order by type asc"

    To scope to a management group: 

    Search-AzGraph -Query "<your query>" -ManagementGroup "YourManagementGroupName"

    Each row represents a unique database service type in use across your environment.

    Prerequisites:

    • The calling identity needs at least Reader role on the subscriptions being queried.
    • For CLI: install the resource-graph extension.
    • For PowerShell: install the Az.ResourceGraph module.

    Why Resource Graph over other approaches?

    • Azure Policy is designed for governance and compliance enforcement, not for ad-hoc resource inventory queries.
    • Looping through subscriptions via CLI/PowerShell makes live ARM API calls per subscription, which is slow and prone to throttling at 100+ subscriptions.
    • Tagging strategies require pre-setup and ongoing maintenance — they don't help discover what's already deployed.

    Azure Resource Graph is specifically designed for this use case.

    Thanks,

    Suchitra.

    Was this answer helpful?

    1 person found this answer helpful.

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.