Generated on: August 28, 2025 Target period: Within the last 24 hours Processing mode: Details Mode Number of updates: 3 items
Published: August 27, 2025 16:00:53 UTC Link: Public Preview: Azure SQL updates for late-August 2025
Update ID: 500780 Data source: Azure Updates API
Categories: In preview, Databases, Hybrid + multicloud, Azure SQL Database, Features
Summary:
What was updated
Azure SQL Database introduced a new replication lag metric during its late-August 2025 public preview update.
Key changes or new features
The replication lag metric provides real-time visibility into the recovery point objective (RPO) when Geo-Disaster Recovery (Geo-DR) is enabled. This enhancement allows users to monitor how current the secondary replicas are relative to the primary database, improving transparency and aiding in disaster recovery planning and validation.
Target audience affected
This update primarily benefits developers and IT professionals managing Azure SQL Database instances with Geo-DR configurations, including database administrators responsible for high availability and disaster recovery strategies.
Important notes if any
The feature is currently in public preview, so users should test it in non-production environments before full adoption. Monitoring replication lag can help optimize failover readiness and ensure compliance with recovery objectives. For more details and implementation guidance, refer to the official Azure update page.
Details:
The late-August 2025 public preview update for Azure SQL Database introduces a new replication lag metric designed to enhance monitoring and management of Geo-Distributed Replication (Geo-DR) scenarios by providing real-time visibility into the recovery point objective (RPO). This update addresses a critical need for database administrators and IT professionals to precisely track data synchronization latency between primary and secondary replicas in geo-replicated environments, thereby improving disaster recovery readiness and operational decision-making.
Background and Purpose:
Geo-DR in Azure SQL Database enables high availability and disaster recovery by replicating data asynchronously from a primary database to one or more secondary databases located in different geographic regions. While this replication ensures data durability and availability, asynchronous replication inherently involves some lag, which impacts the RPO—the maximum acceptable amount of data loss measured in time. Prior to this update, customers had limited visibility into the exact replication lag, making it challenging to assess real-time data currency on secondary replicas and to validate compliance with RPO objectives. The introduction of a replication lag metric aims to fill this gap by offering precise, real-time measurement of replication latency.
Specific Features and Detailed Changes:
Technical Mechanisms and Implementation Methods:
The replication lag metric is derived from internal transaction log synchronization timestamps between the primary and secondary databases. Azure SQL Database tracks the last committed transaction time on the primary and compares it with the last applied transaction time on the secondary replica. The difference represents the replication lag. This metric is surfaced through the Azure Resource Manager (ARM) metrics pipeline and exposed as a first-class metric under the Azure SQL Database resource namespace. The underlying telemetry is collected with minimal performance overhead, ensuring that monitoring does not impact database throughput or latency.
Use Cases and Application Scenarios:
Important Considerations and Limitations:
Integration with Related Azure Services:
Published: August 27, 2025 16:00:53 UTC Link: Generally Available: Schema migration is now available in Azure Database Migration Service (DMS)
Update ID: 500770 Data source: Azure Updates API
Categories: Launched, Databases, Migration, Azure Database Migration Service, Features
Summary:
What was updated
Azure Database Migration Service (DMS) now generally supports schema migration for Azure SQL Database.
Key changes or new features
Developers and IT professionals can migrate missing schema objects alongside data by simply enabling a new checkbox option in DMS. This enhancement streamlines the migration process by combining schema and data migration into a single operation, reducing manual steps and potential errors.
Target audience affected
Database administrators, developers, and IT professionals involved in migrating on-premises or other cloud databases to Azure SQL Database.
Important notes if any
This feature improves migration efficiency and reliability but users should still validate schema compatibility and test migrated databases post-migration. The update is generally available, indicating production readiness and full Microsoft support.
For more details, visit: https://azure.microsoft.com/updates?id=500770
Details:
The recent general availability of schema migration in Azure Database Migration Service (DMS) significantly enhances the service’s capability by enabling automated migration of database schema objects alongside data when migrating to Azure SQL Database. This update addresses a longstanding challenge in database migration workflows, where schema and data migrations were often handled separately, increasing complexity, risk, and manual effort.
Background and Purpose
Traditionally, migrating databases to Azure SQL Database required separate steps for schema and data migration. Customers had to manually generate and apply schema scripts or use third-party tools to replicate schema objects before migrating data. This fragmented approach could lead to inconsistencies, longer migration windows, and increased potential for errors. The purpose of this update is to streamline the migration process by integrating schema migration directly into Azure DMS, thereby simplifying the migration workflow and reducing operational overhead.
Specific Features and Detailed Changes
With this update, Azure DMS now supports migrating missing schema objects such as tables, indexes, constraints, stored procedures, views, and functions automatically during the migration process. Users can enable this feature by selecting a single checkbox in the migration project configuration, which instructs DMS to detect and create any schema objects absent in the target Azure SQL Database before or during data migration. This ensures schema consistency and integrity without requiring separate schema deployment steps.
Technical Mechanisms and Implementation Methods
Under the hood, Azure DMS performs a schema comparison between the source database and the target Azure SQL Database. It identifies schema objects that exist on the source but are missing or different on the target. Using this metadata, DMS generates the necessary Data Definition Language (DDL) scripts to create or alter schema objects in the target environment. These scripts are executed as part of the migration workflow, ensuring the target schema aligns with the source before data is migrated. This process leverages Azure DMS’s existing connectivity and orchestration capabilities, supporting both online and offline migration modes.
Use Cases and Application Scenarios
This feature is particularly beneficial for enterprises migrating on-premises SQL Server databases or other supported sources to Azure SQL Database, where schema drift or incomplete schema deployment can cause migration failures or data inconsistencies. It is ideal for lift-and-shift migrations, modernization projects, and hybrid cloud scenarios where minimizing downtime and manual intervention is critical. Additionally, it supports complex database environments with multiple schema objects, enabling smoother transitions to managed Azure SQL Database services.
Important Considerations and Limitations
While schema migration automation simplifies the process, users should be aware of certain limitations. Complex schema elements such as cross-database references, certain types of triggers, or unsupported features in Azure SQL Database may require manual intervention or post-migration adjustments. It is recommended to review the generated schema scripts and perform thorough testing in a non-production environment prior to cutover. Additionally, schema migration currently supports Azure SQL Database targets; migrating to other targets like Azure SQL Managed Instance may have different considerations.
Integration with Related Azure Services
This update complements other Azure migration and management tools such as Azure Data Factory for data orchestration, Azure Monitor for migration monitoring, and Azure DevOps for CI/CD pipeline integration. It also aligns with Azure SQL Database’s built-in features like automatic tuning and performance monitoring, enabling a more seamless post-migration operational experience. By consolidating schema and data migration within Azure DMS, organizations can leverage a unified, Azure-native migration strategy that reduces complexity and accelerates cloud adoption.
In summary, the general availability of schema migration in Azure Database Migration Service represents a significant advancement in simplifying and automating database migrations to Azure SQL Database, improving reliability, reducing manual effort, and enabling faster cloud modernization initiatives.
Published: August 27, 2025 16:00:53 UTC Link: Public Preview: Azure Cosmos DB for MongoDB (vCore)—add shards and rebalance data
Update ID: 500755 Data source: Azure Updates API
Categories: In preview, Databases, Internet of Things, Azure Cosmos DB, Features
Summary:
What was updated
Azure Cosmos DB for MongoDB (vCore) now supports adding physical shards and rebalancing data within clusters during scale-out operations.
Key changes or new features
Developers and IT professionals can dynamically add physical shards (nodes) to their Cosmos DB for MongoDB (vCore) clusters as workload demands increase. This enables seamless scaling of both compute and storage resources. The update leverages the inherent elasticity of Cosmos DB, allowing clusters to grow without downtime. Additionally, data rebalancing across shards ensures optimal distribution and performance as shards are added.
Target audience affected
This update primarily benefits developers and database administrators managing large or growing MongoDB workloads on Azure Cosmos DB who require scalable, high-performance, and flexible cluster configurations.
Important notes if any
The feature is currently in public preview, so users should evaluate it in non-production environments before full adoption. Proper monitoring and management of shard rebalancing are recommended to maintain performance during scaling operations.
For more details, visit: https://azure.microsoft.com/updates?id=500755
Details:
The recent public preview update for Azure Cosmos DB for MongoDB (vCore) introduces the capability to add physical shards and rebalance data dynamically as clusters scale, enhancing the service’s elasticity and performance for large-scale, distributed MongoDB workloads.
Background and Purpose
Azure Cosmos DB for MongoDB (vCore) is a managed database service that offers MongoDB API compatibility on the Azure Cosmos DB platform, combining MongoDB’s developer ecosystem with Cosmos DB’s global distribution, low latency, and scalability. Previously, scaling was constrained by fixed shard counts, limiting flexibility in handling growing data volumes and throughput demands. This update addresses these limitations by enabling dynamic shard addition and data rebalancing, thereby supporting seamless horizontal scaling and improved resource utilization as workloads evolve.
Specific Features and Detailed Changes
Technical Mechanisms and Implementation Methods
Under the hood, the update leverages Cosmos DB’s distributed architecture and partitioning model. Each physical shard corresponds to a set of logical partitions managed by the Cosmos DB partition key. When a new shard is added, the system recalculates partition-to-shard mappings and migrates partition data asynchronously to the new shard nodes. This migration uses internal data movement protocols optimized for minimal impact on availability and latency. The vCore-based billing model allows independent scaling of compute resources per shard, enabling cost-effective resource allocation aligned with workload demands.
Use Cases and Application Scenarios
Important Considerations and Limitations
Integration with Related Azure Services
This report was automatically generated - 2025-08-28 03:02:05 UTC