Merge pull request #36914 from MicrosoftDocs/main

Auto Publish – main to live - 2026-03-19 17:30 UTC

Author: learn-build-service-prod[bot]

azure-sql/database/doc-changes-updates-release-notes-whats-new.md

@@ -92,8 +92,9 @@ Learn about significant changes to the Azure SQL Database documentation. For pre
 
 | Changes | Details |
 | --- | --- |
-| **New Azure portal query editor experience**|A new Query editor (preview) experience in the Azure portal offers a new modernized authentication page and consistency with other portal query editor experiences. For more information, see [Quickstart: Use the Azure portal query editor to query Azure SQL Database](connect-query-portal.md). |
 | **160 and 192 vCore for Hyperscale Premium-series**|160 and 192 vCore options for Hyperscale Premium-series are now available as a preview offering, for both single Hyperscale databases and Hyperscale elastic pools. For more information, see [160 and 192 vCore offering for Hyperscale Premium-series](https://aka.ms/PRMS192vCores).|
+| **Automatic index compaction preview** | [Automatic index compaction](/sql/relational-databases/indexes/automatic-index-compaction) helps you reduce the consumption of storage space, disk I/O, memory, and improve workload performance without investing time and effort into index maintenance jobs. This feature is now in preview. |
+| **New Azure portal query editor experience**|A new Query editor (preview) experience in the Azure portal offers a new modernized authentication page and consistency with other portal query editor experiences. For more information, see [Quickstart: Use the Azure portal query editor to query Azure SQL Database](connect-query-portal.md). |
 | **Import and export using managed identity preview** | You can [import or export an Azure SQL Database BACPAC file with managed identity authentication](database-import-export-managed-identity.md). Use managed identity authentication for enhanced security when importing or exporting databases. This capability is currently in preview for Azure SQL Database. |
 | **Vector indexing and VECTOR_SEARCH enhancements** | Latest version vector indexes now support full DML operations, iterative filtering, new `SELECT TOP (N) WITH APPROXIMATE` syntax, the `FORCE_ANN_ONLY` table hint, and the new [sys.dm_db_vector_indexes](/sql/relational-databases/system-dynamic-management-views/sys-dm-db-vector-indexes-transact-sql?view=azuresqldb-current&preserve-view=true) DMV for monitoring index health. Regional availability is documented at [Feature availability by region](region-availability.md#vector-search). For more information, see [VECTOR_SEARCH](/sql/t-sql/functions/vector-search-transact-sql?view=azuresqldb-current&preserve-view=true) and [CREATE VECTOR INDEX](/sql/t-sql/statements/create-vector-index-transact-sql?view=azuresqldb-current&preserve-view=true). |
 

azure-sql/database/elastic-convert-to-use-elastic-tools.md

@@ -16,6 +16,8 @@ monikerRange: "=azuresql || =azuresql-db "
 
 [!INCLUDE[appliesto-sqldb](../includes/appliesto-sqldb.md)]
 
+[!INCLUDE [elastic-query-shard-map-manager-mode-end-of-support](includes/elastic-query-shard-map-manager-mode-end-of-support.md)]
+
 Easily manage your existing scaled-out sharded databases using tools (such as the [Building scalable cloud databases](elastic-database-client-library.md)). First convert an existing set of databases to use the [shard map manager](elastic-scale-shard-map-management.md).
 
 ## Overview

azure-sql/database/elastic-database-client-library.md

@@ -16,6 +16,8 @@ monikerRange: "=azuresql || =azuresql-db "
 
 [!INCLUDE[appliesto-sqldb](../includes/appliesto-sqldb.md)]
 
+[!INCLUDE [elastic-query-shard-map-manager-mode-end-of-support](includes/elastic-query-shard-map-manager-mode-end-of-support.md)]
+
 Scaling out databases can be easily accomplished using scalable tools and features for Azure SQL Database. In particular, you can use the **Elastic Database client library** to create and manage scaled-out databases. This feature lets you easily develop sharded applications using thousands databases in Azure SQL Database.
 
 **To download:**

azure-sql/database/elastic-database-perf-counters.md

@@ -17,6 +17,8 @@ monikerRange: "=azuresql || =azuresql-db "
 
 [!INCLUDE[appliesto-sqldb](../includes/appliesto-sqldb.md)]
 
+[!INCLUDE [elastic-query-shard-map-manager-mode-end-of-support](includes/elastic-query-shard-map-manager-mode-end-of-support.md)]
+
 Performance counters are used to track the performance of [data dependent routing](elastic-scale-data-dependent-routing.md) operations. These counters are accessible in the **Performance Monitor**, in the "Elastic Database: Shard Management" category.
 
 You can capture the performance of a [shard map manager](elastic-scale-shard-map-management.md), especially when using [data dependent routing](elastic-scale-data-dependent-routing.md). Counters are created with methods of the `Microsoft.Azure.SqlDatabase.ElasticScale.Client` class.  

azure-sql/database/elastic-database-recovery-manager.md

@@ -17,6 +17,8 @@ ms.custom:
 
 [!INCLUDE[appliesto-sqldb](../includes/appliesto-sqldb.md)]
 
+[!INCLUDE [elastic-query-shard-map-manager-mode-end-of-support](includes/elastic-query-shard-map-manager-mode-end-of-support.md)]
+
 The [RecoveryManager](/dotnet/api/microsoft.azure.sqldatabase.elasticscale.shardmanagement.recovery.recoverymanager) class provides ADO.NET applications the ability to easily detect and correct any inconsistencies between the global shard map (GSM) and the local shard map (LSM) in a sharded database environment.
 
 The GSM and LSM track the mapping of each database in a sharded environment. Occasionally, a break occurs between the GSM and the LSM. In that case, use the `RecoveryManager` class to detect and repair the break.

azure-sql/database/elastic-query-getting-started.md

@@ -16,6 +16,8 @@ monikerRange: "=azuresql || =azuresql-db"
 
 [!INCLUDE[appliesto-sqldb](../includes/appliesto-sqldb.md)]
 
+[!INCLUDE [elastic-query-shard-map-manager-mode-end-of-support](includes/elastic-query-shard-map-manager-mode-end-of-support.md)]
+
 You can create reports from multiple databases from a single connection point using an [elastic query](elastic-query-overview.md). The databases must be horizontally partitioned (also known as "sharded").
 
 If you have an existing database, see [Migrate existing databases to scale out](elastic-convert-to-use-elastic-tools.md).

azure-sql/database/elastic-query-horizontal-partitioning-migration.md

@@ -0,0 +1,89 @@
+---
+title: Migration guide from elastic query shard map manager mode
+description: Learn about migration options for elastic query with EXTERNAL DATA SOURCE type SHARD_MAP_MANAGER, which is reaching end of support on March 31, 2027.
+author: WilliamDAssafMSFT
+ms.author: wiassaf
+ms.reviewer: bgavrilovic
+ms.date: 03/18/2026
+ms.service: azure-sql-database
+ms.subservice: scale-out
+ms.topic: conceptual
+---
+
+# Migration from elastic query shard map manager mode
+
+[!INCLUDE[appliesto-sqldb](../includes/appliesto-sqldb.md)]
+
+Elastic query in shard map manager mode (horizontal partitioning), using `EXTERNAL DATA SOURCE` type `SHARD_MAP_MANAGER`, is reaching end of support on March 31, 2027. After this date, existing workloads will continue to function but will no longer receive support, and creation of new external data sources of type `SHARD_MAP_MANAGER` will no longer be possible. This article contains options to migration from elastic query shared map manager mode.
+
+For customers using elastic query with `EXTERNAL DATA SOURCE` type `SHARD_MAP_MANAGER`, the best alternative depends on the use case for using elastic query and on the overall scenario and architecture. 
+
+This article describes possible alternatives to elastic query shard map manager mode, and key considerations for each.
+
+## Microsoft Fabric
+
+**Best for:** OLAP (online analytical processing) and reporting scenarios.
+
+Microsoft Fabric offers robust capabilities for large-scale analytics and reporting, enabling seamless data integration and advanced analytics workloads. However, migration might require rearchitecting existing solutions and retraining teams on new tools. Evaluate the cost implications and compatibility with your existing data sources.
+
+For more information, see [Microsoft Fabric documentation](/fabric/fundamentals/microsoft-fabric-overview).
+
+## SQL mirroring to Fabric
+
+**Best for:** Reporting and analytics on centralized data.
+
+Mirroring SQL databases to Fabric can simplify reporting and analytics on centralized data. Consider the latency and synchronization requirements between source and mirrored data. Also, assess the complexity involved in setting up mirroring and the impact on ongoing operations.
+
+For more information, see [Microsoft Fabric mirrored databases from Azure SQL Database](/fabric/database/mirrored-database/azure-sql-database).
+
+## ETL-based approach (for example, using Azure Data Factory)
+
+**Best for:** Batch processing and scheduled data movement.
+
+Using ETL pipelines like Azure Data Factory (ADF) provides flexible, scheduled data movement and transformation. This approach works well for batch processing but might introduce delays in data freshness. Consider the maintenance overhead and the scalability of ETL jobs as data volume grows.
+
+For more information, see [Azure Data Factory documentation](/azure/data-factory/) or [Data Factory in Microsoft Fabric](/fabric/data-factory/data-factory-overview).
+
+## Fully migrate data plane to Fabric OneLake
+
+**Best for:** Centralized data management with unified analytics.
+
+When you migrate entirely to Fabric OneLake, you centralize data management and take advantage of unified analytics features. This migration might require significant effort, possible downtime, and refactoring applications. Weigh the long-term benefits against short-term migration challenges, and make sure it fits your business requirements.
+
+For more information, see [OneLake documentation](/fabric/onelake/onelake-overview).
+
+## Azure SQL Database Hyperscale
+
+**Best for:** Workloads where sharding was implemented due to storage limitations that Hyperscale overcomes today.
+
+Azure SQL Database Hyperscale works well for workloads that need high performance, scalability, and rapid growth in data volume. It supports databases of any size, with fast backup and restore, and high concurrency. If you originally implemented sharding because of storage limitations, you can rearchitect your system from a sharded topology to a monolithic database. Migration involves consolidating databases and adapting your application logic for centralized storage. Consider cost, performance, and operational implications, especially if you currently rely on distributed query capabilities.
+
+For more information, see [Azure SQL Database Hyperscale service tier](service-tier-hyperscale.md).
+
+## Elastic jobs
+
+**Best for:** Running queries on individual databases or shards without result aggregation.
+
+If you use elastic query to run queries on individual databases or shards in the fleet without result aggregation, elastic jobs provide the same capability. Elastic jobs are ideal for automating and managing operations across multiple databases. They don't support result aggregation, so they're best suited for scenarios where independent queries suffice. Review the job scheduling features and integration with monitoring tools to ensure operational efficiency.
+
+For more information, see [Elastic jobs in Azure SQL Database](elastic-jobs-overview.md).
+
+## Azure SQL Managed Instance
+
+**Best for:** Point-to-point cross-database queries using three-part names or linked servers.
+
+Azure SQL Managed Instance natively supports three-part name queries and linked servers. If you use elastic query for point-to-point queries, a SQL managed instance is a natural migration target. Consider networking setup, security configurations, and licensing costs. Ensure that your workload fits within the SQL managed instance's performance and scalability limits.
+
+For more information, see [What is Azure SQL Managed Instance?](/azure/azure-sql/managed-instance/sql-managed-instance-paas-overview)
+
+## Custom fanout query and result aggregation layer
+
+**Best for:** Preserving existing Azure SQL Database architecture with maximum flexibility.
+
+Building a custom fanout and aggregation layer preserves your existing architecture and provides maximum flexibility. The fanout query runs on top of the SQL Database architecture by using a customer-built layer. This approach requires development effort, ongoing maintenance, and robust error handling. Evaluate the complexity of building and supporting this solution, as well as its scalability and reliability for your needs.
+
+## Related content
+
+- [Elastic query overview](elastic-query-overview.md)
+- [Reporting across scaled-out cloud databases](elastic-query-horizontal-partitioning.md)
+- [Getting started with elastic query for horizontal partitioning (sharding)](elastic-query-getting-started.md)

azure-sql/database/elastic-query-horizontal-partitioning.md

@@ -1,10 +1,10 @@
 ---
 title: Reporting Across Scaled-Out Cloud Databases
-description: how to set up elastic queries over horizontal partitions
+description: How to set up elastic queries over horizontal partitions.
 author: WilliamDAssafMSFT
 ms.author: wiassaf
 ms.reviewer: bgavrilovic, mathoma
-ms.date: 06/13/2025
+ms.date: 03/17/2026
 ms.service: azure-sql-database
 ms.subservice: scale-out
 ms.topic: how-to
@@ -13,9 +13,10 @@ ms.custom:
 monikerRange: "=azuresql || =azuresql-db"
 ---
 # Reporting across scaled-out cloud databases (preview)
-
 [!INCLUDE[appliesto-sqldb](../includes/appliesto-sqldb.md)]
 
+[!INCLUDE [elastic-query-shard-map-manager-mode-end-of-support](includes/elastic-query-shard-map-manager-mode-end-of-support.md)]
+
 Sharded databases distribute rows across a scaled out data tier. The schema is identical on all participating databases, also known as horizontal partitioning. Using an elastic query, you can create reports that span all databases in a sharded database.
 
 :::image type="content" source="media/elastic-query-horizontal-partitioning/horizontal-partitioning.png" alt-text="Diagram of how queries work across shards." lightbox="media/elastic-query-horizontal-partitioning/horizontal-partitioning.png":::

azure-sql/database/elastic-query-overview.md

@@ -4,7 +4,7 @@ description: Elastic query enables you to run a Transact-SQL query that spans mu
 author: WilliamDAssafMSFT
 ms.author: wiassaf
 ms.reviewer: drskwier, bgavrilovic, mathoma, randolphwest
-ms.date: 01/30/2025
+ms.date: 03/17/2026
 ms.service: azure-sql-database
 ms.subservice: scale-out
 ms.topic: overview
@@ -16,7 +16,7 @@ ms.custom:
 
 [!INCLUDE [appliesto-sqldb](../includes/appliesto-sqldb.md)]
 
-The elastic query feature (in preview) enables you to run a Transact-SQL (T-SQL) query that spans multiple databases in Azure SQL Database. It allows you to perform cross-database queries to access remote tables, and to connect Microsoft and third-party tools (Excel, Power BI, Tableau, etc.) to query across data tiers with multiple databases. Using this feature, you can scale out queries to large data tiers and visualize the results in business intelligence (BI) reports.
+The elastic query feature (in preview) enables you to run a Transact-SQL (T-SQL) query that spans multiple databases in Azure SQL Database. It allows you to perform cross-database queries to access remote tables, and to connect Microsoft and non-Microsoft tools (Excel, Power BI, Tableau, etc.) to query across data tiers with multiple databases. Using this feature, you can scale out queries to large data tiers and visualize the results in business intelligence (BI) reports.
 
 ## Why use elastic queries
 
@@ -93,6 +93,8 @@ After running the DDL statements, you can access the remote table `mytable` as t
 
 ## Horizontal partitioning - sharding
 
+[!INCLUDE [elastic-query-shard-map-manager-mode-end-of-support](includes/elastic-query-shard-map-manager-mode-end-of-support.md)]
+
 Using elastic query to perform reporting tasks over a sharded, that is, horizontally partitioned, data tier requires an [elastic database shard map](elastic-scale-shard-map-management.md) to represent the databases of the data tier. Typically, only a single shard map is used in this scenario and a dedicated database with elastic query capabilities (head node) serves as the entry point for reporting queries. Only this dedicated database needs access to the shard map. Figure 4 illustrates this topology and its configuration with the elastic query database and shard map. For more information about the elastic database client library and creating shard maps, see [Shard map management](elastic-scale-shard-map-management.md).
 
 **Figure 4** Horizontal partitioning - Using elastic query for reporting over sharded data tiers

azure-sql/database/elastic-scale-data-dependent-routing.md

@@ -21,6 +21,8 @@ ms.custom:
 
 The application does not need to track various connection strings or DB locations associated with different slices of data in the sharded environment. Instead, the [Scale out databases with the shard map manager](elastic-scale-shard-map-management.md) opens connections to the correct databases when needed, based on the data in the shard map and the value of the sharding key that is the target of the application's request. The key is typically the *customer_id*, *tenant_id*, *date_key*, or some other specific identifier that is a fundamental parameter of the database request.
 
+[!INCLUDE [elastic-query-shard-map-manager-mode-end-of-support](includes/elastic-query-shard-map-manager-mode-end-of-support.md)]
+
 For more information, see [Scaling Out SQL Server with Data-Dependent Routing](/previous-versions/sql/sql-server-2005/administrator/cc966448(v=technet.10)).
 
 ## Download the client library