Azure SQL Blog articles

Azure SQL Database is retiring Always Encrypted with Intel SGX enclaves

PieterVanhove — Wed, 07 Oct 2026 09:15:52 GMT

On October 31, 2027, Azure SQL Database will retire Intel Software Guard Extensions (SGX) enclave functionality for Always Encrypted. Workloads that still depend on Intel SGX enclaves after that date will no longer work as configured.

The path forward is Virtualization-Based Security (VBS) enclaves, a hardware-independent option that does not require attestation. To retain secure-enclave capabilities, move databases from DC-series compute to a supported standard-series, non-DC tier and update affected applications for VBS enclave mode.

What is changing?

Intel SGX enclaves are tied to DC-series compute. After October 31, 2027, databases on these tiers must move to supported compute to retain enclave-enabled capabilities. Applications configured for Intel SGX enclaves may also need driver and connection-string updates.

For workloads that do not require isolation from the host operating system, VBS enclaves offer a straightforward migration within Azure SQL Database. If your threat model requires Intel SGX-equivalent host isolation, evaluate SQL Server on Azure Confidential VMs instead.

Choose the right migration path

Use the migration guide to identify databases and elastic pools on DC-series compute, choose the target architecture that matches your threat model, update application connectivity and attestation settings, and validate the workload before production cutover.

Move to VBS enclaves in Azure SQL Database

Choose VBS enclaves when you need to protect sensitive data from unauthorized users or malicious insiders but do not require isolation from the host operating system. VBS enclaves run on supported non-DC compute tiers and eliminate attestation requirements.

Consider SQL Server on Azure Confidential VMs

If your threat model requires stronger isolation from the host operating system, assess SQL Server on Azure Confidential VMs. Compare architecture, operations, compatibility, and cost with the Azure SQL Database option.

Start planning early

Start now. Discovery, compute-tier changes, application updates, security review, and production validation all take time. Complete the migration before October 31, 2027, to keep enclave-enabled workloads running without interruption.

Help and support

Have questions? Ask community experts in Microsoft Q&A. If you have an Azure support plan and need technical help, create a support request.

Review service retirements that may affect your resources in the Azure Retirement Workbook. For more ways to find impacted resources, see the retirement guidance. Retirement information may take up to two weeks to appear.

Public Preview: Auto-pause and auto-resume for Azure SQL Database Hyperscale Serverless

kendalvandyke — Tue, 29 Sep 2026 23:02:07 GMT

Auto-pause and auto-resume are now available in public preview for Azure SQL Database Hyperscale databases using the Serverless compute tier.

With auto-pause enabled, a database can automatically pause during periods of inactivity and resume when activity returns, helping reduce costs for workloads that experience extended or predictable idle periods. When a database is paused, compute billing stops and only storage-related charges continue to apply.

Auto-pause and auto-resume can be enabled for both new and existing Hyperscale databases using the Serverless compute tier, and the preview is available in all regions where Hyperscale Serverless is supported.

If you’ve used auto-pause and auto-resume with General Purpose Serverless, the experience in Hyperscale should feel familiar. We've designed the configuration and behavior to closely follow what's already available in the General Purpose tier.

Configure auto-pause and auto-resume

You can configure auto-pause and auto-resume through the Azure portal, Azure CLI, Azure PowerShell, or REST API.

Existing Hyperscale Serverless databases won’t automatically have auto-pause enabled, but you can enable it by updating the database configuration. You can also configure auto-pause when creating a new Hyperscale Serverless database.

Configure the auto-pause delay for a Hyperscale Serverless database in the Azure portal.

The following Azure CLI example creates a Hyperscale Serverless database with a 60-minute auto-pause delay:

$resourceGroupName = "<resource group name>" $serverName = "<logical SQL server name>" $databaseName = "<database name>" az sql db create ` -g $resourceGroupName ` -s $serverName ` -n $databaseName ` -e Hyperscale ` --compute-model Serverless ` -f Gen5 ` --min-capacity 0.5 ` -c 2 ` --auto-pause-delay 60

And this example updates the minimum and maximum vCores and sets the auto-pause delay for an existing Hyperscale Serverless database:

$resourceGroupName = "<resource group name>" $serverName = "<logical SQL server name>" $databaseName = "<database name>" az sql db update ` -g $resourceGroupName ` -s $serverName ` -n $databaseName ` --min-capacity 1 ` --capacity 4 ` --auto-pause-delay 1440

If you're using Azure CLI, Azure PowerShell, or REST API and want to disable auto-pause, set the auto-pause delay to -1.

Things to know during the preview

There are a few behaviors and limitations to keep in mind during the public preview:

The minimum auto-pause delay is currently 60 minutes.
New Hyperscale Serverless databases created through Azure CLI, Azure PowerShell, or REST API will receive a default auto-pause delay of 60 minutes if --auto-pause-delay (or the equivalent parameter) isn't explicitly specified. This mirrors the existing behavior for General Purpose Serverless.
If you don't want a new database to auto-pause, specify an auto-pause delay of -1 when creating the database through Azure CLI, Azure PowerShell, or REST API. Likewise, to disable auto-pause on an existing database that has auto-pause enabled, set the auto-pause delay to -1.
Named Replicas aren't supported with auto-pause during the preview.

Moving from General Purpose to Hyperscale

If you're migrating an existing General Purpose Serverless database to Hyperscale, you'll also need to account for the difference in the supported minimum auto-pause delay.

Here are the current behaviors during preview:

If the General Purpose database has an auto-pause delay of less than 60 minutes and you don't specify a new value, the operation will fail.
If the existing auto-pause delay is 60 minutes or higher and you don't specify a new value, the operation will succeed.
Regardless of the existing value, the operation will succeed if you specify a new auto-pause delay of 60 minutes or higher.

For example, if you're moving a General Purpose Serverless database that has a 15-minute auto-pause delay, specify a supported Hyperscale value, such as 60 minutes, as part of the operation.

Why this matters

You can now combine Hyperscale's independent scaling of compute and storage with the ability to automatically pause inactive databases. If auto-pause has been one of the reasons you've stayed on General Purpose Serverless, you no longer have to make that tradeoff when moving to Hyperscale.

And because the experience closely mirrors General Purpose Serverless, existing tools, automation, and operational practices can be used with minimal changes.

Get started

Read the documentation:
- Serverless compute tier for Azure SQL Database
- Auto-pause and auto-resume in the serverless compute tier for Azure SQL Database
Share feedback through the Azure SQL Database Community
Read more SQLCon Europe 2026 announcements:
- SQLCon Barcelona 2026: Advancing SQL with greater control, scale, and intelligence
- What’s new across Microsoft SQL at SQLCon/FabCon Europe 2026

Database Hub in Fabric: Now in Public Preview -Turn Database Signals into Guided Action

amardigamberpatil — Wed, 07 Oct 2026 19:57:26 GMT

As applications grow, so does the database estate behind them. What starts with a handful of databases can become hundreds or thousands of resources spread across services, subscriptions, and environments. For the teams responsible for keeping them healthy, the challenge is no longer just collecting signals. It is knowing what needs attention, why it matters, and what to do next.

Now in public preview, Database Hub in Microsoft Fabric brings inventory, health, performance, security, and optimization insights into one connected experience. It helps administrators and developers see the bigger picture, identify affected resources, and move from estate-wide visibility to focused investigation, without losing the context that brought them there.

The preview brings together supported resources across Azure SQL Database, SQL Server enabled by Azure Arc, Azure Database for PostgreSQL, Azure Cosmos DB, and SQL database in Fabric. Available capabilities and signals vary by service and preview configuration.

Database Hub Overview brings together estate-wide findings and cross-engine performance trends to help you prioritize what needs attention.

Start with what needs your attention

When you manage a large database estate, another dashboard is only useful if it helps you decide where to spend your time.

The Overview page provides that starting point, bringing together findings across security, performance, and optimization. It distinguishes Issues, which require timely attention, from Suggestions, which highlight opportunities to improve your estate over time.

You might begin with a security configuration that needs review or a performance signal that warrants investigation. Selecting a finding opens Estate with the relevant filters already applied, so you can see the affected resources rather than search for them again.

The result is a more direct path from “something needs attention” to “these are the resources I should investigate.”

Overview highlights issues across Security, Performance, and Optimization, with affected-resource counts and direct links to investigate further.

Bring your estate into one view, and make it relevant to you

The Estate experience brings supported resources into a unified inventory, scoped to your existing permissions. Search and filters help you narrow that inventory to the service, subscription, or resource group you manage.

This is especially useful when your responsibilities span database engines. You can begin with a broader view, then focus on Azure SQL databases, Arc-enabled SQL Server resources, or Azure Database for PostgreSQL flexible servers without rebuilding the resource list in separate portals.

Each resource brings its associated Issues and Suggestions into context. Open a finding to review the affected resource, supporting information, and recommended next step.

The inventory also respects the resource model of each service. For example, the PostgreSQL view represents flexible server instances, rather than every database hosted within them.

A unified view does not mean moving your databases. Your Azure resources remain in their existing subscriptions, and on-premises SQL Server instances remain on-premises, connected through Azure Arc. Database Hub brings operational context together; it does not require relocating or mirroring your application data into Fabric.

Estate brings resource inventory, Issues, and Suggestions into one view, with quick actions to continue investigation in the Azure portal, VS Code, or SSMS.

Understand security posture and performance in context

Database Hub helps you identify configurations worth reviewing and resources that need a closer look.

For security, supported signals can include Microsoft Entra authentication, customer-managed keys, and auditing coverage, depending on the database service. These findings provide a starting point for investigation, not a blanket judgment that every flagged resource is insecure or noncompliant.

For example, a suggestion to review customer-managed keys should be evaluated against your organization’s requirements. A resource using service-managed keys is still encrypted at rest.

For performance, built-in dashboards bring supported utilization and activity signals into view, including CPU, memory, storage, I/O, and connections. Review trends across your estate, then narrow the scope and time range to investigate individual resources. Metric availability varies by engine and monitoring configuration; missing data should not be interpreted as good health.

For supported SQL monitoring scenarios, you can also create a custom monitoring dashboard from a template and tailor its charts and layout to the resources your team follows regularly.

Together, these experiences help answer two practical questions: Where is pressure building, and where is there an opportunity to improve?

Performance summaries highlight recent capacity signals and trends across Microsoft SQL, PostgreSQL, and Cosmos DB.

The Security dashboard summarizes Microsoft Entra authentication, audit logging, and customer-managed key coverage, helping you identify configurations that warrant review across your estate.

The Performance monitoring dashboard combines memory-pressure trends, resource-level details, and interpretation guidance to help focus your investigation.

Move from a finding to an informed next step

Estate-wide visibility is the beginning of an investigation, not a replacement for database expertise.

When a finding needs deeper analysis, Database Hub helps you review the evidence and continue in the appropriate native experience, such as the Azure portal or SQL Server Management Studio (SSMS). Engine-specific diagnostics and configuration changes remain in the tools designed for that work.

Consider a performance issue that occurred before an administrator could inspect it. In supported agent-assisted scenarios, captured incident evidence can help establish what happened, when it happened, and which queries or sessions were involved. That context gives the administrator a more informed starting point for investigation.

The operator remains in control: review the evidence, evaluate the recommendation, and apply authorized changes through the appropriate service tools. The preview investigation workflow does not automatically remediate issues, and existing permissions and approval requirements continue to apply.

Bring database expertise into agent-assisted workflows

We are also making database operational intelligence available through agent skills: reusable capabilities that agents can call to support observability, monitoring, diagnostics, optimization, and other database operations.

Database Hub provides estate context; skills provide a way to bring database expertise into an agent-assisted investigation. This creates a foundation for helping teams move from identifying an affected resource to understanding its signals and evaluating the next step.

We’re building toward making this expertise available in the AI companions and development tools teams already use, with recommendations grounded in evidence, the specific database, and your organization’s operational controls.

If we take a step back, our broader vision brings together a free, extensible Database Hub experience, agentic observability, and OneLake integration, all within Microsoft Fabric. It’s a foundation for connecting database operations with analytics and AI and helping teams turn signals into informed action.

Get started with Database Hub

Start with the Database Hub documentation to review preview availability, supported services, and setup requirements. Ask your Fabric administrator to enable the preview where required, confirm that you have the appropriate resource permissions, and complete any service-specific monitoring prerequisites.

Then open Microsoft Fabric, select Databases in the left navigation, and begin with Overview. Choose a finding, explore the affected resources in Estate, and follow the evidence into your next investigation. For more details on supported services and getting set up, the Database Hub documentation is also available on Microsoft Learn.

Learn more

What is Database Hub in Fabric?

Enable performance monitoring for Microsoft SQL

Performance Monitoring for Azure SQL in Database Hub

MI link support for multiple databases in an Always On availability group for SQL Server (Preview)

danimir — Mon, 05 Oct 2026 22:45:59 GMT

A simpler way to extend availability groups to Azure

We are pleased to announce the preview of multi-database mode for Managed Instance link. The new mode lets you replicate multiple databases from an existing Always On availability group through a single link between SQL Server and Azure SQL Managed Instance.

Managed Instance link uses distributed availability group technology to provide near-real-time replication between SQL Server and Azure SQL Managed Instance. It supports hybrid architectures, online migration, disaster recovery, and read-only workload offload. The link can be configured and managed through SQL Server Management Studio (SSMS), PowerShell, Azure CLI, and Azure APIs.

Previously, each link supported one database. Customers with multi-database availability groups therefore had to split databases into separate availability groups and create a link for each database. Multi-database mode removes that limitation for supported SQL Server versions and editions, while the existing single-database mode remains available for earlier versions and other supported configurations.

What you can do with multi-database link mode

Migrate multiple databases to Azure SQL Managed Instance with minimal cutover downtime.
Offload read-only workloads, including reporting and analytics, to the secondary replica.
Use Azure SQL Managed Instance as a disaster recovery target for supported SQL Server versions.
Start replication in either direction when the SQL Server version and Azure SQL Managed Instance update policy support that direction.
Reverse primary and secondary roles through a planned failover.
Build hybrid and multicloud topologies that place database groups where they are most useful.

One link for an existing multi-database availability group

If you already use an Always On availability group, multi-database link mode lets you extend the complete database group to Azure SQL Managed Instance without creating a separate availability group for every database. All databases in the link move together as one managed group. Databases on the primary are read-write, while their copies on the secondary are read-only. Use of your existing Always On AG listener endpoint is supported with multi-database mode MI link, allowing the link to remain operational after a local AG failover.

Image 1: A multi-database Always On availability group replicated to Azure SQL Managed Instance through one Managed Instance link.

The diagram illustrates the availability group relationship rather than a specific Azure SQL Managed Instance service-tier replica count. Managed Instance link is supported across all Azure SQL Managed Instance service tiers.

Run multiple links in different directions

A single SQL Server instance can participate in multiple links. Each link can carry a different availability group, and supported links can replicate in different directions at the same time.

In the following example, AG1 (containing DB1, DB2, and DB3) replicates from SQL Server to Azure SQL Managed Instance through MI link 1. AG2 (containing DB4, DB5, and DB6) replicates from Azure SQL Managed Instance to SQL Server through MI link 2. Both links can operate at the same time between the two instances.

Image 2: Two multi-database availability groups using separate links with opposite replication directions.

Important: Database names must be unique in this configuration. A database cannot be renamed on the secondary while it is participating in replication to resolve a naming conflict.

Replicate one availability group to multiple managed instances

Multi-database mode also supports fan-out topologies. You can replicate multiple availability groups to one managed instance, or replicate the same availability group to different managed instances. For example, separate links can target managed instances in different Azure regions.

Image 3: One multi-database availability group replicated through separate links to two Azure SQL managed instances.

Preview requirements

Requirement	Details
SQL Server	SQL Server 2022 with CU27 or SQL Server 2025 with CU9 and above.
Edition	Enterprise or Developer edition. Standard edition supports basic availability groups with one database and is not supported for multi-database mode.
Azure SQL Managed Instance	Use a compatible update policy (2022 or 2025) matching your SQL Server version.
SSMS	SSMS 22.10.2 or later for the multi-database link capability.
Automation	Az module 16.3.0 or later and Az.Sql 7.1.0 or later, or the corresponding Azure APIs.

Get started

To evaluate multi-database mode during preview:

Confirm that the SQL Server version, edition, servicing level, and Azure SQL Managed Instance update policy meet the preview requirements.
Upgrade to SSMS 22.10.2 or later, or use a supported automation interface.
Enable multi-database mode before creating a multi-database link.
Create the link from the existing Always On availability group and validate synchronization for every database.
Review the Azure documentation for multi-database Managed Instance link configuration, limitations, monitoring, failover, and cleanup guidance.

Share your feedback

We would love to hear about your experience with multi-database mode. Please share questions, feedback, and feature suggestions through the Managed Instance link feedback form.

Public Preview: Performance monitoring for Azure SQL in Database Hub

LanceWright — Thu, 01 Oct 2026 18:38:44 GMT

We're excited to announce the public preview of performance monitoring for Azure SQL in Database Hub in Fabric.

Performance monitoring brings the health and performance of your SQL estate into Database Hub. You see every supported database in one place and quickly spot the ones that need attention. It works across:

Azure SQL Database
Azure SQL Managed Instance (coming soon)
SQL Server on Azure Virtual Machines
SQL Server enabled by Azure Arc

Microsoft collects performance-related telemetry, runs the pipeline, and stores the data for you. There's nothing you need to deploy and nothing to operate. Turn it on, and your SQL resources show up on the Performance page in Database Hub, which is free.

This post is a deep dive on the performance part of Database Hub. For the full tour, including the Overview, Estate, and Security pages, read Database Hub in Fabric: Now in Public Preview.

Get started in three steps

Open Database Hub in Fabric.
- During the preview, a Fabric administrator needs to turn on the Database Hub tenant setting. See the prerequisites.
Turn on performance monitoring for your SQL resources. See Enable performance monitoring for Microsoft SQL.
Go to the Performance page to see which databases need your attention.

See your entire database estate in Database Hub

Performance monitoring powers the Performance page in Database Hub. Database Hub is built for when you need to look across all your databases, not just one at a time. It brings your database estate across Azure, on-premises, and other clouds into one place, including:

Azure SQL and SQL Server enabled by Azure Arc
Azure Database for PostgreSQL
Azure Cosmos DB

The Performance page comes with prebuilt dashboards, so you can see performance at a glance without building anything yourself. The dashboards are designed to quickly answer two questions:

Are my databases healthy?
Which ones need my attention?

From there, you can drill into resource usage, waits, and session activity to understand what's driving a change in performance.

With Database Hub, you can:

Get estate-wide visibility into health and performance across database types
Investigate the root cause of performance issues across many databases
Use AI-assisted analysis to find and explain issues faster

To learn more, see What is Database Hub in Fabric?

Why we built this

Monitoring SQL performance at scale often meant building and running your own monitoring stack. Before you could effectively answer, "Which of my databases need attention right now?" you typically had to:

Deploy and configure a collection resource, such as a watcher or an agent
Build a telemetry pipeline to move the data
Provision a data store, and then pay for it, secure it, and keep it running
Build dashboards on top of all of it
Repeat for every new server, database, or region

That's a lot of work before you see your first chart. And every step is another thing that can break, drift, or quietly stop collecting data.

Customers are also turning to AI to make sense of their database estate. They want an AI agent that can spot a performance problem, explain what's causing it, and recommend a fix. But an AI agent is only as good as the data it can reach. It operates best with one consistent source of performance data across every database, not a patchwork of tools and data stores.

We heard this feedback loud and clear from customers. You told us you love having at-scale dashboards and ownership of your performance data. You also told us that setting up a telemetry stack was time-consuming, scale limits got in the way, and running the data store added operational burden and cost overhead. One customer put it simply: they wanted to spend less time managing their telemetry infrastructure and more time managing and improving their databases.

Performance monitoring keeps the parts you valued and removes the infrastructure you had to manage. That's why it feeds Database Hub directly. You get one place to see your whole estate, and your AI agents get one consistent source of performance data.

No infrastructure to manage (or pay for)

With performance monitoring, there's no monitoring infrastructure for you to deploy, size, or run. It's all managed by Microsoft, with no scale limits on how many targets you can monitor.

Telemetry is collected close to the database engine and sent to a Microsoft-managed telemetry pipeline and data store. Access to that data is governed by Azure role-based access control (RBAC), so people only see telemetry for the resources they already have access to.

Consistent telemetry across your SQL estate

Performance monitoring collects the same core set of performance data across every supported SQL deployment, whether it runs in Azure, on-premises, or in another cloud. That means one mental model and one set of dashboards in Database Hub, instead of a different tool for every flavor of SQL.

The preview collects performance-related telemetry, including:

CPU and memory utilization
Wait statistics
Active sessions
Storage I/O and database storage utilization
Performance counters
Client connections
Database properties
Availability group, replica, and database replica health

Go beyond Database Hub with KQL

Database Hub covers the most common performance questions. When you need a view that Database Hub doesn't show, you can query the same telemetry directly with Kusto Query Language (KQL). The telemetry is available through a Microsoft-managed, RBAC-governed endpoint, so you don't need to create or pay for your own Azure Data Explorer cluster.

Use it to:

Build your own Real-Time Dashboards and reports
Connect tools you already use, such as Grafana or Power BI
Give an AI agent access to investigate performance across your estate

To get started, see Query performance monitoring telemetry. It includes the schema, connection steps, and ready-to-run starter queries.

Turn on performance monitoring

How you turn on performance monitoring depends on the resource type. For all of the steps in one place, see Enable performance monitoring for Microsoft SQL.

Resource type	How monitoring is enabled in preview	Step-by-step guidance
Azure SQL Database	Add an extended property to each database you want to monitor. You can also select Enable Performance Monitoring in Database Hub.	Azure SQL Database
Azure SQL Managed Instance (coming soon)	Coming soon	Coming soon
SQL Server on Azure VMs	Turn on a feature flag in the SQL IaaS Agent extension.	SQL Server on Azure VMs
SQL Server enabled by Azure Arc	On by default once the server is connected to Azure Arc.	SQL Server enabled by Azure Arc

To view performance monitoring data, you need:

The Reader role, or a role with higher privileges, on each subscription that contains the resources you want to view.
The Microsoft.AzureArcData resource provider registered on each subscription. For steps, see Register the Azure resource provider.

Availability

Performance monitoring is available in public preview in select Azure regions. For the current list of supported regions, see Regional availability and data handling.

Learn more

Announcing the public preview of Local Time Zone Support in Azure SQL Database

uc-msft — Mon, 28 Sep 2026 14:54:42 GMT

We are excited to announce the public preview of local time zone support in Azure SQL Database. You can now configure a time zone at the database level and override it for an individual session using T-SQL. This functionality allows applications to use current date and time values in their local time zone without adding an explicit conversion to every call.

Local time zone support simplifies migration of applications that rely on SQL Server's local time and supports databases serving different geographic regions. Azure SQL Database continues to use UTC by default. You choose whether to configure a database-wide time zone or apply a session-specific setting.

For more details on the functionality, see the feature announcement in the Azure SQL Dev corner.

More performance and flexibility for Azure SQL Managed Instance Business Critical

UrosMilanovic — Mon, 28 Sep 2026 13:45:49 GMT

Azure SQL Managed Instance Business Critical is designed for demanding, business-critical SQL Server workloads that require high performance, low latency, and high availability. We continue to invest in the service tier to deliver more performance while giving customers greater flexibility in how they configure resources for their workloads.

Today, we’re announcing two new improvements, generally available starting September 28, 2026:

Higher transaction log throughput for Business Critical
Flexible memory, enabling customers to add memory independently of vCores on Premium-series hardware

Together, these improvements build on our continued investments in Business Critical, helping customers get more performance from their configurations while giving them greater control over the resources their applications need.

Higher transaction log throughput

For write-intensive workloads, transaction log throughput can be an important performance dimension. Applications that generate large volumes of data modifications can reach transaction log throughput limits before reaching other compute or storage limits.

With this update, we are increasing transaction log throughput for Azure SQL Managed Instance Business Critical.

For Standard-series hardware:

Maximum log throughput increases from 96 to 160 MB/s
Per-vCore log throughput increases to 4.5 to 16 MB/s per vCore
Maximum log throughput is achieved with 10 vCores

For Premium-series and memory-optimized Premium-series hardware:

Per-vCore log throughput increases from 12 to 16 MB/s per vCore
Maximum log throughput of 192 MB/s is achieved with 12 vCores

Hardware	Log throughput per vCore	Maximum log throughput	vCores to reach maximum
Standard-series	16 MB/s	160 MB/s	10
Premium-series	16 MB/s	192 MB/s	12
Memory-optimized Premium-series	16 MB/s	192 MB/s	12

The increased throughput can improve the performance of workloads that generate significant transaction log activity, such as high-throughput OLTP applications, bulk data operations, and batch processing.

The higher per-vCore throughput is also important when sizing an instance. Customers no longer need a larger compute configuration simply to reach the maximum transaction log throughput available from the service tier.

With Standard-series hardware, 10 vCores are sufficient to reach the maximum 160 MB/s log throughput. With Premium-series and memory-optimized Premium-series hardware, 12 vCores are sufficient to reach the maximum 192 MB/s.

For workloads where transaction log throughput is the limiting resource, this provides more flexibility to select a compute configuration that better matches the application's actual CPU requirements.

Learn more about Business Critical resource limits.

Flexible memory is now generally available in Business Critical

Database performance isn't only about CPU and storage. Many SQL Server workloads are memory-intensive, and increasing memory has traditionally also meant increasing the number of vCores.

Flexible memory changes that.

Flexible memory allows you to increase the amount of memory allocated to Azure SQL Managed Instance without increasing the number of vCores.

Starting September 28, flexible memory is generally available for Azure SQL Managed Instance Business Critical on Premium-series hardware, for both locally redundant and zone-redundant instances.

This gives you an additional dimension for optimizing your instance configuration. Instead of increasing compute when your workload primarily needs more memory, you can configure a higher memory-to-vCore ratio while keeping the number of vCores unchanged.

Consider an application whose CPU requirements are already met by its current configuration but whose workload would benefit from more memory. Previously, obtaining more memory could mean increasing the vCore count as well. With flexible memory, you can add memory while maintaining the compute configuration that already meets the workload's CPU requirements.

Flexible memory can be used with both new and existing managed instances, giving you the ability to adjust your configuration as workload requirements evolve.

Learn more about flexible memory for Azure SQL Managed Instance.

More performance where you need it

Higher transaction log throughput and flexible memory address two different resource dimensions, but they follow the same principle: giving customers more control over the resources they need for their workloads.

A write-intensive application might require higher transaction log throughput without requiring significantly more CPU. With the new log throughput limits, that workload can achieve higher transaction log throughput at smaller vCore configurations.

A memory-intensive application might have sufficient CPU resources but require a larger memory allocation. Flexible memory allows additional memory to be configured without adding vCores simply to obtain more RAM.

These capabilities provide more options for aligning the configuration of Azure SQL Managed Instance with the performance characteristics of your application.

Continuing to improve Business Critical

These improvements build on a series of investments we have made in Azure SQL Managed Instance Business Critical. Our focus has been consistent: deliver more performance, provide greater flexibility in how instances are configured, and help customers optimize the cost of running demanding SQL Server workloads.

More performance and configuration flexibility

Previous Business Critical improvements increased performance and expanded the configuration options available to customers, providing greater flexibility when choosing the resources needed for demanding workloads.

These improvements included support for Premium-series and memory-optimized Premium-series hardware, expanding the choice of hardware configurations available for Business Critical workloads.

Learn more about the Business Critical improvements.

More storage without adding compute

We also improved the storage-to-vCore ratio for Business Critical, allowing customers to configure significantly more storage without increasing compute simply to meet their storage requirements.

Business Critical supports up to 16 TB of instance storage, providing substantially more freedom to size compute based on workload requirements rather than storage capacity alone.

For workloads that require substantial storage but comparatively fewer CPU resources, the improved storage-to-vCore ratio can reduce the number of vCores required for the same storage footprint, enabling compute cost savings of up to 50% in applicable configurations.

Learn how the improved storage-to-vCore ratio can reduce compute costs.

Better economics for zone-redundant Business Critical

We also expanded Azure Reservations support for zone-redundant Business Critical configurations, providing another way for customers with predictable workloads to optimize their costs.

Azure Reservations provide discounted compute pricing in exchange for a one-year or three-year commitment.

For zone-redundant Business Critical instances, customers can use reservations for both the standard compute charge and the zone-redundancy compute add-on by purchasing the corresponding vCore and vCore ZR reservation types.

Storage and SQL licensing are priced separately, and customers with eligible SQL Server licenses can use Azure Hybrid Benefit to reduce SQL Server licensing costs.

Learn about Azure Reservations for zone-redundant resources.

And we continue those improvements today

Higher transaction log throughput and generally available flexible memory build on this work.

The common theme is giving customers more control over the resources they need for their workloads:

More storage without having to add compute simply to increase storage capacity
More memory without having to add compute
Higher transaction log throughput at smaller vCore configurations
More options to optimize the cost of zone-redundant deployments

Together, these improvements make it easier to configure Business Critical around the actual requirements of your application, rather than increasing one resource simply to gain more of another.

Get started

Higher transaction log throughput and flexible memory for Azure SQL Managed Instance Business Critical are generally available starting September 28, 2026.

To learn more:

Review the Azure SQL Managed Instance resource limits
Learn more about flexible memory for Azure SQL Managed Instance
Explore previous Business Critical improvements
Learn how the improved storage-to-vCore ratio can reduce compute costs
Learn about Azure Reservations for zone-redundant resources

We’re excited to continue improving Azure SQL Managed Instance Business Critical and giving you more performance, flexibility, and control for your most demanding SQL Server workloads.

SQL Data Sync – the final phase of retirement

Mladen_Andzic — Wed, 09 Sep 2026 10:38:14 GMT

SQL Data Sync has served customers well for many years, and we recognize that many teams rely on it. As operational, security, and compliance requirements have continued to evolve, we are progressing through the previously announced retirement in a way that gives customers time and guidance to transition.

In 2024, we announced that SQL Data Sync will retire on September 30, 2027. As we enter the final year before retirement, we are moving to the next phase to help customers avoid new dependencies and focus on the transition.

What is changing

Starting on September 9, 2026, new SQL Data Sync deployments can no longer be created in Azure subscriptions that have not previously used the service.

This change affects only Azure subscriptions that have never used SQL Data Sync. If your subscription already uses the service, nothing changes for you: you can continue to create, modify, and manage sync groups and member databases throughout the remaining retirement period.

One year remains to complete transition

We announced SQL Data Sync retirement three years in advance to provide customers with time to assess their dependencies, select an appropriate alternative, and complete the transition before the service is retired.

With approximately one year remaining, we encourage customers who still rely on SQL Data Sync to begin or continue the transition work. We recognize that transitioning takes effort, and we are committed to helping you find the right fit. Depending on your topology, data volume, synchronization direction, and availability requirements, the transition can involve architectural evaluation, testing, and carefully planned execution.

How to check whether you are using SQL Data Sync

SQL Data Sync is organized around sync groups. Each sync group has an Azure SQL Database that serves as its hub database and one or more member databases. Member databases can be databases in Azure SQL Database or SQL Server instances.

To check an individual Azure SQL Database in the Azure portal, assuming you have a handful of them:

Sign in to the Azure portal.
Type “Azure SQL Database” in the search field and select the service
Select SQL databases from the menu
Open listed Azure SQL Databases one by one.
Under Data management, select Sync to other databases.
Any related sync groups will be listed.

If sync groups are listed, the database is configured as a SQL Data Sync hub. Review each sync group to identify its member databases, synchronization direction, schedule, and status.

Organizations with many subscriptions, logical servers, or databases can perform a broader inventory across their Azure SQL Database estate. Azure PowerShell and Azure SQL management REST API can help automate discovery of sync groups by iterating through Azure SQL Database resources in subscriptions of a tenant.

Choose an alternative based on your scenario

SQL Data Sync was built on an earlier generation of synchronization technology. Newer Azure capabilities support a broader range of security, performance, and operational characteristics, so retirement is a good opportunity to reassess your use cases, reduce legacy dependencies, and adopt a modern solution aligned with latest security practices and your workload's current requirements.

SQL Data Sync supports several scenarios, including synchronization between SQL Server and Azure SQL Database, distribution of data for reporting, and synchronization across regions. There is no single replacement that maps to every SQL Data Sync configuration, and the scenario-based guidance below maps each common configuration to a recommended path to help customers identify optimal path for each deployment.

The appropriate replacement depends on several factors:

Source and destination platforms
One-way or bidirectional synchronization
Acceptable synchronization latency
Number of databases and synchronization topology
Availability and disaster recovery requirements
Data transformation and orchestration needs
Data volume and throughput

Depending on your scenario, alternatives may include:

Azure Data Factory for scheduled, incremental, or orchestrated data movement.
Transactional replication for one-way data distribution from SQL Server to Azure SQL Database.
Always On availability groups or Managed Instance link for the reporting replicas of the entire database in SQL Server in Azure VM or Azure SQL Managed Instance, respectively.
Active geo-replication or read replicas for read-scale and regional availability scenarios.
Azure SQL trigger for Azure Functions for application-specific synchronization logic leveraging SQL binding.
Mirroring in Fabric for analytics scenarios that require continuous replication of operational data in Microsoft Fabric.

For detailed guidance organized by scenario and source and destination platform, see SQL Data Sync retirement: Migrate to alternative solutions.

There are two more recommended reads with detailed description of ADF-based alternative solutions:

Azure SQL Database Data Sync retirement: Migration scenarios and recommended alternatives

Azure SQL Data Sync Retirement: Migration Insights and Modern Alternatives

Recommended next steps

If your organization currently uses SQL Data Sync:

Inventory all SQL Data Sync deployments across your Azure subscriptions, including sync groups that are inactive.
Identify the hub databases, member databases, on-premises sync agents, and dependent applications associated with each deployment.
Document the business scenario, data flow direction, synchronization frequency, data throughput, latency and observability requirements, if you have not already done so.
Use the guidance to identify suitable alternatives for each deployment.
Configure and validate the replacement solution in a non-production environment. Temporarily disable Automatic Sync option for sync group during validation.
Fully remove SQL Data Sync resources after confirming that the replacement solution is operating successfully and that applications no longer depend on the existing sync groups.

If you have questions and have an Azure support plan, you can create a support request through the Azure portal. You can also ask questions through the Azure SQL Database community on Microsoft Q&A.

Summary

The SQL Data Sync retirement process is entering its final year. New SQL Data Sync deployments can no longer be created in Azure subscriptions that have not previously used the service. For subscriptions already using the service, functionality is unchanged, and sync groups can continue operating until the end of the retirement period.

SQL Data Sync will retire on September 30, 2027. If your organization still depends on the service, now is a good time to identify your deployments, finalize your replacement architecture, and complete the transition.

Understanding DevOps Auditing API Migration Behavior in Azure SQL Database

sravani-saluru — Wed, 23 Sep 2026 10:30:33 GMT

Background

Historically, DevOps Auditing could be configured through the server-level auditing API using the isDevopsAuditEnabled property under:

Microsoft.Sql/servers/auditingSettings

As Azure SQL auditing capabilities evolved, a dedicated resource was introduced specifically for DevOps Auditing:

Microsoft.Sql/servers/devOpsAuditingSettings

This dedicated API is now the supported approach for configuring DevOps Auditing.

The Question

Customers occasionally observe that setting isDevopsAuditEnabled=true continues to work on some servers but not on others.

A recent customer engagement highlighted this scenario where the same deployment was able to enable DevOps Auditing on most servers, while a smaller subset of servers ignored the setting even though the ARM operation completed successfully.

At first glance, this appears inconsistent. However, the behavior is expected.

How Backward Compatibility Works

Today, Azure SQL maintains backward compatibility for customers who still use the legacy auditing API.

The behavior is as follows:

The recommended and supported approach is to use the dedicated DevOps Auditing resource:

Microsoft.Sql/servers/devOpsAuditingSettings

2. The isDevopsAuditEnabled property under:

Microsoft.Sql/servers/auditingSettings

is no longer recommended for new implementations.

3. To preserve backward compatibility, the legacy property may continue to work for servers that have never been migrated to the new model.

4. Once the dedicated DevOps Auditing API is used on a server for the first time, that server is permanently marked as migrated.

5. After migration, the legacy isDevopsAuditEnabled property is no longer honoured for that server, even if it is supplied in subsequent requests.

Why Some Servers Behave Differently

Consider an environment with hundreds of Azure SQL servers managed through ARM templates or Azure Policy.

The deployment may successfully update:

{

"type": "Microsoft.Sql/servers/auditingSettings",

"properties": {

"isDevopsAuditEnabled": true

}

For servers that have never used the new DevOps Auditing resource, the setting may still take effect.

For servers that were previously configured through:

Microsoft.Sql/servers/devOpsAuditingSettings

the server is already considered migrated. In these cases, the request can complete successfully, but the legacy property is ignored and DevOps Auditing remains unchanged.

Recommended Action

Customers should migrate all automation, ARM templates, Bicep templates, Terraform deployments, and Azure Policies to use the dedicated DevOps Auditing resource:

Microsoft.Sql/servers/devOpsAuditingSettings

and avoid relying on the legacy isDevopsAuditEnabled property going forward.

Key Takeaway

If isDevopsAuditEnabled appears to work for some servers but not others, it is usually due to the server's migration state:

Not yet migrated → legacy flag may still work.

Already migrated → legacy flag is ignored.

Use Microsoft.SQL/servers/devOpsAuditingSettings for all future configurations.

This behavior allows Azure SQL to maintain backward compatibility while providing a clear migration path to the dedicated DevOps Auditing configuration model.

For the new API, refer documentation

Server DevOps Audit Settings - Create Or Update - REST API (Azure SQL Database) | Microsoft Learn

Server DevOps Audit Settings - Get - REST API (Azure SQL Database) | Microsoft Learn

Microsoft.Sql/servers/devOpsAuditingSettings - Bicep, ARM template & Terraform AzAPI reference | Microsoft Learn

ICYMI: New Azure SQL Foundations video series with GitHub samples

Anna Hoffman — Wed, 26 Aug 2026 12:41:16 GMT

Bob Ward and I recently released a series of videos, read more in the original blog post or go directly to the series on YouTube.

The Azure SQL Database Foundations series are four videos that take you from your first Hyperscale database to AI features running against your own operational data. We also included how to assess and migrate (with AI and skills!) to Hyperscale in the first place, and the common optimizations you should consider. Every episode ships with a repo, so you can follow along in your own environment instead of watching someone else’s terminal.

Introducing Simplified Regional Limits for Azure SQL Managed Instance

DjordjeJeremic — Mon, 12 Oct 2026 19:08:49 GMT

We are pleased to announce improvements to regional subscription limits for Azure SQL Managed Instance. These changes simplify subnet management and provide more granular control over vCore capacity across hardware generations.

What’s changing?

Two changes are now generally available:

Regional subnet limits are removed

Azure SQL Managed Instance no longer applies service-specific regional subnet limits. Instead, deployments are governed by the applicable Azure Resource Manager virtual networking limits.

This simplifies resource planning and removes the need to monitor or request increases for Azure SQL Managed Instance regional subnet limits.

Regional vCore limits are now hardware-generation specific

Regional vCore limits are now managed separately for each supported hardware generation:

• Standard Series

• Premium Series

• Premium Series Memory Optimized

Previously, a single regional vCore limit applied across hardware generations. With hardware-generation-specific limits, customers can request additional capacity only for the hardware generation required by their workloads.

For example, if you need additional Premium Series capacity in a region, you can request an increase for Premium Series without changing the limits for Standard Series or Premium Series Memory Optimized.

Check vCore quota limit and usage with PowerShell

Use the Subscription Usages - Get REST API to retrieve the current vCore quota limit and consumption for Azure SQL Managed Instance in a subscription and region. Query each hardware generation separately by specifying its usage name:

Hardware generation	Usage name
Standard-series (Gen5)	SubscriptionSQLManagedInstanceStandardSeriesVCoreQuota
Premium-series	SubscriptionSQLManagedInstancePremiumSeriesVCoreQuota
Memory optimized premium-series	SubscriptionSQLManagedInstancePremiumSeriesMemoryOptimizedVCoreQuota

Run the following script in a PowerShell session with the Az module installed, or in Azure Cloud Shell using PowerShell. Your account needs permission to read subscription usage, such as the Reader role assigned at subscription scope.

Replace <subscription-id> with your subscription ID, set $location to the Azure region name (for example, eastus), and set $usageName to one of the values in the table. If you're already signed in through Cloud Shell, omit Connect-AzAccount.

$subscriptionId = "<subscription-id>" $location = "eastus" $usageName = "SubscriptionSQLManagedInstanceStandardSeriesVCoreQuota" Connect-AzAccount -ErrorAction Stop | Out-Null Set-AzContext -SubscriptionId $subscriptionId -ErrorAction Stop | Out-Null $path = "/subscriptions/$subscriptionId/providers/Microsoft.Sql/locations/$location/usages/${usageName}?api-version=2025-01-01" $response = Invoke-AzRestMethod -Method GET -Path $path -ErrorAction Stop if ($response.StatusCode -ne 200) { throw "Unable to retrieve quota usage. HTTP $($response.StatusCode): $($response.Content)" } $response.Content | ConvertFrom-Json -ErrorAction Stop | ConvertTo-Json -Depth 10

Example output (excerpt; values are illustrative):

{ "name": "SubscriptionSQLManagedInstanceStandardSeriesVCoreQuota", "properties": { "currentValue": 80, "limit": 320, "unit": "SubscriptionSQLManagedInstanceStandardSeriesVCoreQuota" } }

In this example, `properties.currentValue` is the current quota consumption: 80 vCore units. `properties.limit` is the current quota limit: 320 vCore units. The remaining quota is `limit - currentValue`, or 240 vCore units, for standard-series hardware in the specified subscription and region.

The previously used VCoreQuota usage name, which represented a single regional quota shared across all hardware generations, is being deprecated in favor of hardware-generation-specific quotas. Use the usage names listed in the table above to retrieve the quota limit and consumption for each hardware generation.

What does this mean for existing customers?

Existing regional vCore limits will be automatically converted to hardware-generation-specific limits. No customer action is required.

Your new limits can be viewed and managed through the Azure portal. If the default limit for a hardware generation is insufficient for a planned deployment, you can request an increase for that specific hardware generation.

New hardware generation specific vCore limits apply to both single-zone and multi-zone (Zone Redundant) Managed Instance deployments.

Benefits

These improvements provide:

• Simpler quota management through the removal of service-specific regional subnet limits.

• Better granularity with separate vCore limits for each hardware generation.

• Greater flexibility to request capacity only where it is needed.

• A seamless transition with automatic conversion of existing limits.

To learn more about Azure SQL Managed Instance resource limits and how to request an increase, see Request quota increases for Azure SQL Database and SQL Managed Instance.

We hope these changes make planning and scaling your Azure SQL Managed Instance deployments simpler and more flexible.

Public Preview: Zone-Redundant Next-Gen General Purpose for Azure SQL Managed Instance

UrosMilanovic — Tue, 18 Aug 2026 13:30:23 GMT

Customers no longer need to choose between the latest General Purpose architecture and zone-level resiliency. With the public preview of zone redundancy for Next-Generation General Purpose Azure SQL Managed Instance, organizations can now take advantage of all the benefits of Next-Generation General Purpose while meeting strict high availability and compliance requirements through Availability Zone protection.

When Next-Generation General Purpose became generally available, it introduced a modernized General Purpose architecture delivering improved performance, greater scalability, enhanced flexibility, and better price-performance for Azure SQL Managed Instance workloads. Since then, customers have increasingly adopted the architecture to modernize SQL workloads, consolidate databases, and optimize total cost of ownership.

Today, we're extending those benefits to customers who require zone-level resiliency. With zone redundancy now available in public preview, customers can realize all the advantages of Next-Generation General Purpose while meeting the same zone-level availability requirements previously available only with Classic General Purpose.

This milestone brings full high-availability parity between Classic General Purpose and Next-Generation General Purpose, removing one of the last major reasons for customers to remain on the previous architecture.

Closing the last major gap

Zone redundancy has consistently been one of the most requested capabilities for Next-Generation General Purpose.

Since its introduction, Next-Generation General Purpose has provided substantial improvements in scalability and flexibility, including support for up to 128 vCores, up to 32 TB of storage, up to 500 databases per instance, configurable IOPS, and flexible memory sizing. Customers can optimize resources for their workload requirements while continuing to benefit from the simplicity and compatibility of Azure SQL Managed Instance.

With today's announcement, these capabilities can now be combined with zone-level resiliency, enabling customers to deploy highly available business-critical workloads on the latest General Purpose architecture without compromise.

In addition, the flexible memory option for zone-redundant Next-Generation General Purpose instances is also available in public preview, providing even greater flexibility to balance performance requirements and infrastructure costs.

Built-in high availability, now with Zone-level protection

Azure SQL Managed Instance has always been designed for high availability.

Next-Generation General Purpose delivers built-in high availability through its distributed architecture, leveraging Service Fabric together with fault domains and update domains to minimize the impact of hardware failures, software updates, and planned maintenance events. This architecture enables applications to remain available even during infrastructure events and maintenance operations.

As a result, single-zone deployments provide a 99.99% availability SLA.

For organizations with more demanding availability requirements, zone redundancy distributes service components across multiple Availability Zones within a region. This provides protection against zone-level failures and increases the availability SLA to 99.995%.

While many workloads are well served by single-zone deployments, organizations in regulated industries and mission-critical environments often require zone-redundant architectures as part of compliance, operational resilience, or business continuity requirements. With today's preview, these customers can now adopt Next-Generation General Purpose without sacrificing those requirements.

Regional availability

Zone redundancy for Next-Generation General Purpose is available in public preview in all regions where the underlying ESAN infrastructure supports zone-redundant deployments.

For the latest list of supported regions, check out the documentation page containing the regions where Elastic SAN is currently available and the supported redundancy options.

Regions that do not yet support ESAN-based zone redundancy are not included in the preview at this time. Additional regions will become available as platform support expands.

Upgrading existing deployments

Whether you are already running Next-Generation General Purpose or remain on Classic General Purpose, adopting zone-redundant Next-Generation General Purpose is designed to be straightforward and transparent.

Enable zone redundancy on existing Next-gen General Purpose instances

Customers already running Next-Generation General Purpose can enable zone redundancy directly on existing instances and immediately benefit from enhanced resiliency and a higher availability SLA.

Move from classic General Purpose zone-redundant to Next-generation General Purpose zone-redundant

Customers currently running Classic General Purpose with zone redundancy can migrate to Next-Generation General Purpose while preserving zone-level resiliency and gaining access to the latest platform architecture, resource flexibility, and scalability improvements.

This provides a natural modernization path for existing deployments and allows customers to standardize on the future architecture of the General Purpose tier.

Online operation with a short failover

Enabling zone redundancy or migrating between architectures is performed as an online management operation.

During most of the operation, Azure SQL Managed Instance provisions and synchronizes the new infrastructure while the existing deployment continues serving application traffic. Near the end of the operation, a brief failover occurs as client connections are switched from the existing infrastructure to the newly provisioned environment.

For more information about management operations, expected behavior, and application connectivity considerations, see management operations overview article.

Protecting workloads beyond a single region

For customers running in regions where zone redundancy is not currently available, or for customers seeking protection from broader regional outages, Failover Groups remain the recommended solution.

Failover Groups enable disaster recovery across Azure regions by maintaining a secondary managed instance and providing automatic or manual failover capabilities when needed. This approach helps organizations meet business continuity objectives even when Availability Zone protection is unavailable or when protection from regional outages is required.

Optimize disaster recovery costs with License Free failover rights

Customers implementing disaster recovery through Failover Groups can further optimize costs through Azure SQL License Free failover rights.

When the secondary managed instance is maintained exclusively for standby disaster recovery purposes and is not used for read-only workloads, SQL Server licensing costs do not apply to the secondary environment. Customers pay only for the compute resources required to maintain disaster recovery readiness, helping reduce overall total cost of ownership.

Planning costs

The Azure SQL Managed Instance pricing page and Azure Pricing Calculator have been updated to include the latest zone-redundant Next-Generation General Purpose offerings.

These tools can help customers evaluate deployment options, compare availability architectures, and estimate costs associated with zone redundancy and disaster recovery configurations.

Get started

Zone redundancy for Next-Generation General Purpose marks the completion of an important milestone in the evolution of Azure SQL Managed Instance.

Customers can now combine the performance, scalability, flexibility, and operational advantages of Next-Generation General Purpose with zone-level resiliency and a 99.995% availability SLA. Whether deploying new workloads, enabling zone redundancy on existing Next-Generation General Purpose instances, or modernizing Classic General Purpose deployments, organizations now have a clear path to adopting the latest General Purpose architecture without compromise.

Learn more

What is Azure SQL Managed Instance

Availability through local and zone redundancy - Azure SQL Managed Instance

Flexible memory - Azure SQL Managed Instance

Next-gen General Purpose – official documentation

Try Azure SQL Managed Instance for free

Accelerate SQL Server Migration to Azure with Azure Arc

Analyzing the Economic Benefits of Microsoft Azure SQL Managed Instance

How 3 customers are driving change with migration to Azure SQL

SQLCon is Back: 5 Reasons to Attend the European Microsoft Fabric + SQL Community Conference

RieMerritt — Tue, 11 Aug 2026 14:10:55 GMT

5 Reasons to Attend the European Microsoft Fabric + SQL Community Conference

This year the SQL community joins Fabric in Europe for the first time at the Microsoft Fabric + SQL Community Conference happening September 28th - October 1st in Barcelona, Spain. Hear the latest announcements and roadmap directly from Microsoft leaders. With a full week of deep technical sessions and workshops covering the topics you care about most across and see how we’re helping solve your most pressing data challenges, from strengthening data sovereignty to powering agentic AI and unlocking trusted, actionable intelligence.

And while there’s no shortage of topics, here are a couple of things we’re the most excited about heading to Barcelona:

Unify your data (conference) experience

With one registration, this event doubles your opportunity to sharpen your skillset with 130+ expert led sessions, workshops, and keynotes coming together in one high- impact week. Mix and match sessions to best meet your learning goals while you move seamlessly across tracks, visit the shared expo, and connect with peers in the community hub, all under one roof.

The ultimate SQL experience, like only Microsoft can deliver

With more than 25 dedicated SQL sessions, whether you’re a DBA or, a developer building AI apps, you can create your custom agenda with the topics you care about most. Pre-day programming is for the builders; bring your laptop and start your week with any of our full- day SQL workshops for the demos, practical guidance, and repeatable patterns you can start using immediately. Tuesday kicks off the official event with our opening keynote, three corenotes, and general sessions focused on SQL Server 2025, Azure SQL, and SQL in Fabric. Learn the latest in performance, tuning and tools like SSMS and VS Code delivered directly from SQL experts, MVPs, and community leaders.

Ready to start building your agenda? Try our new session planner to curate your schedule based on your interests.

The backdrop: Barcelona

This year’s conference takes place in the historic, vibrant city of Barcelona, set along the Mediterranean Sea, the ideal setting for the first European SQLCon. When you’re ready for a break, you’re only a 15-minute ride away from the city center, perfect for exploring Gaudí’s iconic architecture or enjoying some local bites. Don’t miss the wrap- up celebration taking place in Barcelona’s exclusive Sutton Club.

Community Connection

SQLCon is more than just sessions; we’re bringing together more than 4,000 of the most dedicated Microsoft community members together for a week of endless connection opportunities. The Community Hub will bring some of our most popular experiences to life, from in-person meetups and user group connections to hands-on learning and certification opportunities all designed to help you grow your skills and expand your network.

Launching Soon: SQLCon TV

Enjoyed catching all the behind-the-scenes action on FabCon TV? In Barcelona we’ll bring SQLCon TV to the stage, with the content, demos, and interviews every SQL fan will want to see.

Save your spot today. The earlier you register, the more opportunities you have to take advantage of early pricing specials. See you in Barcelona!

HostNameInCertificate changes in Azure SQL Managed Instance affecting client connectivity

ZoranRilak — Wed, 05 Aug 2026 11:18:19 GMT

Azure SQL Managed Instance is changing how TLS certificates are stored and handled in managed instances. One of those certificates was specifically tailored to support migration scenarios where SQL clients retain the server name, while updating its record in DNS so that it resolves to the managed instance instead. This was supported with an instance certificate that we are now replacing in favor of a more complete solution.

When does this change take effect?

New managed instances already contain certificates with a reduced list of SANs. Existing managed instances will have their certificates revoked and replaced with reduced certificates during the first week of August 2026.

Am I affected?

Your SQL clients and applications might be unable to connect if all of the below is true:

The client is connecting over the VNet-local endpoint, and
The client attempts to establish a Redirect connection, and
Client settings contain the HostNameInCertificate connection parameter.

The exact error message depends on your application, client, and driver. For example:

The target principal name is incorrect.

The certificate chain was issued by an authority that is not trusted.

The certificate's CN name does not match the passed value.

The remote certificate is invalid according to the validation procedure.

Failed to validate the server name in a certificate

hostname verification failed

certificate verify failed: Hostname mismatch

My clients are affected. What should I do?

If your clients are affected, find an appropriate solution in the table below.

If the client is...	Solution
Connecting to the managed instance's VNet-local endpoint with Redirect using the instance's original VNet-local domain name	Remove HostNameInCertificate from client's connection string; or Deploy a private endpoint and ensure your client is connecting to it.
Connecting to the managed instance’s VNet-local endpoint with Redirect using a different domain name (for example, via DNS CNAME)	Set the instance’s connection type to Proxy; or Deploy a private endpoint and ensure your client is connecting to it.
Connecting via private endpoint	No action is needed.
Connecting via public endpoint	No action is needed.
Connecting with Proxy connection type	No action is needed.

What else should I know?

Microsoft recommends you adhere to the security best practices for data in flight:

Only allow network access to known networks and hosts; see Connecting to a managed instance.
Authorize using safe credentials, ideally by using Microsoft Entra where possible.
Always use TLS encryption (Encrypt=Strict or Encrypt=Mandatory).
Monitor suspicious network activity throughout your network topology.
Follow the principle of least privilege.
Ensure that your SQL clients and applications have a network path to fetch the latest CRL and/or connect to OCSP for certificate validation.

Announcing Automatic Backup Immutability for Azure SQL Database and Azure SQL Managed Instance

Dinakar-Nethi — Tue, 04 Aug 2026 18:42:26 GMT

Built-in protection for your most recent backups - enabled automatically

Today, we're excited to announce General Availability of automatic backup immutability up to the most recent 7 days of point-in-time restore (PITR) backups in Azure SQL Database and Azure SQL Managed Instance, at no additional cost.

With this release, up to most recent 7 days of backups are automatically protected with immutability by default, regardless of your configured PITR retention period. No configuration changes, policy creation, or administrative action are required.

This enhancement provides an additional layer of protection for one of your most critical recovery assets - your backups.

Why backup immutability matters

Cyberattacks continue to evolve, with ransomware increasingly targeting not only production data, but also backup systems. Attackers understand that if backups can be deleted, modified, or corrupted, recovery becomes significantly more difficult and costly.

Traditional backup strategies focus on creating recoverable copies of data. Modern cyber-resilience strategies go further by ensuring those backups themselves cannot be altered or removed during a protected period.

Immutable backups help ensure that recovery points remain available when you need them most - even in the face of malicious actions, accidental deletion, or compromised administrative credentials.

What is changing?

Starting with this release:

Up to the most recent 7 days of Azure SQL Database and Azure SQL Managed Instance PITR backups are automatically protected by immutability

Protection is enabled by default for all databases, with no additional cost

No configuration or onboarding is required

Protection applies regardless of the database's configured PITR retention setting

Because this capability is built directly into the Azure SQL backup service, customers automatically benefit from stronger protection without changing existing backup, restore, or operational workflows.

Designed for modern cyber resilience

Organizations across industries increasingly require stronger safeguards around backup data as part of broader cyber-resilience programs.

Automatic backup immutability helps customers:

Improve protection against ransomware attacks

Reduce the risk of accidental backup deletion

Strengthen recovery readiness

Increase confidence that recent recovery points remain available during an incident

Simplify adoption of immutable backup practices without additional deployment effort

This capability is particularly valuable because the backups most often used during recovery operations are typically the most recent ones.

Supporting compliance and governance requirements

Many industries must maintain records in a protected, tamper-resistant manner to satisfy regulatory and governance requirements.

Azure Storage immutable storage capabilities have been validated for compliance scenarios involving requirements such as:

SEC Rule 17a-4(f)

CFTC Rule 1.31(d)

FINRA record-retention requirements

These regulations commonly require records to be retained in a nonerasable, non-rewritable format for a defined period of time. Azure immutable storage uses a Write Once, Read Many (WORM) model that helps organizations meet these requirements. 

Azure SQL database backups leverage this WORM capability from Azure storage to achieve immutability for the backups. While compliance requirements vary by organization and jurisdiction, automatic backup immutability provides an additional foundational control that can support broader security, governance, and resilience objectives.

No additional complexity

One of our goals with this release is to deliver stronger security without increasing operational burden.

You don't need to:

Create immutability policies

Configure storage accounts

Manage retention locks

Extract data

The protection is integrated directly into the Azure SQL managed backup service and works automatically for all Azure SQL Database and Azure SQL Managed Instance databases.

Pricing and Availability

Automatic backup immutability up to the most recent 7 days of point-in-time restore (PITR) backups is available for all Azure SQL Database and Azure SQL Managed Instance databases.

There is no additional cost to use this capability. The protection is built into the Azure SQL managed backup service and is automatically applied to the most recent 7 days of backups. No configuration, policy management, or separate licensing is required.

By enabling immutable protection by default and at no additional charge, Azure SQL helps customers strengthen their cyber-resilience posture, improve protection against ransomware and accidental deletion, and gain the benefits of immutable backups without added operational complexity.

Building on Azure SQL's data protection foundation

Automatic backup immutability is the latest enhancement in Azure SQL's ongoing investment in data protection, security, and business continuity.

By combining automated backups, point-in-time restore capabilities, geo-redundant backup options, soft delete protection for your Azure SQL logical server and now automatic backup immutability for recent backups, Azure SQL continues to help organizations strengthen their resilience against both operational accidents and modern cyber threats.

This is just the beginning. Azure SQL hyperscale backup immutability and a host of other additional capabilities are coming soon.

FAQs

Q: What is changing?

A: Microsoft Azure SQL will start protecting the short-term retention backups for all Azure SQL DB and Azure SQL managed instance databases with immutability to protect against ransomware attacks.

Q: Are all my backups protected?

A: In this release, up to most recent 7 days of short-term retention backups are immutable, regardless of the configured retention period. For example, if the configured retention period is 7 or less, then all the backups are immutable. If the configured retention period is 35 days, then the most recent 7 days of backups are immutable.

Q: Is there any additional cost for this feature?

A: No. Immutability for the backups is being provided as a security feature natively.

Q: When will this be available?

A: The code to enable immutable policy is already in progress in all Azure regions worldwide. In the next few weeks all backups will be on immutable storage.

Q: Do I need to do anything to enable/configure immutability?

A: No. There is no action needed on your end. The backups will automatically be immutable once the enablement is complete.

Q: How can I verify if my backups are immutable?

A: In a future release, immutability status will be exposed as a database property.

Q: How can I get immutability for my backups beyond 7 days?

A: In this release backups up to most recent 7 days are immutable. Immutability for additional retention period will be added in a future release.

Limitations

Immutability for Azure SQL hyperscale is not included in this release but will be available soon.

Learn more

To learn more about immutable storage concepts and WORM (Write Once, Read Many) protection in Azure, see:

https://learn.microsoft.com/azure/storage/blobs/immutable-storage-overview

We are excited to bring this protection to every Azure SQL Database and Azure SQL Managed Instance customer automatically, helping you improve backup security and recovery readiness with no additional effort.

Documentation updates

More details at https://aka.ms/auto-immutability 

Looking ahead

We are just getting started on this journey of ransomware protection. Additional flexibility and configuration options coming in future releases.

Regex-based dynamic data masking in Azure SQL Database (preview)

MadhumitaTripathyMSFT — Thu, 23 Jul 2026 06:48:35 GMT

Azure SQL Database introduces Regex-based dynamic data masking, a new capability that enables flexible, pattern-driven masking for string-based columns using regular expressions through the T‑SQL REGEXP_REPLACE() function. This feature extends Dynamic Data Masking beyond built-in masking functions, giving you precise control over which portions of sensitive data are masked and which remain visible, helping preserve data utility while meeting business and compliance requirements.

This capability is especially useful when working with structured data patterns—such as emails, phone numbers, or identifiers—where teams need to preserve specific visible segments while masking sensitive parts, and where built-in masks may be rigid for some business workflows.

Why this matters

Dynamic Data Masking helps reduce accidental exposure of sensitive data by obfuscating values in query results for nonprivileged users, while keeping the original data intact in the database. However, existing built-in masking functions—such as default(), email(), random(), partial(), and datetime()—apply fixed patterns. These patterns cannot be customized, and may not be suitable for some of the real-world scenarios.

For example, the built-in email() mask always transforms an address like alice.johnson@example.com into aXXX@XXXX.com, fully obscuring the domain name. In many operational scenarios, retaining the domain name is important for troubleshooting, routing, or business logic.

Regex-based dynamic data masking addresses this gap by enabling precision masking without sacrificing usability.

What’s new with regex-based masking

Regex-based DDM allows you to define custom, pattern-driven masking rules using regular expressions. By leveraging the native REGEXP_REPLACE function in Azure SQL Database, you can precisely specify which parts of a string to mask and which to preserve—centrally enforced in the database layer.

This approach supports variable-length and structured string data, enabling more precise and flexible data masking rules.

Practical scenarios

Regex-based masking enables common customer scenarios that are difficult to address with fixed masks:

Mask email usernames while preserving domains
alice.johnson@example.com → ****@example.com
Preserve country codes in phone numbers
+1-4155552671 → +1-XXXXXXXXXX
+44-7911123456 → +44-XXXXXXXXXX
Mask structured identifiers consistently
Hide sensitive portions of national IDs or custom identifiers while keeping recognizable structure for support and auditing workflows. For example: AB-1234-5678 → AB-****-5678

Example

The following example creates a table CustomerDetails with regex-based masking applied on Phone_Number and Email columns. The phone number mask preserves the country code and replaces the remaining digits with xxxx, and the email mask conceals the username while retaining the domain name.

-- Drop the CustomerDetails table if it exists

DROP TABLE IF EXISTS Data.CustomerDetails;

-- Create a CustomerDetails table under a schema

CREATE TABLE Data.CustomerDetails (

ID INT IDENTITY(1,1) PRIMARY KEY,

Name varchar(30),

Phone_Number varchar(30) MASKED WITH (FUNCTION = 'REGEXP_REPLACE("(\+\d{1,3})(?:[ -.]?\d){7,14}","(\1)-xxxx")'),

Email varchar(255) MASKED WITH (FUNCTION = 'REGEXP_REPLACE("([a-zA-Z0-9._%+-]+)(@+)([a-zA-Z0-9.-]+)(\.)(\w)","*****\2\3\4\5")')

);

-- Insert some dummy records to CustomerDetails table

INSERT INTO Data.CustomerDetails (Name, Phone_Number, Email) VALUES

('Alice Johnson', '+1 202-555-0123', 'alice.johnson@example.com'),

('Bob Smith', '+1 415-555-0198', 'bob.smith@contoso.com');

-- Create a test user

CREATE USER SupportEngineer WITHOUT LOGIN;

-- Grant read permission on CustomerDetails to SupportEngineer

GRANT SELECT ON Data.CustomerDetails TO SupportEngineer;

-- Query CustomerDetails table as SupportEngineer

EXECUTE AS USER = 'SupportEngineer';

SELECT * FROM Data.CustomerDetails;

REVERT;

Public Preview notice

Important
Regex-based dynamic data masking is currently in Preview for Azure SQL Database. Preview features are provided for evaluation purposes and are subject to the Preview Terms Of Use | Microsoft Azure.

Azure SQL Database is the first SQL offering to receive this feature, with additional SQL platforms planned in the future.

How to get started

To learn more and access sample scripts, refer to the official documentation Regex-based dynamic data masking (preview) - Azure SQL Database | Microsoft Learn

Try Regex-based dynamic data masking in your dev or test environment and tell us what works—and what doesn’t!

Tell us what you need next in Data Masking

Share your ideas through Azure SQL feedback forum.

Disclaimer: The examples in this article use fictional customer records created solely for demonstration and testing purposes. No real customer data is included.

Recently released: Updates to SQL projects in SSMS, VS Code, and SqlPackage

DrewSkwiersKoballa — Mon, 20 Jul 2026 12:45:00 GMT

Your database should be part of the same development process as the rest of your application, with source control and automation for validation and deployment. Recent releases of SQL Server Management Studio (SSMS), the SQL Database Projects extension for Visual Studio Code, SqlPackage, and the Microsoft.Build.Sql SDK add capabilities for the SQL projects ecosystem focused on developing, evolving, and deploying SQL databases.

Whether you are starting from an existing database, adding a database to a deployment pipeline, or refining a mature SQL project, the following updates make incorporating your database with your overall DevOps strategy more efficient.

System database references in SSMS

SSMS 22.8 adds system database references for SQL projects. Database references let a project use objects defined outside its local source files, whether those objects are in the same database or another database. The new system database packages for master and msdb let you reference system objects without manually managing the associated database artifacts.

Add a package reference from the command line with dotnet add package. For example, add the SQL Server 2025 master database package:

dotnet add package Microsoft.SqlServer.Dacpacs.Master --version 170.0.4

System database references can also be viewed and added from Solution Explorer in SSMS 22.8. Because the system database references are done through package references, no additional configuration is required to build the project with the .NET SDK in CI/CD pipelines.

Enabling projects to reference system objects with database references

Other recent SSMS releases added additional capabilities across the SQL project lifecycle through the Database DevOps (preview) workload. When you create a project, select its target platform in the new project dialog. The target platform determines the Microsoft SQL version against which the project validates syntax. After creating a project, use the project properties editor to change the target platform, configure code analysis, and define SQLCMD variables. SQLCMD variables resolve only at deployment time, allowing deployment-specific behavior without changing the project source.

New SQL project dialog in SQL Server Management Studio 22.8

SSMS 22.7 introduced schema compare and SQL formatting. Learn more in Power up in SSMS 22.7: Schema compare and SQL formatting

Schema compare in SSMS gives an object-level view of differences between databases and projects

Update to SSMS 22.8 and explore the SSMS 22 release notes and database references documentation.

SQL projects in Visual Studio Code

The 1.6.2 release of the SQL Database Projects extension for Visual Studio Code continues to improve the SQL project development experience in the cross-platform and mutli-functional VS Code environment. Install or update to version 1.6.2 to use the latest capabilities.

Project IntelliSense suggests object names from your SQL project model and enables Go to Definition and refactoring actions. When you refactor an object, Visual Studio Code updates the local `.sql` files and records the change in refactorlog.xml. Deploying your SQL project from an IDE or CLI, including Visual Studio Code and SqlPackage, uses this log to apply "sp_rename" and "ALTER SCHEMA ... TRANSFER" when required. This preserves the intent of your change during deployment instead of treating a renamed object as a drop and create operation. For more details on how SQL projects track and deploy these changes, see the SQL projects refactoring documentation.

Review the cascade of changes when updating the name of a table in a SQL project

When you create an object through SQL project explorer, the extension can automatically organize its file by schema and object type. This organizational pattern is the most prevalent standard, although some teams have alternative structures. To manually organize the files only, set "sqlDatabaseProjects.autoCreateFolders" to false in Visual Studio Code settings.

Extract an existing database to a SQL project with the SqlPackage CLI

The 170.4 release of SqlPackage in June 2026 adds a one-command path to turn an existing database into its full code definition. Set the ExtractTarget property to SqlProject during extract to reverse engineer the database into a Microsoft.Build.Sql project instead of the default .dacpac output format. The generated project contains individual .sql files for database objects and a .sqlproj file for database-level settings.

The generated SQL project can be iteratively developed, compiled to a .dacpac with dotnet build, or checked into source control as the foundation for database CI/CD.

For example, use the following command to create a SQL project from a database connection string in the `AdventureWorks` folder:

sqlpackage /a:extract /scs:"yourconnectionstring" /tf:AdventureWorks /p:ExtractTarget=SqlProject

The generated project is identical to the same SQL project you would create from that database in a graphical development environment:

AdventureWorks extracted to a SQL project, automatically organized by schema and objec type

For the complete release details, see the SqlPackage release notes.

Database settings in the Microsoft.Build.Sql project SDK

Microsoft.Build.Sql SDK 2.2.0, released with DacFx 170.4 in June 2026, adds support for automatic index compaction. This database-level feature is in preview for Azure SQL Database and SQL database in Fabric, where it compacts indexes in the background with minimal overhead. For more information, see Stop defragmenting and start living: Introducing auto index compaction

SQL projects can define database-level settings as properties in the .sqlproj file, including:

Change tracking
Query Store stale query threshold
Compatibility mode

Microsoft.Build.Sql 2.2.0 adds the AutomaticIndexCompaction property so you can enable or disable automatic index compaction as part of a SQL project deployment. Database settings in the project file make these deployment decisions visible in source control and repeatable across your environments. Review the SQL projects properties documentation for more available settings.

Provide feedback and learn more

To learn about the future planned work and avenues for feedback across the SQL projects ecosystem, visit the SQL projects roadmap.

Use Microsoft.Build.Sql projects to branch, build, commit, and deploy your database. Get started from an existing database or create a new SQL project. Learn more about SQL projects as part of CI/CD in Azure DevOps from a recent blog post in Azure SQL Dev Corner and associated Data Exposed episode.

Generally Available: SQL Migration to SQL Server on Azure Virtual Machines in Azure Architecture

danimir — Tue, 14 Jul 2026 15:01:52 GMT

One Migration Experience, More Flexibility

Modernizing SQL Server estates is rarely a single-step journey. Organizations often operate across on-premises, hybrid, and cloud environments while balancing application dependencies, operational requirements, and modernization goals. SQL Server migration enabled by Azure Arc simplifies this process by bringing migration activities into a single experience in the Azure portal.

With the July 2026 release, we are announcing General Availability of SQL Server on Azure Virtual Machines as a migration target in Azure Arc, allowing customers to have a greater flexibility to choose Azure destination that best aligns with to your needs without introducing additional tools or migration processes.

Whether migrating to the fully managed Azure SQL Managed Instance service or to SQL Server running on Azure VMs, the experience remains consistent and familiar.

Unified Migration Workflow

A key benefit of SQL Server migration enabled by Azure Arc is that the entire migration lifecycle is managed from a single tool in Azure portal.

After a SQL Server instance is enabled by Azure Arc, customers can:

Assess migration readiness
Select a migration target
Configure migration settings
Monitor migration progress
Validate results
Perform final cutover

All of these activities are performed directly from the Azure portal using a guided workflow designed to simplify migration planning and execution.

The prerequisite remains unchanged: source SQL Server instances must be enabled by Azure Arc before migration can begin. The result is a flexible, scalable, and consistent migration experience that supports hybrid realities, reduces operational overhead, and helps customers modernize SQL Server estates at their own pace.

Consistent Experience Across Azure SQL Targets

Migration to SQL Server on Azure Virtual Machines follows the same operational model already available for Azure SQL Managed Instance migration scenarios.

Customers use the same migration dashboard, monitoring experience, and guided workflow regardless of the destination. This consistency reduces learning curves, simplifies operational processes, and enables teams to select the most appropriate Azure SQL platform without changing migration methodology.

Online Migration Using Backup and Log Shipping

Migration to SQL Server on Azure Virtual Machines uses backup and restore with log shipping to support online migration scenarios while minimizing downtime.

The process begins with a full database backup that is restored to the target SQL Server instance running on an Azure Virtual Machine. Transaction log backups that are uploaded continuously by your workflows to Azure Blob Storage are continuously applied to the target database, keeping it closely synchronized with the source environment.

Azure Blob Storage serves as the intermediary staging location between source and target systems. To support efficient data movement and restore operations, both the Azure Blob Storage account and the target SQL Server on Azure Virtual Machines must reside in the same Azure region.

Within the Azure Arc migration experience, customers select the Azure Blob Storage container that stores the backup files. Azure Arc automatically restores the full backup and continuously applies transaction log backups as they become available. Customers are responsible for configuring and maintaining the continuous upload of transaction log backups to Azure Blob Storage.

Customer-Controlled Cutover

When the customer is ready to complete migration, upon customer initiated cutover, Azure Arc performs the final synchronization by applying the last uploaded backup and bringing the target database online.

This approach gives organizations full control over the migration timeline and cutover window, allowing downtime to be planned according to business requirements while reducing operational complexity.

Learn More

To learn more about SQL Server migration enabled by Azure Arc, see: Migration Overview

For information about migrating to SQL Server in Azure VM, see: Migrate to SQL Server in Azure VM

3 Reasons Enterprise SQL Server Migrations Slow Down - and How to Avoid Them

dhanMMS — Tue, 30 Jun 2026 23:45:00 GMT

Summary

Many of Enterprises around the globe have relied on SQL Server for over 3 decades to run their mission critical business applications. Their SQL Server estates face pressure from downtime risk, cost volatility, end of support timelines and modernization demands. As these customers get ready to modernize their data to use the latest capabilities of A.I and cloud native application trends, they want to migrate and modernize their SQL Servers to use Azure SQL with a modernization strategy built on confidence of customer success. Enterprise migrations rarely fail because of migration tools.

They slow down because organizations struggle to answer three questions:

How much downtime can we tolerate?
What will it cost after migration?
Are we choosing the right target platform?

The organizations that answer these questions early move faster and with less risk. For the DB Administrators, Data architects, application architect and cloud-cost decision makers there are important technical considerations before, during and after data modernization to avoid long term costs and operational concerns. The Microsoft SQL Team has helped many customers modernize their SQL. We discuss important guidelines that can help resolve the 3 major concerns that block or slow SQL Server migration and modernization in Enterprises. This is covered in the episode of DataExposed for which this companion blog goes into the details.

What are important triggers that cause customers and partners to consider SQL modernization?

There are many business triggers that force Enterprises to migrate their data to public cloud. As SQL Server 2012 to SQL Server 2016 are already in the end of support stage of their lifecycle, customers need to upgrade SQL Server in place or migrate to AzureSQL. Due to cyber security threats, customers are feeling more vulnerable to attackers. Moving their data into a secure environment is essential for protecting not just their data but their business. Customers are reporting the need to free up IT dollars to invest into other parts of the business that may need it more. These may be anything from datacenter contract expirations, need for Hardware refreshes to software license renewals. As the business grows or becomes cyclical, there is surge in demand. Capacity constraints become a barrier for such expansions. These are triggers that cause them to rethink their data modernization strategy. Data modernization and moving the data to a elastic, scalable, secure and resilient data platform such as Azure SQL, becomes essential.

The Three Migration Blockers

However, data modernization and migration is not without any risk. Based on our customers experience, here are three key reasons that we have commonly encountered that halt or slow down SQL modernization.

1. Downtime Risk

Business stakeholders often require strict service level commitments before authorizing production cutovers. Even when migrations are technically feasible, organizations may delay projects if they believe downtime windows could impact revenue, customer experience, or regulatory obligations. Most customers are still offered offline migration paths which can take hours to days, even though zero-downtime migrations are possible which take seconds to minutes.

2. Cost uncertainty

Many modernization projects are approved based on expected cost savings. However, if infrastructure sizing, licensing assumptions, storage consumption, or disaster recovery requirements are not evaluated properly, the actual operational cost can exceed initial expectations.

Cost uncertainty often slows executive approval processes and extends migration timelines.

3. Compatibility and Feature Fit

When migrating SQL Server, Azure SQL has several deployment offerings from IaaS to PaaS. These include SQL Server on Azure VM, Azure SQL Managed Instance, Azure SQL DB Hyperscale and Azure SQL in Microsoft Fabric. Many customers maybe using SQL Server features like Cross-database queries, CLR, SSIS, SQL Agent, and linked servers. They make a safe decision to lift and shift migrate to SQL Server on Azure VMs IaaS instead of modernizing to a PaaS service like Azure SQL Managed Instance. However, in the process, they lose the opportunity to use the PaaS capabilities, manageability and AI/Fabric capabilities in Azure by making this choice. Enterprise Architects, Application Architects, Database developers and DB Administrators have to make the right choice taking both development as well as operational costs and compatibility when they make their SQL modernization decisions.

Here are best practices some of the biggest and successful SQL migrations have used to make the migration and modernization journey with confidence. While we cannot disclose specific customer names, these guidelines are based on helping many large to small Enterprise customers.

Azure SQL Managed Instance as the Resiliency Anchor

Azure SQL Managed Instance is often the platform that helps organizations overcome all three concerns simultaneously because it combines near-full SQL Server compatibility with platform-as-a-service benefits.

Azure SQL Managed Instance (Azure SQL MI) Next-gen General Purpose is now generally available, bringing a built-in performance and scale upgrade for General Purpose workloads, including up to 500 databases per instance, up to 32 TB storage, lower latency, and higher IOPS. The release also adds more flexible cost-performance tuning with independent vCore, IOPS, and memory scaling, plus faster management operations to adapt to changing workload demand. For enterprise SQL Server modernization, this positions Azure SQL MI as a stronger path for high-compatibility migrations that need better price-performance without moving to a full replatform.

Let us dive deeper into how this helps address the downtime risk concerns by enables three levels of resiliency and high availability features.

Local Redundancy

Azure SQL Managed Instance provides first layer of Local Redundancy — built into every Azure SQL MI instance at no extra cost. Azure SQL Managed Instance uses local redundancy by default to keep workloads available during node, VM, rack, maintenance, and other local failures within a single datacenter, with Service Fabric orchestrating failover. In General Purpose (including Next-gen GP), this is implemented as stateless compute plus remote stateful storage; during failover, the engine process moves to another compute node and reattaches data, which can cause temporary performance impact due to cold cache. In Business Critical, local redundancy uses multiple synchronized replicas with local SSD storage (Always On-like architecture), enabling fast failover and read scale-out on secondaries.Next-gen General Purpose is an architectural upgrade to the existing General Purpose service tier that uses an upgraded remote storage layer that stores instance data and log files on Elastic SAN instead of page blobs and maintains it locally. Local redundancy protects against local infrastructure issues. This gives you a 99.99% SLA but not full datacenter/zone disasters, so zone redundancy (where supported) or disaster recovery (DR) options like failover groups/geo-restore are needed for broader resilience.

Zone Redundancy

The second layer is Zone Redundancy, which is accomplished placing data replicas across availability zones. Your Azure SQL MI resources are distributed across multiple availability zones within a region. This protects against the failure of an entire datacenter because each Azure availability zone is a separate physical location with independent power, cooling and networking. It relies on synchronous replication using zone-redundant storage for General Purpose. For Business critical, it uses Always On Availability group replicas across zones for Business Critical. Always On availability group technology replicates data changes from the primary instance to standby replicas in other availability zones. In the event of an outage, there's an automatic failover that seamlessly transitions one of the standby replicas to be prima. These replicas are always in sync — which means zero data loss. Failover typically happens in under 30 seconds, and your SLA jumps to 99.995%.

Failover Groups

The third layer is Failover Groups. This is your cross-region disaster recovery solution. It asynchronously replicates all user databases to a secondary Azure SQL MI instance in a different Azure region. Because it is asynchronous replication, there is potential for momentary data loss in the case of a datacenter outage. But it still protects the data against the worst case failure — a full regional outage. If the replica is a standby replica, there is no license required and it is used only for disaster recovery.

Using these options, business stakeholders can get their assurance that they have Enterprise grade availability and resiliency platform of AzureSQL for running their mission critical workloads. You can read more about these HA and Resiliency options in Microsoft Learn.

Cost Governance for Enterprise Buyers

The total cost of data modernization and migration is not a one-time estimate but an ongoing one. In this case, Azure SQL MI provides Enterprise DB Administrators many levers through pricing model choice, right-sizing, elasticity, serverless options and dev/test free tiers. Let us explore how these can be combined for smart cost estimations.

Lets also look at the best offering for the cost-conscious Enterprises - Azure SQL DB Hyperscale. With Azure SQL DB Hyperscale, you get the SQL Server engine, T-SQL compatibility, High Availability, Disaster recovery, security, backups, and management all bundled into the service price. No separate cost for SQL Server license. Hyperscale separates compute and storage that can scale independently and does not force you to overprovision. You have to only pay what you use which is ideal for seasonal workloads, Dev/Test, SaaS applications, predictable daytime trends, and up to 60% savings when you use Elastic pools.

Azure Hybrid benefit (AHB)- Azure Hybrid Benefit lets you bring your existing SQL Server investments to Azure and reduce compute costs, accelerating your ROI from cloud migration while preserving all the benefits of Azure SQL

Azure SQL DB Free offer – is the strongest product offering. Enterprises can use all features of Azure SQL at no cost for up to 10 Azure SQL DB free-tier. 100,000 vCore-seconds of serverless compute per month, 32GB data storage, 32 GB backup storage, serverless auto-scaling and auto-pause if you hit the limit per month. Run your POCs at no cost and evaluate before you move to Azure SQLDB, especially SMB& some enterprise

Azure SQL Managed Instance also offers 1 free Azure SQL MI instance per Azure subscription giving you 720vCore hours per month, 64GB storage, up to 500 databases, automated backups and 12 months free.

And if data migration is not possible due to data compliance or data proximity purposes, Azure Arc Pay-As-You-Go (PAYG) gives you cloud-style SQL licensing for servers running anywhere—on-premises, at the edge, or in other clouds. Instead of making large up-front licensing investments, you only pay for SQL Server while it's running, while still gaining access to Azure Arc management, security, monitoring, and modernization capabilities.

For seasonal, variable, or growth-oriented workloads, PAYG can improve cash flow and reduce licensing complexity. Reserved instances allow Enterprise customers to commit to using Azure SQL resource for a period of one or three years to receive a significant discount. This option combined with AHB can save you even more up to 80%. We have a comprehensive licensing guide for on-premises SQL Server for your reference.

Azure SQL enables a variety of cloud cost-models for a wide range of enterprise workload needs to help Enterprise cloud cost decision makers and DB Administrators make the right choice for their workloads.

Target selection guidance

While Azure SQL has multiple deployment options to migrate your on-premises work loads, it is critical to make the right choice long term. Customers can install SQL Server on-premises, they can use Azure SQL deployment options, and also run SQL Server in other clouds like Amazon Web Services and Google Cloud.

If there is an Enterprise workload that is not ready to modernize, you have the ability to lift and shift into SQL Server in Azure VM. It is a low cost migration option, because the application does not need any modification and it gives DB Administrators full control over the SQL server and underlying Windows or Linux OS. This can be a first step to modernization for some customers who are risk-averse.

For those Enterprise customers who are willing to modernize their workloads and SQL Server instances, Azure SQL DB Hyperscale is the best option. Azure SQL Database Hyperscale helps organizations modernize their most demanding database workloads with virtually unlimited growth, high performance, and cloud-scale economics. Customers can scale storage and compute independently, support large multi-terabyte databases, accelerate application performance with read-scale replicas, and eliminate the operational complexity of managing infrastructure, backups, patching, and high availability. They can build cloud-native applications or cloud-enable existing applications.

However, if Enterprise customers want good compatibility with their on-premises SQL Server but continue down the modernization path - their best option is Azure SQL Managed Instance. They can modernize the instance and not impact the application as there is no application change required. Applications will continue to work and the DB Administrators do not need to worry about managing infrastructure and all the overhead that comes with managing, self-managing your SQL Server virtual machines.

For SQL Server customers, PostgreSQL may look like an attractive low cost option. However, it requires re-platforming that could add significant hidden cost due to retraining all their DBAs and their developers to do performance optimization, performance best practices and operational maintenance. Lastly, our same SQL engine is also available to customers as a SaaS-ified version, Fabric SQL database as well.

All these options use the exact same SQL engine which makes it easier for Database developers and DB Administrators continue to use the same expertise, tools and process. Making the right choice of Azure SQL deployment is not just on the fastest way to modernize but the right long term approach.

Conclusion and Next steps

Enterprise SQL Server migrations rarely stall because of migration technology. More often, they are delayed by concerns around downtime, cost predictability, and platform selection. Organizations that address these questions early can accelerate modernization while reducing operational risk.

Azure SQL provides multiple modernization paths—from SQL Server on Azure Virtual Machines to Azure SQL Managed Instance and Azure SQL Database—allowing organizations to balance compatibility, operational simplicity, resiliency, and cost efficiency based on their business requirements.

As modernization initiatives accelerate, the most successful projects are those that treat migration not as a one-time infrastructure event, but as a long-term platform strategy.

Whether its the newest and the fastest way for us to migrate customers, we have all the comprehensive Copilot enabled AI-assisted migration tooling, technical training and support you need. Look for more blogs, whitepapers, guides and training based on best practices used real-world data modernization projects.

Generally Available: Microsoft Entra Server Principals and Server Roles for Azure SQL Database

PDasgupta — Thu, 18 Jun 2026 20:27:39 GMT

The problem we're solving

Previously, Microsoft Entra identities in Azure SQL Database could only be created as contained database users - principals scoped to a single database with no server-level presence. That meant:

No granular server-level delegation. You couldn't assign a server role such as ##MS_ServerStateReader## (to query DMVs across databases) or ##MS_LoginManager## (to manage logins) to an Entra principal. Only the Entra admin or a SQL login could perform these server-scoped tasks.
Per-database provisioning overhead. Each Entra principal had to be created separately as a contained database user in every database that required access, with no way to inherit server-scoped permissions.
No centralized “disable” switch. Offboarding meant tracking down a contained database user in every database - there was no server-level login to disable.

These gaps forced many teams to keep SQL authentication for administrative tasks, even when they wanted to go password-less with Entra.

What changes with GA

Microsoft Entra logins become first-class server principals in the logical master database, just like SQL logins. This capability has been in public preview on Azure SQL Database (and is already generally available on Azure SQL Managed Instance and SQL Server 2022+); with this release it reaches general availability on Azure SQL Database, unlocking three things for production use:

1. Server role assignment for Entra identities

Azure SQL Database's seven fixed server-level roles can be assigned to Entra server principals(logins). These roles cover database connectivity, database management, definition and security-definition reads, login management, and server-state read/manage.

This means you can give your monitoring service principal read-only DMV access across all databases (##MS_ServerStateReader##), delegate login management to a security team member (##MS_LoginManager##), or let a DevOps app create databases (##MS_DatabaseManager##). All without SQL auth, all with Entra identities.

2. Server-wide login model

Instead of provisioning contained users independently in every database, you can create database users mapped to a server login (CREATE USER ... FROM LOGIN). These users inherit server-scoped permissions automatically. One login, many databases — managed from a single place.

For the T-SQL syntax, see Create and utilize Microsoft Entra server logins.

3. Centralized logins enable/disable

ALTER LOGIN [user@contoso.com] DISABLE - one command blocks that identity from connecting to every database on the server. No more hunting down per-database users during an offboarding or incident response. When you re-enable the login, access is restored everywhere.

Note: ALTER LOGIN ... DISABLE applies only to login-based users, not contained database users. It blocks new connections only; existing sessions remain active until terminated with KILL if needed. For immediate effect, see cache propagation. Microsoft Entra group logins are not supported; see the server principals documentation for alternatives.

What does this unlock for your organization

Ability to go password-less. With server principals and roles now generally available, organizations can adopt Entra-only authentication without a remaining server-level functionality gap. Entra logins bring parity with SQL logins closer, making it practical to disable SQL authentication entirely and using Entra as the sole authentication path.

Least-privilege administration. Server-level roles simplify permission management by enabling customers to delegate common management and monitoring responsibilities without requiring admin privileges, enabling adherence to least privilege and separation of duties at scale, while making administration across databases on the same logical server much easier. Server roles let you scope access precisely, previously, the only server-wide option for an Entra identity was the all-powerful Entra admin. Give your security auditors ##MS_SecurityDefinitionReader## role instead of 'db_owner'. Give your monitoring tools ##MS_ServerStateReader## instead of an over-privileged administrator role.

Zero-touch DevOps. A service principal with ##MS_DatabaseManager## and ##MS_LoginManager## can automate database and user provisioning end-to-end. After the initial Entra admin bootstrap, no human needs to be in the loop for routine operations.

Faster incident response. When a principal is compromised, disable the login at the server level. New connections are blocked across all databases immediately - without needing to know which databases the user had access to. To cut off active sessions immediately, flush the authentication caches and KILL existing sessions.

Geo-replica support. Entra logins created on the primary server are automatically available on geo-replicas, with read-only access to replicated databases.

Key things to know

Bootstrap requirements. The Microsoft Entra admin must create the first Entra login. After that, any Entra principal with ALTER ANY LOGIN or ##MS_LoginManager## membership can create additional logins.
Entra admin takes precedence. If a principal is both the Entra admin and has a login, the admin permissions win. The login permissions have no additional effect.
Cache propagation. Role membership and permission changes take effect on the next connection. For immediate effect, clear the auth cache with DBCC FLUSHAUTHCACHE and DBCC FREESYSTEMCACHE('TokenAndPermUserStore').
EXECUTE AS LOGIN is not supported for Entra logins on Azure SQL Database (it is supported on Managed Instance).

Get started

Configure a Microsoft Entra admin on your logical server
Create your first Entra login and assign server roles (step-by-step tutorial)
Understand the server roles and their permissions
Consider enabling Entra-only authentication to eliminate SQL auth entirely

Ready to migrate from SQL Authentication?

If you're looking to move your existing SQL logins to Entra, check out Securing Azure SQL Database with Microsoft Entra password-less authentication - migration guide. It walks through the end-to-end journey from SQL auth to Entra, including how to identify SQL login dependencies, convert them to Entra principals, and enable Entra-only mode.

Learn more

Microsoft Entra server principals (logins) - full reference: syntax, permissions, limitations.
Azure SQL Database server roles - role descriptions, permission matrix, examples.
Microsoft Entra authentication overview - how Entra auth works with Azure SQL.
Manage logins and users - login lifecycle management.