Generated on: July 31, 2025 Target period: Within the last 24 hours Processing mode: Details Mode Number of updates: 6 items
Published: July 30, 2025 17:00:36 UTC Link: Public Preview: New SQL Server database migration in Azure Arc
Update ID: 498948 Data source: Azure Updates API
Categories: In preview, Features
Summary:
What was updated
Azure introduced a public preview of a new SQL Server database migration experience integrated with Azure Arc, enabling end-to-end migration management within the Azure portal.
Key changes or new features
The update provides a streamlined, unified migration workflow—from initial assessment, provisioning target environments, to cutover—directly in the Azure portal. This experience is powered by Azure Database Migration Service and leverages Azure Arc to manage SQL Server instances across on-premises, multi-cloud, and edge environments. It centralizes migration operations, reduces complexity, and improves visibility and control over the migration process.
Target audience affected
Developers and IT professionals responsible for database migration, especially those managing hybrid or multi-cloud SQL Server deployments using Azure Arc, will benefit from this enhanced migration experience.
Important notes if any
This feature is currently in public preview, so users should evaluate it in non-production environments and provide feedback. Licensing and Azure Arc prerequisites apply. Users should monitor Azure updates for GA announcements and additional capabilities.
Details:
The recent Azure update introduces a Public Preview for a new SQL Server database migration experience integrated within Azure Arc, designed to streamline and centralize the entire migration workflow—from initial assessment through provisioning to final cutover—directly in the Azure portal. This enhancement leverages the Azure Database Migration Service (DMS) under the hood, providing IT professionals with a unified, simplified interface and improved operational efficiency when migrating SQL Server databases to Azure Arc-enabled environments.
Background and Purpose:
As enterprises increasingly adopt hybrid and multi-cloud architectures, managing and migrating SQL Server databases across on-premises, edge, and cloud environments has become complex. Azure Arc extends Azure management capabilities to these diverse environments, but previously, SQL Server migration workflows required multiple tools and fragmented processes. This update addresses the need for a cohesive migration experience that reduces operational overhead, minimizes errors, and accelerates migration timelines by embedding migration capabilities directly within the Azure Arc portal.
Specific Features and Detailed Changes:
Technical Mechanisms and Implementation Methods:
The migration experience is built on top of Azure Arc’s resource management framework, which extends Azure Resource Manager capabilities to on-premises and edge SQL Server instances. When initiating a migration, the portal triggers Azure DMS jobs configured to connect source SQL Server databases (on-premises or other clouds) and target Azure Arc-enabled SQL Server instances. The service handles schema extraction, data replication, and cutover orchestration. Authentication and network connectivity leverage Azure Arc’s secure hybrid connectivity, including Azure Private Link and VPN/ExpressRoute setups, ensuring secure data transfer. The portal’s UI abstracts complex DMS configurations, providing templates and best practices for common migration scenarios.
Use Cases and Application Scenarios:
Important Considerations and Limitations:
Integration with Related Azure Services:
Published: July 30, 2025 17:00:36 UTC Link: Generally Available: Azure SQL updates for late-July 2025
Update ID: 498943 Data source: Azure Updates API
Categories: Launched, Databases, Hybrid + multicloud, Azure SQL Database, Features
Summary:
What was updated
Azure SQL received new language and string handling enhancements in the late-July 2025 update.
| Support for the ANSI SQL concatenation operator ( | ) to concatenate character strings, providing a standard-compliant alternative to the plus (+) operator. |
Target audience affected
Developers working with Azure SQL who require advanced Unicode string manipulation and prefer ANSI SQL standard syntax. Database administrators and IT professionals managing Azure SQL environments will also benefit from improved compatibility and query standardization.
For full details, visit: https://azure.microsoft.com/updates?id=498943
Details:
| The late-July 2025 Azure SQL update introduces enhanced SQL language support by adding the UNISTR intrinsic function and enabling the ANSI SQL concatenation operator ( | ), aligning Azure SQL more closely with standard SQL syntax and improving Unicode string handling capabilities. |
Background and Purpose of the Update
Azure SQL continuously evolves to support broader SQL standards and developer preferences, improving compatibility and easing migration from other database platforms. Prior to this update, Azure SQL had limited native support for certain Unicode string literal definitions and used the plus sign (+) for string concatenation, which differs from the ANSI SQL standard. This update addresses these gaps by implementing the UNISTR function and the ANSI concatenation operator, thereby enhancing developer productivity and code portability.
Specific Features and Detailed Changes
UNISTR Intrinsic Function:
The UNISTR function allows developers to define Unicode string literals using Unicode code points within a string, using the syntax UNISTR(‘…’). This function interprets escape sequences representing Unicode characters (e.g., \XXXX where XXXX is a hexadecimal Unicode code point), enabling precise and readable Unicode string definitions directly in SQL queries. This is particularly useful for representing characters outside the Basic Multilingual Plane or special symbols without relying on external encoding or conversion.
| **ANSI SQL Concatenation Operator ( | )**: | |||
| Azure SQL now supports the double pipe ( | ) operator for string concatenation, which is the ANSI SQL standard. Previously, concatenation was primarily done using the plus sign (+), which can cause ambiguity with numeric addition and requires explicit type casting in some cases. Supporting ( | ) improves code clarity, reduces errors, and enhances compatibility with other ANSI-compliant SQL engines. |
Technical Mechanisms and Implementation Methods
| The ( | ) operator is added to the SQL parser’s grammar as a valid concatenation operator, mapped internally to the string concatenation function. It supports implicit type conversion for string-compatible data types, ensuring seamless concatenation behavior. |
Use Cases and Application Scenarios
| Developers migrating from other ANSI-compliant databases (e.g., Oracle, PostgreSQL) can now use familiar concatenation syntax ( | ) without rewriting queries, simplifying migration and reducing code refactoring efforts. |
Important Considerations and Limitations
| The ( | ) operator is now supported, but legacy code using (+) remains valid; however, mixing concatenation operators within the same query is not recommended to maintain readability. |
Integration with Related Azure Services
In summary, the late-July 2025 Azure SQL update enhances Unicode
Published: July 30, 2025 17:00:36 UTC Link: Public Preview: Azure Database for PostgreSQL cascading read replica
Update ID: 498938 Data source: Azure Updates API
Categories: In preview, Databases, Hybrid + multicloud, Azure Database for PostgreSQL, Features
Summary:
What was updated
Azure Database for PostgreSQL flexible server now supports cascading read replicas, introduced in Public Preview.
Key changes or new features
Developers and IT professionals can create additional read replicas from an existing read replica instead of only from the primary server. This enables a hierarchical replication topology, improving scalability and read workload distribution. Cascading replicas help reduce the load on the primary server and allow for more flexible replication architectures.
Target audience affected
Database administrators, developers, and IT professionals managing PostgreSQL workloads on Azure who require scalable read-heavy architectures and improved replication strategies.
Important notes if any
This feature is currently in Public Preview, so it should be used with caution in production environments. Users should monitor performance and replication lag and review Azure’s documentation for limitations and best practices when implementing cascading read replicas.
Details:
The recent Public Preview release of cascading read replicas for Azure Database for PostgreSQL flexible server introduces a significant enhancement in read scalability and replication topology flexibility. Previously, Azure Database for PostgreSQL allowed creation of read replicas directly from the primary server to offload read workloads, but this update enables the creation of additional read replicas from an existing read replica, forming a cascading replication chain.
Background and Purpose
As cloud-native applications scale, read-heavy workloads often require multiple read replicas to distribute query load and improve performance. Traditional replication models in Azure Database for PostgreSQL flexible server supported only a single hop from the primary server to read replicas, which could lead to increased load on the primary and network bottlenecks. The cascading read replica feature addresses these limitations by allowing a read replica itself to serve as a source for further read replicas, thereby distributing replication traffic and improving scalability and availability.
Specific Features and Detailed Changes
Technical Mechanisms and Implementation Methods
Cascading read replicas leverage PostgreSQL’s native streaming replication capabilities, where WAL (Write-Ahead Log) data is streamed from the source server to the replica. In this update, the replication source can be either the primary or an existing read replica. Azure manages the replication endpoints, authentication, and failover configurations transparently. The replication chain is maintained by configuring the downstream replica’s recovery.conf (or equivalent in flexible server) to connect to the upstream replica’s replication endpoint. Azure’s platform automates the provisioning, monitoring, and failover processes to ensure replication health.
Use Cases and Application Scenarios
Important Considerations and Limitations
Integration with Related Azure Services
Published: July 30, 2025 17:00:36 UTC Link: Generally Available: Accelerated logs now available for General Purpose tier in Azure Database for MySQL - Flexible Server
Update ID: 498933 Data source: Azure Updates API
Categories: Launched, Databases, Azure Database for MySQL, Features
Summary:
What was updated
Azure Database for MySQL - Flexible Server now supports accelerated logs in the General Purpose tier.
Key changes or new features
Accelerated logs, previously exclusive to the Business Critical tier, are now generally available for the General Purpose tier. This enhancement improves write performance by optimizing transaction log handling, reducing latency, and increasing throughput for database workloads.
Target audience affected
Developers and IT professionals using Azure Database for MySQL Flexible Server in the General Purpose tier who require improved database performance without upgrading to the Business Critical tier.
Important notes if any
This update enables cost-effective performance improvements for a wider range of applications. Users can leverage accelerated logs to enhance transactional workloads without changing their existing tier. No additional configuration is typically required to benefit from this feature. For detailed performance tuning and best practices, refer to Azure documentation.
Details:
The recent update announcing the general availability of accelerated logs for the General Purpose tier in Azure Database for MySQL - Flexible Server extends a performance optimization feature that was previously exclusive to the Business Critical tier, thereby enhancing transaction log throughput and overall database responsiveness for a wider range of workloads.
Background and Purpose:
Azure Database for MySQL - Flexible Server offers managed MySQL instances with configurable compute and storage options. Historically, accelerated logs—a feature designed to improve write-ahead logging (WAL) performance by offloading log processing to faster storage media—were limited to the Business Critical tier, which targets I/O-intensive, latency-sensitive applications. The purpose of this update is to democratize this performance enhancement by enabling accelerated logs on the General Purpose tier, which balances cost and performance for most production workloads, thereby improving transactional throughput and reducing commit latency without requiring the higher cost of Business Critical hardware.
Specific Features and Detailed Changes:
Accelerated logs optimize the handling of MySQL’s binary logs and transaction logs by leveraging premium storage and optimized I/O paths. This reduces the latency involved in writing log data to disk, which is critical for transactional consistency and replication. With this update, customers using the General Purpose tier can now enable accelerated logs to achieve lower commit latency and improved write throughput, which translates to better performance for write-heavy workloads such as OLTP applications, real-time analytics, and high-frequency data ingestion scenarios.
Technical Mechanisms and Implementation Methods:
Technically, accelerated logs utilize a combination of faster storage media (such as SSD-backed premium storage) and optimized I/O scheduling to expedite the flushing of transaction logs. This reduces the time MySQL spends waiting on durable log writes, thus improving transaction commit times. The implementation integrates with the Flexible Server architecture by allowing accelerated logs to be enabled or disabled via server configuration parameters or during server provisioning. The underlying infrastructure automatically manages the allocation of premium storage resources for log files, ensuring durability and high availability consistent with Azure’s SLA.
Use Cases and Application Scenarios:
This feature is particularly beneficial for applications with high transaction rates, such as e-commerce platforms, financial services, and SaaS applications requiring consistent low-latency writes. It also benefits scenarios involving replication, where binary log write speed directly impacts replication lag. Additionally, accelerated logs can improve performance for analytics workloads that rely on real-time data ingestion and require minimal write latency to maintain freshness.
Important Considerations and Limitations:
While accelerated logs improve log write performance, they do not replace the need for appropriate indexing, query optimization, and scaling strategies. The feature is available only in the General Purpose tier and may incur additional costs associated with premium storage usage. It is important to monitor performance metrics and storage costs post-enablement to ensure the benefits justify the expense. Additionally, accelerated logs do not impact read latency or CPU-bound workloads directly. Users should also verify compatibility with their MySQL version and application architecture.
Integration with Related Azure Services:
Accelerated logs complement other Azure services such as Azure Monitor for performance monitoring, Azure Backup for data protection, and Azure Private Link for secure connectivity. When combined with Azure Database for MySQL’s built-in high availability and geo-replication features, accelerated logs help maintain low replication lag and high throughput across distributed environments. Integration with Azure Advisor can provide recommendations on enabling accelerated logs based on workload patterns.
In summary, the general availability of accelerated logs for the General Purpose tier in Azure Database for MySQL - Flexible Server provides a cost-effective means to enhance transactional log performance, thereby improving write throughput and reducing latency for a broad spectrum of production workloads, while maintaining the manageability and scalability inherent to the Flexible Server platform.
Published: July 30, 2025 17:00:36 UTC Link: Generally Available: Configure backup interval for Azure Database for MySQL automated backups
Update ID: 498928 Data source: Azure Updates API
Categories: Launched, Databases, Azure Database for MySQL, Features
Summary:
What was updated
Azure Database for MySQL now supports configurable backup intervals for automated backups.
Key changes or new features
Users can set the frequency of automated backups by adjusting the backup interval. This enhancement increases the number of snapshots taken, which helps reduce restore times by providing more recent recovery points. The feature improves backup granularity and recovery flexibility compared to the previous fixed backup schedule.
Target audience affected
Developers and IT professionals managing Azure Database for MySQL instances who require optimized backup and restore strategies, particularly those with stringent recovery point objectives (RPOs).
Important notes if any
Configuring backup intervals allows balancing between backup storage costs and restore speed. Users should evaluate their backup retention and cost requirements when adjusting intervals. This feature is generally available and can be configured via the Azure portal or API.
Details:
The recent general availability of configurable backup intervals for automated backups in Azure Database for MySQL addresses a critical need for enhanced data protection and faster recovery times by allowing users to define how frequently system snapshots are taken. Traditionally, Azure Database for MySQL automated backups occur at fixed intervals, which may not align optimally with varying workload requirements or recovery point objectives (RPOs). This update introduces flexibility by enabling IT professionals to specify backup frequency, thereby improving restore granularity and minimizing potential data loss in disaster recovery scenarios.
Background and Purpose
Automated backups are essential for point-in-time restore (PITR) capabilities and disaster recovery in managed database services. Prior to this update, Azure Database for MySQL performed automated backups at a default interval, typically once every 24 hours, which could lead to longer recovery times and coarser RPOs. Organizations with high transaction volumes or stringent compliance requirements needed more frequent backups to reduce data loss windows. This update responds to those demands by allowing customization of backup intervals, enhancing resilience and operational agility.
Specific Features and Detailed Changes
The key feature introduced is the ability to configure the automated backup interval for Azure Database for MySQL instances. Users can now specify backup intervals shorter than the default, such as every 1, 2, or 4 hours, depending on their business needs. This results in more frequent snapshots of the database, which are stored in Azure Blob Storage as part of the backup retention policy. The update maintains compatibility with existing backup retention settings, ensuring that backups are retained according to user-defined retention periods while increasing snapshot frequency.
Technical Mechanisms and Implementation Methods
Under the hood, the system leverages Azure’s snapshot technology and storage infrastructure to capture consistent backups of the MySQL database at the configured intervals. When a backup interval is set, the Azure Database for MySQL service schedules snapshot jobs accordingly, coordinating with the underlying storage layer to ensure data consistency and minimal performance impact. These snapshots are incremental, capturing only changes since the last backup to optimize storage and reduce backup windows. The configuration can be applied through Azure Portal, Azure CLI, or ARM templates, enabling automation and integration into DevOps pipelines.
Use Cases and Application Scenarios
This feature is particularly beneficial for mission-critical applications requiring minimal data loss, such as financial services, e-commerce platforms, and real-time analytics systems. By reducing the backup interval, organizations can achieve tighter RPOs, ensuring that in the event of failure, data loss is minimized to a few hours or less. It also supports compliance with regulatory standards that mandate frequent backups. Additionally, development and testing environments can leverage this feature to create more granular restore points for debugging or rollback purposes.
Important Considerations and Limitations
While more frequent backups improve restore capabilities, they may increase storage consumption and potentially impact performance during snapshot creation. IT professionals should balance backup frequency with cost implications and workload characteristics. The minimum allowed backup interval and maximum retention period are subject to Azure service limits, which should be reviewed in the official documentation. It is also important to monitor backup job status and storage utilization to avoid unexpected failures or quota overruns.
Integration with Related Azure Services
This update integrates seamlessly with Azure Backup and Azure Monitor. Backup metrics and alerts can be configured in Azure Monitor to track backup health and performance. Additionally, automated backup snapshots are stored in Azure Blob Storage, benefiting from Azure’s durability and geo-redundancy options. Users can also incorporate backup interval configurations into Azure Policy for governance and compliance enforcement across multiple MySQL instances.
In summary, the ability to configure automated backup intervals in Azure Database for MySQL empowers IT professionals to tailor backup strategies to their operational and compliance needs, enhancing data protection and recovery speed through more frequent, incremental snapshots managed via Azure’s robust storage and monitoring ecosystem.
Published: July 30, 2025 16:00:44 UTC Link: Generally Available: Azure Database for PostgreSQL Entra authentication for Power BI Desktop
Update ID: 498175 Data source: Azure Updates API
Categories: Launched, Databases, Hybrid + multicloud, Azure Database for PostgreSQL, Features
Summary:
What was updated
Azure Database for PostgreSQL now supports Microsoft Entra ID authentication when connecting from Power BI Desktop.
Key changes or new features
Developers and IT professionals can use Entra ID (formerly Azure AD) credentials to authenticate Power BI Desktop connections to Azure Database for PostgreSQL. This eliminates the need for managing separate database credentials, streamlining access management and improving security by leveraging centralized identity and access controls.
Target audience affected
Developers building data solutions with Power BI Desktop and Azure Database for PostgreSQL, as well as IT administrators managing database access and security policies.
Important notes if any
Ensure your Azure Database for PostgreSQL server is configured to support Entra ID authentication. This feature aligns with organizations adopting Microsoft Entra for unified identity management, enabling better compliance and governance. For detailed setup instructions, refer to the official Azure documentation.
Details:
The recent update announcing the general availability of Microsoft Entra ID (formerly Azure Active Directory) authentication for Azure Database for PostgreSQL connections from Power BI Desktop represents a significant enhancement in secure data access and identity management for IT professionals managing analytics and database environments.
Background and Purpose
Traditionally, connecting Power BI Desktop to Azure Database for PostgreSQL required using database credentials (username and password) stored within Power BI or managed externally, which posed challenges in centralized identity management, credential rotation, and security compliance. With organizations increasingly adopting Microsoft Entra ID as their unified identity platform, enabling Entra ID authentication directly for PostgreSQL connections streamlines access control, reduces reliance on static credentials, and aligns database access with enterprise identity governance policies.
Specific Features and Detailed Changes
This update introduces native support in Power BI Desktop to authenticate to Azure Database for PostgreSQL using Microsoft Entra ID tokens. Instead of specifying database user credentials, users can now sign in with their Entra ID accounts, and Power BI will acquire OAuth 2.0 access tokens to authenticate the connection. This feature supports both single sign-on (SSO) and multi-factor authentication (MFA) scenarios, enhancing security posture. It also allows administrators to leverage conditional access policies and centralized user lifecycle management for database access.
Technical Mechanisms and Implementation Methods
Under the hood, Power BI Desktop integrates with Microsoft Entra ID’s OAuth 2.0 authorization code flow to obtain access tokens scoped for Azure Database for PostgreSQL. When a user initiates a connection, Power BI triggers an interactive login prompt or silently acquires tokens if SSO is available. The PostgreSQL server must be configured to accept Entra ID tokens by enabling Azure AD authentication and associating database roles with Entra ID users or groups. The connection string in Power BI uses the authentication method parameter set to “Active Directory Interactive” or similar, instructing the client to use Entra ID tokens instead of passwords. Token validation occurs on the PostgreSQL server side, ensuring that only authorized Entra ID principals can connect.
Use Cases and Application Scenarios
Important Considerations and Limitations
Integration with Related Azure Services
This update tightly integrates with Microsoft Entra ID’s identity and access management capabilities, including conditional access, MFA, and identity protection. It complements Azure Database for PostgreSQL’s built-in support for Entra ID authentication, enabling unified identity across Azure resources. Additionally, it aligns with Azure Monitor and Azure Security Center by providing audit trails and security insights based on Entra ID sign-ins. Organizations using Azure Purview for data governance can also benefit from consistent identity attribution for data access activities.
In summary, the general availability of Microsoft Entra ID authentication for Azure Database
This report was automatically generated - 2025-07-31 03:02:39 UTC