Azure SQL Blog articles

Azure SQL is Deprecating the “No Minimum TLS” (MinTLS None) Configuration

talawren — Mon, 06 Apr 2026 20:27:03 GMT

As part of the retirement of lower TLS versions 1.0 and 1.1 and the enforcement of 1.2 as the new default minimum TLS version, we will be removing the No Minimum TLS (MinTLS = “None” or "0") option and updating these configurations to TLS 1.2.

No Minimum TLS allowed Azure SQL Database and Azure SQL Managed Instance resources to accept client connections using any TLS protocol version and unencrypted connections.

Over the past year, Azure has retired TLS 1.0 and 1.1 for all Azure databases, due to known security vulnerabilities in these older protocols. As of August 31, 2025, creating servers configured with versions 1.0 and 1.1 was disallowed and migration to 1.2 began. With legacy TLS versions being deprecated, TLS 1.2 will become the secure default minimum TLS version for new Azure SQL DB and MI configurations and for all client-server connections, rendering the MinTLS = None setting obsolete. As a result, the MinTLS = None configuration option will be deprecated for new servers, and existing servers configured with No Minimum TLS will be upgraded to 1.2.

What is changing?

After July 15, 2026, we will disallow minimum TLS value "None", for the creation of new SQL DB and MI resources using PowerShell, Azure CLI, and any other REST based interface. This configuration option has already been removed from the Portal during the deprecation of TLS versions 1.0 and 1.1.

Creating new Azure SQL Database and Managed Instance servers with MinTLS = None (which was previously considered the default) will no longer be a supported configuration. If the server parameter value for the minimum TLS is left blank, it will default to minimum TLS version 1.2.

Attempts to create an Azure SQL server with MinTLS = None will fail with an “Invalid operation” error and downgrades to None will be disallowed. While attempts to connect with TLS 1.0, 1.1 or unencrypted connections will fail with “Error: 47072/171 on Gateway.”

Effective date (retirement milestone)	MinTLS = None (0)	MinTLS left blank (defaults to supported minimum)
Before 8/31/25	Any + Unencrypted	Any + Unencrypted
After 8/31/25	1.2 + Unencrypted	1.2
After July 15, 2026	Invalid operation error (for new server creates) Downgrades will be disallowed TLS error: 47072/171 (for unencrypted connections)	1.2

In summary, after July 15, 2026, Azure SQL Database and Azure SQL Managed Instance will require all client connections to use TLS 1.2 or higher and unencrypted connections will be denied. The minimum TLS version setting will no longer accept the value "None" for new or existing servers and servers currently configured with this value will be upgraded to explicitly enforce TLS 1.2.

Who is impacted?

For most Azure SQL customers, there is no action required. Most clients already use TLS 1.2 or higher. After July 15, 2026, if your Azure SQL Database or Managed Instance is still configured with No Minimum TLS and using 1.0, 1.1 or unencrypted connections, it will automatically update to TLS 1.2 to reflect the current minimum protocol enforcement in client-server connectivity.

We do recommend you verify your client applications – especially any older or third-party client drivers – to ensure they can communicate with TLS 1.2 or above. In some rare cases, very old applications, such as an outdated JDBC driver or older .NET framework version, may need an update or need to enable TLS 1.2.

Conclusion

This deprecation is part of Azure’s broader security strategy to ensure encrypted connections are secure by modern encryption standards. TLS version 1.2 is more secure than older versions and is now the industry standard (required by regulations like PCI DSS and HIPAA). This change eliminates the use of unencrypted connections which ensure all database connections meet current security standards.

If you’ve already migrated to TLS 1.2 (as most customers have), you will most likely not notice any change, except that the No Minimum TLS option will disappear from configurations.

Zero Trust for data: Make Microsoft Entra authentication for SQL your policy baseline

PDasgupta — Mon, 30 Mar 2026 02:24:12 GMT

A policy-driven path from enabled to enforced.

Why this matters now

Security and compliance programs were once built on an assumption that internal networks were inherently safer. Cloud adoption, remote work, and supply-chain compromise have steadily invalidated that model. U.S. federal guidance has now formalized this shift: Executive Order 14028 calls for modernizing cybersecurity and accelerating Zero Trust adoption, and OMB Memorandum M-22-09 sets a federal Zero Trust strategy with specific objectives and timelines.

Meanwhile, attacker economics are changing. Automation and AI make reconnaissance, phishing, and credential abuse cheaper and faster. That concentrates risk on identity—the control plane that sits in front of systems, applications, and data. In Zero Trust, the question is no longer “is the network trusted,” but “is this request verified, governed by policy, and least-privilege?”

Why database authentication is a first‑order Zero Trust control

Databases are universally treated as crown-jewel infrastructure. Yet many data estates still rely on legacy patterns: password-based SQL authentication, long-lived secrets embedded in apps, and shared administrative accounts that persist because migration feels risky. This is exactly the kind of implicit trust Zero Trust architectures aim to remove.

NIST SP 800-207 defines Zero Trust as eliminating implicit trust based solely on network location or ownership and focusing controls on protecting resources. In that model, every new database connection is not “plumbing”—it is an access decision to sensitive data. If the authentication mechanism sits outside the enterprise identity plane, governance becomes fragmented and policy enforcement becomes inconsistent.

What changes when SQL uses Microsoft Entra authentication

Microsoft Entra authentication enables users and applications to connect to SQL using enterprise identities, instead of usernames and passwords. Across Azure SQL and SQL Server enabled by Azure Arc, Entra-based authentication helps align database access with the same identity controls organizations use elsewhere.

The security and compliance outcomes that leaders care about

Reduce password and secret risk: move away from static passwords and embedded credentials.
Centralize governance: bring database access under the same identity policies, access reviews, and lifecycle controls used across the enterprise.
Improve auditability: tie access to enterprise identities and create a consistent control surface for reporting.
Enable policy enforcement at scale: move from “configured” controls to “enforced” controls through governance and tooling.

This is why Entra authentication is a high-ROI modernization step: it collapses multiple security and operational objectives into one effort (identity modernization) rather than a set of ongoing compensating programs (password rotation programs, bespoke exceptions, and perpetual secret hygiene projects).

Why AI makes this a high priority decision

AI accelerates both reconnaissance and credential abuse, which concentrates risk on identity. As a result, policy makers increasingly treat phishing-resistant authentication and centralized identity enforcement as foundational—not optional.

A practical path: from enabled to enforced

Successful security programs define a clear end state, a measurable glide path, and an enforcement model. A pragmatic approach to modernizing SQL access typically includes:

Discover active usage: Identify which logins and users are actively connecting and which are no longer required.
Establish Entra as the identity authority: Enable Entra authentication on SQL logical servers, starting in mixed mode to reduce disruption.
Recreate principals using Entra identities: Replace SQL Authentication logins/users with Entra users, groups, service principals, and managed identities.
Modernize application connectivity: Update drivers and connection patterns to use Entra-based authentication and managed identities.
Validate, then enforce: Confirm the absence of password‑based SQL authentication traffic, then move to Entra‑only where available and enforce via policy.

By adopting this sequencing, organizations can mitigate risks at an early stage and postpone enforcement until the validation process concludes. For a comprehensive migration strategy, refer to Securing Azure SQL Database with Microsoft Entra Password-less Authentication: Migration Guide.

Choosing which projects to fund — and which ones to stop

When making investment decisions, priority is given to database identity projects that can demonstrate clear risk reduction and lasting security benefits.

Microsoft Entra authentication as the default for new SQL workloads, with a defined migration path for the existing workloads.
Managed identities for application-to-database connectivity to eliminate stored secrets.
Centralized governance for privileged database access using enterprise identity controls.

At the same time, organizations should explicitly de-prioritize investments that perpetuate password risk: password rotation projects that preserve SQL Authentication, bespoke scripts maintaining shared logins, and exception processes that do not scale.

Security and scale are not competing goals

Security is often seen as something that slows down innovation, but database identity offers unique benefits. When enterprise identity is used for access controls, bringing in new applications and users shifts from handing out credentials to overseeing policies. Compliance reporting also becomes uniform rather than customized, making it easier to grow consistently thanks to a single control framework.

Modern database authentication is not solely about mitigating risk— it establishes a scalable operational framework for secure data access.

A scorecard designed for leadership readiness

To elevate the conversation from implementation to governance, use outcome-based metrics:

Coverage: Percentage of SQL workloads with Entra authentication enabled.
Enforcement: Percentage operating in Entra-only mode after validation.
Secret reduction: Applications still relying on stored database passwords.
Privilege hygiene: Admin access governed through enterprise identity controls.
Audit evidence: Ability to produce identity-backed access reports on demand.

These map directly to Zero Trust maturity expectations and provide a defensible definition of “done.”

Closing

Zero Trust is an operating posture, not a single control. For most organizations, the fastest way to make that posture measurable is to standardize database access on the same identity plane used everywhere else.

If you are looking for a single investment that improves security, reduces audit friction, and supports responsible AI adoption, modernizing SQL access with Microsoft Entra authentication — and driving it from enabled to enforced — is one of the most durable choices you can make.

References

Stream data in near real time from SQL MI to Azure Event Hubs - Public preview

NikolaZagorac — Fri, 20 Mar 2026 20:34:02 GMT

How do I modernize an existing application without rewriting it?

Many business-critical applications still rely on architectures where the database is the most dependable integration point. These applications may have been built years ago, long before event-driven patterns became mainstream. Even after moving such workloads to Azure, teams are often left with the same question: how do we get data changes out of the database quickly, reliably, and without adding more custom plumbing?

This is where Change Event Streaming (CES) comes in.

We are happy to announce that Change Event Streaming for Azure SQL Managed Instance is now in Public Preview. CES enables you to stream row-level changes - inserts, updates, and deletes - from your database directly to Azure Event Hubs in near real time.

For workloads running on Azure SQL Managed Instance, this matters especially because many of them are existing line-of-business applications, modernized from on-premises SQL Server environments into Azure. Those applications are often still central to the business, but they were not originally designed to publish events to downstream systems. CES helps bridge that gap without requiring you to redesign the application itself.

What is Change Event Streaming?

Change Event Streaming is a capability that captures committed row changes from your database and publishes them to Azure Event Hubs or Fabric Eventstreams. Instead of relying on periodic polling, custom ETL jobs, or additional connectors, CES lets SQL push changes out as they happen.

This opens the door to near-real-time integrations while keeping the architecture simpler and closer to the source of truth.

A diagram conceptually visualizing data flow from SQL, with an arrow towards Azure Event Hubs, from where a number of arrows point to different final destinations.

Why CES matters for Azure SQL Managed Instance

Incremental modernization for existing applications

Azure SQL Managed Instance is a database of choice where application compatibility matters and where teams want to modernize from on-premises SQL Server into Azure with minimal disruption. In these environments, the database often becomes the most practical place to tap into business events - especially when the application itself was not designed to emit events or integrate in real-time.

With CES, you do not need to retrofit an older application to emit events itself. You can publish changes at the data layer and let downstream services react from there. This makes CES a practical tool for modernization programs that need to move step by step rather than through a full rewrite.

Lower operational complexity

Before CES: teams typically had to assemble integration flows out of polling processes, ETL pipelines, custom code, or third-party connectors. Those approaches can work, but they usually bring more moving parts, more credentials to manage, more monitoring overhead, and more latency tuning.

With CES: SQL Managed Instance streams changes directly to the configured destination. This reduces architectural sprawl and helps teams focus on consuming the events instead of maintaining the mechanics of moving them.

Better decoupling across the estate

Once changes are published to Azure Event Hubs or Fabric Eventstreams, multiple downstream systems can consume them independently. That is useful when one operational workload needs to feed analytics platforms, integration services, caches, search indexes, or new application components at the same time.

Instead of teaching an existing application to integrate with every destination directly, you can stream once from the database and let the message bus handle fan-out.

Typical scenarios

Breaking down monoliths

Many modernization efforts start with a large existing application and a database that serves many business functions. CES can help you carve out one capability at a time. A new component (microservice) can subscribe to events from selected tables, build its own behavior around those changes, and be validated incrementally before broader cutover decisions are made.

Real-time integration for line-of-business systems

If an operational system running on SQL Managed Instance needs to notify other platforms when data changes, CES provides a direct path to doing that. This can help with partner integrations, internal workflows, or downstream business processes that should react quickly when transactions are committed.

Real-time analytics

Operational data often becomes more valuable when it can be analyzed quickly. CES can stream data changes into Fabric Eventstreams or Azure Event Hubs, from where they can be consumed by analytics and stream processing processes for timely insights or actions.

Cache and index refresh

Applications often depend on caches or search indexes that need to stay aligned with transactional data. CES can provide a cleaner alternative to custom synchronization logic by publishing changes as they occur.

How it works

CES uses transaction log-based capture to stream changes with minimal impact on the publishing workload. Events are emitted in a structured JSON format that follows the CloudEvents standard and includes details such as the operation type, primary key, and before/after values.

Azure SQL Managed Instance can publish these events to Azure Event Hubs or Fabric Eventstreams using AMQP or Kafka protocols, depending on how you connect your downstream consumers.

Conclusion

Change Event Streaming for Azure SQL Managed Instance is an important step for customers who want to make existing applications more connected, simplified into smaller pieces or easier to integrate with modern data and application platforms.

For teams modernizing long-lived SQL Server workloads in Azure, CES offers a practical path: keep the application stable, tap into the data layer, and start enabling near-real-time scenarios without building another custom integration stack.

As CES enters Public Preview for Azure SQL Managed Instance, we encourage you to explore where it can simplify your architecture and accelerate modernization efforts.

Availability notes

Besides SQL Server 2025 and Azure SQL Database, where CES is already in Public preview, CES is available as of today in Public Preview for Azure SQL Managed Instance.

Just make sure that your SQL MI update policy is set to "Always up to date" or "SQL Server 2025".

This preview brings the same core CES capability to SQL Managed Instance workloads, helping customers apply event-driven patterns to existing operational systems without adding another custom integration layer.

For feature details, configuration guidance, and frequently asked questions, see:

We welcome your feedback through Azure Feedback channels or support channels. The CES team can also be reached via email: sqlcesfeedback [at] microsoft [dot] com.

Useful resources

Database DevOps (preview) in SSMS 22.4.1

DrewSkwiersKoballa — Thu, 19 Mar 2026 15:31:46 GMT

Database DevOps tooling for Microsoft SQL brings the benefits of database-as-code to your development workflow. At its core are SQL database projects, which enable you to source control your database schema, perform reliable deployments to any environment, and integrate code quality checks into your development process. Whether you're managing a single database or orchestrating complex deployments across multiple environments, SQL projects in SQL Server Management Studio (SSMS) provide the foundation for modern database DevOps practices.

Introducing SQL projects in SSMS

With the 22.4 release of SQL Server Management Studio (SSMS), we are excited to launch the public preview of SQL projects with the new "Database DevOps" workload in SSMS. This marks a significant milestone in our journey to bring the power of SQL projects to database professionals in different roles and with different preferences for development environments. The initial public preview brings the core create, build, and publish workflow to SSMS with the backing of Microsoft.Build.Sql projects, which are also supported in VS Code. This means that you can create a SQL project in SSMS, check it into source control, and then work with it in VS Code or vice versa, enabling a seamless experience across different tools and teams.

This is just the beginning of our plans for SQL projects in SSMS, and we are committed to expanding the capabilities and integrations in future releases based on your feedback and needs. Additional functionality in upcoming releases includes creating and updating projects from databases directly as well as the graphical schema compare interface. If you're looking to bring an existing database into source control and start with SQL projects in SSMS today, you have two options for quickly accessing your database definition. The mssql extension in VS Code provides a menu item in object explorer for "Create project from database" and the SqlPackage CLI has a command to generate the .sql files that can be copied directly into the SQL project directory:

dotnet tool install -g microsoft.sqlpackage sqlpackage /action:extract /sourceconnectionstring:"<connection string>" /targetfile:"databasefiles" /p:extracttarget=schemaobjecttype

What about Visual Studio SQL Server Data Tools (SSDT)?

SQL projects in SSMS are based on Microsoft.Build.Sql projects and requires a minimum SDK version of 2.1.0. While a preview of SSDT for Microsoft.Build.Sql projects is available for Visual Studio 2022, only the original SQL projects are supported in SSDT for Visual Studio 2026. The SQL projects tooling ecosystem includes multiple development environments, CI/CD integrations, and even customization through the DacFx .NET library. Our goal is that this ecosystem enables you and your teams to manage SQL database schemas and deployments in a more automated and reliable way, and this requires that tools used by your teams surface SQL projects such that they can be integrated into your existing workflows.

I understand that initial messaging about Microsoft.Build.Sql projects for Visual Studio and changes when that work was delayed has led to some confusion, so we’re operating with as much transparency as we can with the SQL projects roadmap at aka.ms/sqlprojects-roadmap. You'll note at this time that Microsoft.Build.Sql support in Visual Studio 2026 is not yet on the roadmap. Please continue to voice your feedback on the Developer Community, which is extremely valuable as we are actively reviewing the integration.

Get to know SQL projects

SQL projects represent a fundamental file format for database development and automation, enabling both a declarative approach to defining and deploying database schemas as well as supporting migration-based deployment methods with consolidated change visibility and code quality checks. By adopting SQL projects, teams can achieve greater consistency, collaboration, and efficiency in their database development processes, ultimately leading to more reliable and maintainable database systems. The integration of SQL projects with modern development tools and platforms further enhances their value, making it easier for teams to implement DevOps practices and automate their database workflows.

Documentation is available at aka.ms/sqlprojects-docs, and our public roadmap at aka.ms/sqlprojects-roadmap shows what's coming next. We'd love to hear your feedback — your input directly shapes our priorities and helps us build the database DevOps experience that works best for your teams. Get started with the public preview of SQL projects in SSMS today by downloading SSMS 22 or updating your current SSMS to 22.4 and modifying the SSMS install to include the Database DevOps workload.

Announcing Preview of 160 and 192vCore Premium-series Options for Azure SQL Database Hyperscale

scott_kim — Wed, 18 Mar 2026 18:53:27 GMT

We are excited to announce the public preview of 160 and 192vCore compute sizes for Premium-series hardware configuration in Azure SQL Database Hyperscale. Since the introduction of Premium-series hardware configurations for Hyperscale in November 2022, many customers have successfully used larger vCore configurations to consolidate workloads, reduce shard counts, and improve overall application performance and stability.

This preview builds on the Premium-series configuration introduced previously for Hyperscale, extending the maximum scale of a single database and elastic pools from 128vCores to 192vCores to support higher concurrency, faster CPU performance, and larger memory footprints, for more demanding mission critical workloads. With this preview, customers running largescale OLTP, HTAP, and analytics-heavy workloads can evaluate even higher compute ceilings without rearchitecting their applications.

Premium-Series Hyperscale Hardware Overview

Premium-series Hyperscale databases run on latest-generation Intel and AMD processors , delivering higher per core performance and improved scalability compared to standard-series (Gen5) hardware. With this public preview release, Premium-series Hyperscale now supports larger vCore configurations, extending the scaleup limits for customers who need more compute and memory in a single database.

Getting started

Customers can enable the 160 or 192vCore Premium-series options when creating a database, or when scaling up existing Hyperscale databases in supported regions (where preview capacity is available).

As with other Hyperscale scale operations, moving to a larger vCore size does not require application changes and uses Hyperscale’s distributed storage and compute architecture.

Resource Limits & Key characteristics

Link to Azure SQL documentation on resource limits

Single Database Resource Limits

Cores	Memory (GB)	Tempdb max data size (GB)	Max Local SSD IOPS	Max Log Rate (MiB/s)	Max concurrent workers	Max concurrent external connections per pool	Max concurrent sessions
128 (Current Limit)	625	4,096	544,000	150	12,800	150	30,000
160 (New preview limit)	830	4,096	680,000	150	16,000	150	30,000
192 (New preview limit)	843*	4,096	816,000	150	19,200	150	30,000

*Memory values will increase for 192 vCores at GA.

Elastic Pool Resource Limits

Cores	Memory (GB)	Tempdb max data size (GB)	Max Local SSD IOPS	Max Log Rate (MiB/s)	Max concurrent workers per pool	Max concurrent external connections per pool	Max concurrent sessions
128 (Current Limit)	625	4,096	409,600	150	13,440	150	30,000
160 (New preview limit)	830	4,096	800,000	150	16,800	150	30,000
192 (New preview limit)	843*	4,096	960,000	150	20,160	150	30,000

*Memory values will increase for 192 vCores at GA.

Premium-series Hyperscale can now scale up to 160 vCores & 192 vCores in public preview regions.
High performance CPUs optimized for compute-intensive workloads.
Increased memory capacity proportional to vCore scale
Up to 128 TiB of data storage, consistent with Hyperscale architecture
Full compatibility with existing Hyperscale features and capabilities

Performance Improvements with 160 and 192 vcores

Strong scale-up efficiency observed beyond 128 vCores: Moving from 128 → 160 → 192 vCores shows consistent performance gains, demonstrating that Hyperscale Premium-series continues to scale effectively at higher core counts.

160 vCores delivers a strong balance of single-query and concurrent performance.
192 vCores is ideal for customers prioritizing maximum throughput, high user concurrency, and large-scale transactional or analytical workloads
TPC-H Power Run (measures single-stream query performance) improves from 217 (128 vCores) to 357 (160 vCores) and remains high at 355 (192 vCores), delivering a +64% increase from 128 → 192 vCores, indicating strong single-query execution and CPU efficiency at larger sizes.
TPC-H Throughput Run (measures multi-stream concurrency) increases from 191 → 360 → 511 QPH, resulting in a +168% gain from 128 → 192 vCores, highlighting significant benefits for highly concurrent, multi-user workloads.

Performance case study (Zava Lending example)

If the player doesn’t load, open the video in a new window: Open video

Zava Lending scaled Azure SQL Hyperscale online as demand increased—supporting more users and higher transaction volume with no downtime.
Throughput scaled linearly as compute increased, moving cleanly from 32 → 64 → 128 → 192 vCores to match real workload growth.
192 vCores proved to be the optimal operating point, sustaining peak transaction load without over‑provisioning.
Azure SQL Hyperscale handled mixed OLTP and analytics workloads, including nightly ETL, without becoming a bottleneck.
Every scale operation was performed online, with no service interruption and no application changes.

Preview scope and limitations

During preview, Premium-series 160 and 192 vCores are supported in a limited set of initial regions (Australia East, Canada Central, East US 2, South Central US, UK South, West Europe, North Europe, Southeast Asia, West US 2), with broader availability planned over time.

During preview:

Zone redundancy and Azure SQL Database maintenance window are not supported for these sizes
Preview features are subject to supplemental preview terms, and performance characteristics may continue to improve through GA

Customers are encouraged to use this preview to validate scalability, concurrency, memory utilization, query parallelism, and readiness for larger single database deployments.

Next Steps

This public preview is part of our broader investment in scaling Azure SQL Hyperscale for the most demanding workloads. Feedback from preview will help inform GA configuration limits, regional rollout priorities, and performance optimizations at extreme scale.

Versionless keys for Transparent Data Encryption in Azure SQL Database (Generally Available)

PieterVanhove — Wed, 18 Mar 2026 13:23:11 GMT

With this release, you no longer need to reference a specific key version stored in Azure Key Vault or Managed HSM when configuring Transparent Data Encryption (TDE) with customer‑managed keys. Instead, Azure SQL Database now supports a versionless key URI, automatically using the latest enabled version of your key. This means:

Simpler key management—no longer necessary to specify the key version.
Reduced operational overhead by eliminating risks tied to outdated key versions.
Full control remains with the customer.

This enhancement streamlines encryption at rest, especially for organizations operating at scale or enforcing strict security and compliance standards.

Versionless keys for TDE are available today across Azure SQL Database with no additional cost.

Versioned vs. Versionless Key URIs

To highlight the difference, here are real examples:

Versioned Key URI (old approach — explicit version required)

https://demotdeakv.vault.azure.net/keys/TDECMK/40acafb8a7034b20ba227905df090a1f

Versionless Key URI (new approach)

https://demotdeakv.vault.azure.net/keys/TDECMK

A versionless key URI references only the key name. Azure SQL Database automatically uses the newest enabled version of the key.

Learn more

Transparent Data Encryption - Azure SQL Database

Azure SQL transparent data encryption with customer-managed key

Transparent data encryption with customer-managed keys at the database level

Stop defragmenting and start living: introducing auto index compaction

Dimitri_Furman — Wed, 18 Mar 2026 12:30:29 GMT

Executive summary

Automatic index compaction is a new built-in feature in the MSSQL database engine that compacts indexes in background and with minimal overhead.

Now you can:

Stop using scheduled index maintenance jobs.
Reduce storage space consumption and save costs.
Improve performance by reducing CPU, memory, and disk I/O consumption.

Today, we announce a public preview of automatic index compaction in Azure SQL Database, Azure SQL Managed Instance with the always-up-to-date update policy, and SQL database in Fabric.

Index maintenance without maintenance jobs

Enable automatic index compaction for a database with a single T-SQL command:

ALTER DATABASE [database-name] SET AUTOMATIC_INDEX_COMPACTION = ON;

Once enabled, you no longer need to set up, maintain, and monitor resource intensive index maintenance jobs, a time-consuming operational task for many DBA teams today.

As the data in the database changes, a background process consolidates rows from partially filled data pages into a smaller number of filled up pages, and then removes the empty pages. Index bloat is eliminated – the same amount of data now uses a minimal amount of storage space.

A conceptual view of the index compaction process

Resource consumption is reduced because the database engine needs fewer disk IOs and less CPU and memory to process the same amount of data.

By design, the background compaction process acts on the recently modified pages only. This means that its own resource consumption is much lower compared to the traditional index maintenance operations (index rebuild and reorganize), which process all pages in an index or its partition.

For a detailed description of how the feature works, a comparison between automatic index compaction and the traditional index maintenance operations, and the ways to monitor the compaction process, see automatic index compaction in documentation.

Compaction in action

To see the effects of automatic index compaction, we wrote a stored procedure that simulates a write-intensive OLTP workload. Each execution of the procedure inserts, updates, deletes, or selects a random number of rows, from 1 to 100, in a 50,000-row table with a clustered index.

We executed this stored procedure using a popular SQLQueryStress tool, with 30 threads and 400 iterations on each thread.

The SQLQueryStress tool running an OLTP-like workload

We measured the page density, the number pages in the leaf level of the table’s clustered index, and the number of logical reads (pages) used by a test query reading 1,000 rows, at three points in time:

After initially inserting the data and before running the workload.
Once the workload stopped running.
Several minutes later, once the background process completed index compaction.

Here are the results:

	Before workload	After workload	After compaction
Logical reads	25 🟢	1,610 🔴⬆️	35 🟢⬇️
Page density	99.51% 🟢	52.71% 🔴⬇️	96.11% 🟢⬆️
Pages	962 🟢	4,394 🔴⬆️	1,065 🟢⬇️

Before the workload starts, page density is high because nearly all pages are full. The number of logical reads required by the test query is minimal, and so is its resource consumption.

The workload leaves a lot of empty space on pages and increases the number of pages because of row updates and deletions, and because of page splits. As a result, immediately after workload completion, the number of logical reads required for the same test query increases more than 60 times, which translates into a higher CPU and memory usage.

But then within a few minutes, automatic index compaction removes the empty space from the index, increasing page density back to nearly 100%, reducing logical reads by about 98% and getting the index very close to its initial compact state. Less logical reads means that the query is faster and uses less CPU. All of this without any user action.

With continuous workloads, index compaction is continuous as well, maintaining higher average page density and reducing resource usage by the workload over time.

The T-SQL code we used in this demo is available in the Appendix.

Conclusion

Automatic index compaction delegates a routine database maintenance operation to the database engine itself, letting administrators and engineers focus on more important work without worrying about index maintenance.

The public preview is a great opportunity to let us know how this new feature works for you. Please share your feedback and suggestions for any improvements we can make.

To let us know your thoughts, you can comment on this blog post, leave feedback at https://aka.ms/sqlfeedback, or email us at sqlaicpreview@microsoft.com.

Appendix

Here is the T-SQL code we used to demonstrate automatic index compaction.

The type of executed statements and the number of affected rows is randomized to better represent an OLTP workload. While the results demonstrate the effectiveness of automatic index compaction, exact measurements may vary from one execution to the next.

/* Enable automatic index compaction */ ALTER DATABASE CURRENT SET AUTOMATIC_INDEX_COMPACTION = ON; /* Reset to the initial state */ DROP TABLE IF EXISTS dbo.t; DROP SEQUENCE IF EXISTS dbo.s_id; DROP PROCEDURE IF EXISTS dbo.churn; /* Create a sequence to generate clustered index keys */ CREATE SEQUENCE dbo.s_id AS int START WITH 1 INCREMENT BY 1; /* Create a test table */ CREATE TABLE dbo.t ( id int NOT NULL CONSTRAINT df_t_id DEFAULT (NEXT VALUE FOR dbo.s_id), dt datetime2 NOT NULL CONSTRAINT df_t_dt DEFAULT (SYSDATETIME()), u uniqueidentifier NOT NULL CONSTRAINT df_t_uid DEFAULT (NEWID()), s nvarchar(100) NOT NULL CONSTRAINT df_t_s DEFAULT (REPLICATE('c', 1 + 100 * RAND())), CONSTRAINT pk_t PRIMARY KEY (id) ); /* Insert 50,000 rows */ INSERT INTO dbo.t (s) SELECT REPLICATE('c', 50) AS s FROM GENERATE_SERIES(1, 50000); GO /* Create a stored procedure that simulates a write-intensive OLTP workload. */ CREATE OR ALTER PROCEDURE dbo.churn AS SET NOCOUNT, XACT_ABORT ON; DECLARE @r float = RAND(CAST(CAST(NEWID() AS varbinary(4)) AS int)); /* Get the type of statement to execute */ DECLARE @StatementType char(6) = CASE WHEN @r <= 0.15 THEN 'insert' WHEN @r <= 0.30 THEN 'delete' WHEN @r <= 0.65 THEN 'update' WHEN @r <= 1 THEN 'select' ELSE NULL END; /* Get the maximum key value for the clustered index */ DECLARE @MaxKey int = ( SELECT CAST(current_value AS int) FROM sys.sequences WHERE name = 's_id' AND SCHEMA_NAME(schema_id) = 'dbo' ); /* Get a random key value within the key range */ DECLARE @StartKey int = 1 + RAND() * @MaxKey; /* Get a random number of rows, between 1 and 100, to modify or read */ DECLARE @RowCount int = 1 + RAND() * 99; /* Execute a statement */ IF @StatementType = 'insert' INSERT INTO dbo.t (id) SELECT NEXT VALUE FOR dbo.s_id FROM GENERATE_SERIES(1, @RowCount); IF @StatementType = 'delete' DELETE TOP (@RowCount) dbo.t WHERE id >= @StartKey; IF @StatementType = 'update' UPDATE TOP (@RowCount) dbo.t SET dt = DEFAULT, u = DEFAULT, s = DEFAULT WHERE id >= @StartKey; IF @StatementType = 'select' SELECT TOP (@RowCount) id, dt, u, s FROM dbo.t WHERE id >= @StartKey; GO /* The remainder of this script is executed three times: 1. Before running the workload using SQLQueryStress. 2. Immediately after the workload stops running. 3. Once automatic index compaction completes several minutes later. */ /* Monitor page density and the number of pages and records in the leaf level of the clustered index. */ SELECT avg_page_space_used_in_percent AS page_density, page_count, record_count FROM sys.dm_db_index_physical_stats(DB_ID(), OBJECT_ID('dbo.t'), 1, 1, 'DETAILED') WHERE index_level = 0; /* Run a test query and measure its logical reads. */ DROP TABLE IF EXISTS #t; SET STATISTICS IO ON; SELECT TOP (1000) id, dt, u, s INTO #t FROM dbo.t WHERE id >= 10000 SET STATISTICS IO OFF;

Managed Identity Support for Azure SQL Database Import & Export services (preview)

HugoQueiroz_MSFT — Tue, 03 Mar 2026 18:05:24 GMT

Today we’re announcing a public preview that lets Azure SQL Database Import & Export services authenticate with user-assigned managed identity. Now Azure SQL Databases can perform import and export operations with no passwords, storage keys or SAS tokens.

With this preview, customers can choose to use either a single user-assigned managed identity (UAMI) for both SQL and Storage permissions or assign separate UAMIs, one for the Azure SQL logical server and another for the Storage account, for full separation of duties.

At a glance:

Run Import/Export using a user-assigned managed identity (UAMI).
Use one identity for both SQL and Storage, or split them if you prefer tighter scoping.
Works in the portal, REST, Azure CLI, and PowerShell.

Why this matters:

Managed identity support makes SQL migrations simpler and safer, no passwords, storage keys, or SAS tokens. By leveraging managed identity when integrating Import/Export into a pipeline, you streamline access management and enhance security: permissions are granted directly to the identity, reducing manual credential handling and the risk of exposing sensitive information. This keeps operations efficient and secure, without secrets embedded in scripts

You’ve got two straightforward options:

One UAMI for everything (simplest setup).
Two UAMIs, one for SQL and one for Storage, recommended if you wish to maintain more strictly defined permissions.

Getting started:

Create a user-assigned managed identity (UAMI)
Decide up front whether you want one identity end-to-end, or two identities (SQL vs Storage) for separation of duties.

Attach the UAMI to the Azure SQL logical server
On the server Identity blade, add the UAMI so the Import/Export job can run as that identity.

Set the server’s Microsoft Entra ID admin to the UAMI
In Microsoft Entra ID > Set admin, select the UAMI. This is what lets the workflow authenticate to SQL without a password.

Grant Storage access
Use Storage Blob Data Reader for import and Storage Blob Data Contributor for export, assigned in Access control (IAM). If you can, scope the assignment to the container that holds the .bacpac.

Pass resource IDs (not names) in your calls

In REST/CLI/PowerShell, you pass the UAMI resource ID as the value of administratorLogin (SQL identity) and storageKey (Storage identity), and set authenticationType / storageKeyType to ManagedIdentity.
- administratorLogin → UAMI resource ID used for SQL auth
- storageKey → UAMI resource ID used for Storage
- authauthenticationType / storageKeyType → ManagedIdentity

Run the import/export job
Kick it off from the portal, REST, Azure CLI, or PowerShell. From there, the service uses the identity you selected to reach both SQL and Storage.

Portal experience

In the Azure portal, you can choose Authentication type = Managed identity and select the user-assigned managed identity to use for the operation.

Figure 1: Azure portal Import/Export experience with Managed identity authentication selected.

Notes

This preview supports user-assigned managed identities (UAMIs).
For least privilege, scope Storage roles to the specific container used for the .bacpac file and use two user-assigned managed identities (UAMIs), one for SQL and one for the storage.

Sample 1: REST API — Export using one UAMI:

$exportBody = "{ `n `"storageKeyType`": `"ManagedIdentity`", `n `"storageKey`": `"${managedIdentityServerResourceId}`", `n `"storageUri`": `"${storageUri}`", `n `"administratorLogin`": `"${managedIdentityServerResourceId}`", `n `"authenticationType`": `"ManagedIdentity`" `n}" $export = Invoke-AzRestMethod -Method POST -Path "/subscriptions/${subscriptionId}/resourceGroups/${resourceGroupName}/providers/Microsoft.Sql/servers/${serverName}/databases/${databaseName}/export?api-version=2024-05-01-preview" -Payload $exportBody # Poll operation status Invoke-AzRestMethod -Method GET $export.Headers.Location.AbsoluteUri

Sample 2: REST API — Import to a new server using one UAMI:

$serverName = "sql-mi-demo-target" $databaseName = "sqldb-mi-demo-target" # Same UAMI for SQL auth + Storage access $importBody = "{ `n `"operationMode`": `"Import`", `n `"administratorLogin`": `"${managedIdentityServerResourceId}`", `n `"authenticationType`": `"ManagedIdentity`", `n `"storageKeyType`": `"ManagedIdentity`", `n `"storageKey`": `"${managedIdentityServerResourceId}`", `n `"storageUri`": `"${storageUri}`", `n `"databaseName`": `"${databaseName}`" `n}" $import = Invoke-AzRestMethod -Method POST -Path "/subscriptions/${subscriptionId}/resourceGroups/${resourceGroupName}/providers/Microsoft.Sql/servers/${serverName}/databases/${databaseName}/import?api-version=2024-05-01-preview" -Payload $importBody # Poll operation status Invoke-AzRestMethod -Method GET $import.Headers.Location.AbsoluteUri

Sample 3: PowerShell — Export using two UAMIs:

# Server UAMI for SQL auth, Storage UAMI for storage access New-AzSqlDatabaseExport -ResourceGroupName $resourceGroupName -DatabaseName $databaseName -ServerName $serverName -StorageKeyType ManagedIdentity -StorageKey $managedIdentityStorageResourceId -StorageUri $storageUri -AuthenticationType ManagedIdentity -AdministratorLogin $managedIdentityServerResourceId

Sample 4: PowerShell — Import to a new server using two UAMIs:

New-AzSqlDatabaseImport -ResourceGroupName $resourceGroupName -DatabaseName $databaseName -ServerName $serverName -DatabaseMaxSizeBytes $databaseSizeInBytes -StorageKeyType "ManagedIdentity" -StorageKey $managedIdentityStorageResourceId -StorageUri $storageUri -Edition $edition -ServiceObjectiveName $serviceObjectiveName -AdministratorLogin $managedIdentityServerResourceId -AuthenticationType ManagedIdentity

Sample 5: Azure CLI — Export using two UAMIs:

az sql db export -s $serverName -n $databaseName -g $resourceGroupName --auth-type ManagedIdentity -u $managedIdentityServerResourceId --storage-key $managedIdentityStorageResourceId --storage-key-type ManagedIdentity --storage-uri $storageUri

Sample 6: Azure CLI — Import to a new server using two UAMIs:

az sql db import -s $serverName -n $databaseName -g $resourceGroupName --auth-type ManagedIdentity -u $managedIdentityServerResourceId --storage-key $managedIdentityStorageResourceId --storage-key-type ManagedIdentity --storage-uri $storageUrib

For more information and samples, please check Tutorial: Use managed identity with Azure SQL import and export (preview)

GA of update policy SQL Server 2025 for Azure SQL Managed Instance

Mladen_Andzic — Tue, 03 Mar 2026 00:22:29 GMT

We’re happy to announce that the update policy SQL Server 2025 for Azure SQL Managed Instance is now generally available (GA). SQL Server 2025 update policy contains all the latest SQL engine innovation while retaining database portability to the recent major release of SQL Server.

Update policy is an instance configuration option that provides flexibility and allows you to choose between instant access to the latest SQL engine features and fixed SQL engine feature set corresponding to 2022 and 2025 major releases of SQL Server. Regardless of the update policy chosen, you continue to benefit from Azure SQL platform innovation. New features and capabilities not related to the SQL engine – everything that makes Azure SQL Managed Instance a true PaaS service – are successively delivered to your Azure SQL Managed Instance resources.

What’s new in SQL Server 2025 update policy

In short, instances with update policy SQL Server 2025 benefit from all the SQL engine features that were gradually added to the Always-up-to-date policy over the past few years and are not available in the SQL Server 2022 update policy. Let’s name few most notable features, with complete list available in the update policy documentation:

Update policy for each modernization strategy

Always-up-to-date is a “perpetual” update policy. It has no end of lifetime and brings new SQL engine features to instances as soon as they are available in Azure. It enables you to always be at the forefront - to quickly adopt new yet production-ready SQL engine features, benefit from them in everyday operations and keep a competitive edge without waiting for the next major release of SQL Server.

In contrast, update policies SQL Server 2025 and SQL Server 2022 contain fixed sets of SQL engine features corresponding to the respective releases of SQL Server. They’re optimized to fulfill regulatory compliance, contractual, or other requirements for database/workload portability from managed instance to SQL Server. Over time, they get security patches, fixes, and incremental functional improvements in form of Cumulative Updates, but not new SQL engine features. They also have limited lifetime, aligned with the period of mainstream support of SQL Server releases. As the end of mainstream support for the update policy approaches, you should upgrade instances to a newer policy. Instances will be automatically upgraded to the next more recent update policy at the end of mainstream support of their existing update policy.

Best practices with the Update policy feature

Plan for the end of lifetime of SQL Server 2022 update policy if you’re using it today, and upgrade to a newer policy on your terms before automatic upgrade kicks in. Choose between Always-up-to-date and SQL Server 2025 update policy.
Make sure to add update policy configuration to your deployment templates and scripts, so that you don’t rely on service defaults that may change in the future.
Be aware that using some of the newly introduced features may require changing the database compatibility level. Consult feature documentation for details.

What’s coming next

SQL Server 2025 will become the default update policy in Azure portal during March 2026.

Future versions of REST API, PowerShell and CLI will also have the default value changed to SQL Server 2025 for the „database format“ parameter which corresponds to the instance’s update policy.

SQL Server 2022 policy will reach end of lifetime on January 11, 2028 when the mainstream support for SQL Server 2022 ends. Plan timely and change the update policy of your instances before that date.

Update policy transitions

Summary

Update policy SQL Server 2025 for Azure SQL Managed Instance is now generally available. It brings the same set of SQL engine features that exist in the new SQL Server 2025. Consider it if you have regulatory compliance, contractual, or other reasons for database/workload portability from Azure SQL Managed Instance to SQL Server 2025. Otherwise, use the Always-up-to-date policy which always provides the latest features and benefits available to Azure SQL Managed Instance.

If your instances are currently configured with SQL Server 2022 update policy, update them to a newer policy before the end of mainstream support.

For more details visit Update policy documentation. To stay up to date with the latest feature additions to Azure SQL Managed Instance, subscribe to the Azure SQL video channel, subscribe to the Azure SQL Blog feed, or bookmark What’s new in Azure SQL Managed Instance article with regular updates.

Why Developers and DBAs love SQL’s Dynamic Data Masking (Series-Part 1)

MadhumitaTripathyMSFT — Mon, 02 Mar 2026 10:17:08 GMT

Dynamic Data Masking (DDM) is one of those SQL features (available in SQL Server, Azure SQL DB, Azure SQL MI, SQL Database in Microsoft Fabric) that both developers and DBAs can rally behind. Why? Because it delivers a simple, built-in way to protect sensitive data—like phone numbers, emails, or IDs—without rewriting application logic or duplicating security rules across layers. With just a single line of T-SQL, you can configure masking directly at the column level, ensuring that non-privileged users see only obfuscated values while privileged users retain full access. This not only streamlines development but also supports compliance with data privacy regulations like GDPR and HIPAA, etc. by minimizing exposure to personally identifiable information (PII).

In this first post of our DDM series, we’ll walk through a real-world scenario using the default masking function to show how easy it is to implement and how much development effort it can save.

Scenario: Hiding customer phone numbers from support queries

Imagine you have a support application where agents can look up customer profiles. They need to know if a phone number exists for the customer but shouldn’t see the actual digits for privacy. In a traditional approach, a developer might implement custom logic in the app (or a SQL view) to replace phone numbers with placeholders like “XXXX” for non-privileged users. This adds complexity and duplicate logic across the app.

With DDM’s default masking, the database can handle this automatically. By applying a mask to the phone number column, any query by a non-privileged user will return a generic masked value (e.g. “XXXX”) instead of the real number. The support agent gets the information they need (that a number is on file) without revealing the actual phone number, and the developer writes zero masking code in the app.

This not only simplifies the application codebase but also ensures consistent data protection across all query access paths. As Microsoft’s documentation puts it, DDM lets you control how much sensitive data to reveal “with minimal effect on the application layer” – exactly what our scenario achieves.

Using the ‘Default’ Mask in T-SQL :

The ‘Default’ masking function is the simplest mask: it fully replaces the actual value with a fixed default based on data type. For text data, that default is XXXX. Let’s apply this to our phone number example. The following T-SQL snippet works in Azure SQL Database, Azure SQL MI and SQL Server:

SQL

-- Step 1: Create the table with a default mask on the Phone column

CREATE TABLE SupportCustomers (

    CustomerID   INT PRIMARY KEY,

    Name         NVARCHAR(100),

    Phone        NVARCHAR(15) MASKED WITH (FUNCTION = 'default()')  -- Apply default masking

);

-- Step 2: Insert sample data

INSERT INTO SupportCustomers (CustomerID, Name, Phone)

VALUES (1, 'Alice Johnson', '222-555-1234');

-- Step 3: Create a non-privileged user (no login for simplicity)

CREATE USER SupportAgent WITHOUT LOGIN;

-- Step 4: Grant SELECT permission on the table to the user

GRANT SELECT ON SupportCustomers TO SupportAgent;

-- Step 5: Execute a SELECT as the non-privileged user

EXECUTE AS USER = 'SupportAgent';

SELECT Name, Phone FROM SupportCustomers WHERE CustomerID = 1

Alternatively, you can use Azure Portal to configure masking as shown in the following screenshot:

Expected result: The query above would return Alice’s name and a masked phone number. Instead of seeing 222-555-1234, the Phone column would show XXXX. Alice’s actual number remains safely stored in the database, but it’s dynamically obscured for the support agent’s query.

Meanwhile, privileged users such as administrator or db_owner which has CONTROL permission on the database or user with proper UNMASK permission would see the real phone number when running the same query.

How this helps Developers :

By pushing the masking logic down to the database, developers and DBAs avoid writing repetitive masking code in every app or report that touches this data. In our scenario, without DDM you might implement a check in the application like:

If user_role == “Support”, then show “XXXX” for phone number, else show full phone.

With DDM, such conditional code isn’t needed – the database takes care of it. This means:

Less application code to write and maintain for masking

Consistent masking everywhere (whether data is accessed via app, report, or ad-hoc query).

Quick changes to masking rules in one place if requirements change, without hunting through application code.

From a security standpoint, DDM reduces the risk of accidental data exposure and helps in compliance scenarios where personal data must be protected in lower environments or by certain roles, while reducing the developer effort drastically.

In the next posts of this series, we’ll explore other masking functions (like Email, Partial, and Random etc) with different scenarios. By the end, you’ll see how each built-in mask can be applied to make data security and compliance more developer-friendly!

Reference Links :

Dynamic Data Masking - SQL Server | Microsoft Learn

Dynamic Data Masking - Azure SQL Database & Azure SQL Managed Instance & Azure Synapse Analytics | Microsoft Learn

Multiple secondaries for failover groups is now in public preview

mhyon — Fri, 30 Jan 2026 16:52:54 GMT

Failover groups for Azure SQL Database is a business continuity solution that lets you manage the replication and failover of databases to another Azure SQL logical server. With failover groups, you get automatic endpoint redirection, so you don't have to change the connection string for your application after a geo-failover—connections are automatically routed to the current primary. Until now, Azure SQL failover groups have only supported one secondary.

We're excited to announce that Azure SQL Database failover groups support for up to four secondaries is now available in public preview. This enhancement gives you greater flexibility for disaster recovery, regional read scale-out, and complex high-availability scenarios.

What's New?

Create up to four secondaries for each failover group, deployed across the same or different Azure regions.
Use the additional secondaries to add read scale-out capabilities to additional regions, adding flexibility for read-only workloads.
Greater flexibility for disaster recovery planning with multiple failover targets.
Improved resilience by distributing secondaries across multiple geographic regions.
Facilitate migration to another region without sacrificing existing disaster recovery protection.

How to Get Started

Getting started with multiple secondaries in Azure SQL failover groups is straightforward.

In the Azure Portal, the process to create a failover group remains the same. You can add additional secondaries using the process below.

Adding Additional Secondary Servers to a Failover Group in the Portal

Go to your Azure SQL Database logical server in the Azure portal.
Open the "Failover groups" blade under "Data management".
Select an existing failover group.
Click the "Add server" menu item to add additional secondary servers.
A side panel opens displaying the list of secondary servers and a dropdown to select which server should operate as the read-only listener endpoint target. The additional secondary server can be in the same or different Azure region as the primary.

NOTE: The read-only listener endpoint dropdown lists all existing secondary servers as well as the secondary server being added. This allows you to designate which secondary server should receive read-only traffic routed through the `<fog-name>.secondary.database.windows.net` endpoint. However, the server selected as the read-only listener endpoint target should not be in the same region as the primary server if you intend to serve read workloads with that endpoint.

Adding an additional secondary to your failover group and specifying the read-only listener endpoint target

After selecting the additional secondary and specifying your read-only listener endpoint target, click "Select" on the side panel and click "Save" in the main menu to apply your failover group configuration. The additional secondary will be added and seeding of databases in the failover group will begin to that additional secondary. You can modify your read-only listener endpoint target with the "Edit configuration" menu option.

Save the configuration for the failover group with the newly added secondaryDatabases in the failover group will begin seeding to the newly added secondary

TIP: If you want zone redundancy enabled for the secondary databases, ensure that the secondary servers are in regions that support availability zones and configure the zone redundancy setting appropriately.

Using PowerShell

Creating a failover group with multiple secondaries can also be done with PowerShell.

Example - Create a failover group with multiple secondaries:

New-AzSqlDatabaseFailoverGroup ` -ResourceGroupName "myrg" ` -ServerName "primaryserver" ` -PartnerServerName "secondaryserver1" ` -FailoverGroupName "myfailovergroup" ` -FailoverPolicy "Manual" ` -PartnerServerList @("secondary_uri_1", "secondary_uri_2", "secondary_uri_3", "secondary_uri_4") ` -ReadOnlyEndpointTargetServer "secondary_uri_1" where "secondary_uri_n" is in the form below and secondaryserver1 is also included in the list "/subscriptions/your_sub_guid/resourceGroups/your_resource_group/providers/Microsoft.Sql/servers/your_server_name"

Example - Add additional secondary servers to an existing failover group:

Set-AzSqlDatabaseFailoverGroup ` -ResourceGroupName "myrg" ` -ServerName "primaryserver" ` -FailoverGroupName "myfailovergroup" ` -FailoverPolicy "Manual" ` -PartnerServerList @("secondary_uri_1", "secondary_uri_2", "secondary_uri_3", "secondary_uri_4") ` -ReadOnlyEndpointTargetServer "secondary_uri_1" where "secondary_uri_n" is in the form below and secondaryserver1 is also included in the list "/subscriptions/your_sub_guid/resourceGroups/your_resource_group/providers/Microsoft.Sql/servers/your_server_name"

Performing a Failover

With multiple secondaries, you can choose which secondary to promote to primary during a failover.

Using the Portal

Navigate to your SQL server's Failover groups blade.
Select the failover group you want to fail over.
In the servers list, locate the secondary server you want to promote.
Click the ellipsis menu (...) next to the server.

Use the ellipsis menu for failover options and to remove a server from the failover group

Select Failover for a planned failover (with full data synchronization) or Forced failover for an unplanned failover (potential data loss).

TIP: The ellipsis menu also includes a Remove server option, allowing you to remove a secondary server from the failover group.

Using PowerShell

For PowerShell, use the `Switch-AzSqlDatabaseFailoverGroup` cmdlet to perform a failover.

Example:

Switch-AzSqlDatabaseFailoverGroup ` -ResourceGroupName "myrg" ` -ServerName "secondaryserver1" ` -FailoverGroupName "myfailovergroup"

Key Benefits

Enhanced Disaster Recovery - Multiple geo-secondaries provide additional failover targets, reducing the risk of total service disruption.
Regional Read Scale-Out - Distribute read-only workloads across multiple regions.
Flexible HA/DR Architecture - Design your high-availability architecture based on your specific business requirements.
Ease migrations to another region - Leverage the additional secondary to migrate to a different Azure region while maintaining DR protection.

Limitations & Notes

You can create up to four secondaries per failover group.
Each secondary must be hosted on a different logical server from the primary.
Secondary servers can be in the same region as the primary or in different regions.
The read-only listener endpoint target must be in a different region from the primary if you want to make use of the read-only listener for read workloads.
The failover group name must be globally unique within the `.database.windows.net` domain.
Chaining (creating a geo-replica of a geo-replica) is not supported.
Secondary databases in a failover group inherit the backup storage redundancy and zone redundancy configuration from the primary, depending on the service tier.
For non-Hyperscale databases: Secondary databases will not have high availability (zone redundancy) enabled by default. Enable it after the failover group is created.
For Hyperscale databases: Secondary databases inherit the high availability settings from their respective primary databases.

Best Practices

Use paired regions when possible—failover groups in paired regions have better performance compared to unpaired regions.
Test your failover procedures regularly using planned failovers to ensure your disaster recovery plan works as expected.
Monitor replication lag using `sys.dm_geo_replication_link_status` or the Replication Lag metric in Azure Monitor to ensure your secondaries are synchronized.
Consider your RTO and RPO requirements when designing your failover group architecture.
Use the read-write listener (`<fog-name>.database.windows.net`) for write workloads and the read-only listener (`<fog-name>.secondary.database.windows.net`) for read workloads to take advantage of the automatic endpoint redirection after failovers.
Use customer-managed failover group policy to ensure your RTO and RPO are in your control.

Frequently Asked Questions

What services tiers are supported for multiple secondaries in failover group?

The following service tiers are supported:
- Standard
- General Purpose
- Premium
- Business Critical
- Hyperscale
When there is more than one secondary, how does read only endpoint work?

While creating a failover group with more than one secondary you must designate one of the secondaries as the read only endpoint target. All read only connections will be routed to the designated secondary.

If a failover group is created with just one secondary, then the read only endpoint will default to the only available secondary.
If I have created multiple secondaries for failover group, can I update the read only endpoint at any time?

Yes, you can "Edit configuration" in the portal or use PowerShell to change the read-only listener endpoint target.
How does Auto DR work when multiple secondaries exist for a failover group?

The primary server (read write endpoint) and secondary server (designated as read only endpoint) will be used as a pair for Auto DR failover and endpoints will be swapped upon failover.

Learn More

Why ledger verification is non-negotiable

PieterVanhove — Tue, 13 Jan 2026 10:28:01 GMT

Data integrity isn’t just a buzzword, it’s the backbone of trust in any database system. With the ledger functionality in Azure SQL and SQL Server, organizations have a powerful way to ensure their data hasn’t been tampered with. But here’s the catch: many customers implement ledger tables yet skip the critical step of running the ledger verification procedure. This oversight can leave your data vulnerable and your compliance posture shaky.

What is a database digest?

Ledger is a feature that allows SQL Server, Azure SQL Database or Azure SQL Managed Instance to cryptographically link transactions in a tamper-evident manner. Think of it as a blockchain-like mechanism inside your database: every transaction is hashed and chained, creating a block. The hash of the latest block in the database ledger is called the database digest. It represents the state of all ledger tables in the database at the time when the block was generated. These digests can be stored externally, such as in immutable storage or Azure Confidential Ledger, to prevent tampering, providing an independent proof of integrity.

How does ledger verification work?

The ledger verification procedure compares the current state of your ledger tables against the stored digests. It recalculates hashes and validates the chain to confirm that no unauthorized changes have occurred. Without this step, you’re essentially trusting the ledger without verifying it, a dangerous assumption in environments where compliance and security matter.

You can launch the verification by running the following stored procedure:

DECLARE @digest_locations NVARCHAR(MAX) = (SELECT * FROM sys.database_ledger_digest_locations FOR JSON AUTO, INCLUDE_NULL_VALUES); SELECT @digest_locations as digest_locations; BEGIN TRY EXEC sys.sp_verify_database_ledger_from_digest_storage @digest_locations; SELECT 'Ledger verification succeeded.' AS Result; END TRY BEGIN CATCH THROW; END CATCH

Why skipping verification is risky

Many organizations assume that enabling ledger tables is enough. It’s not. If you don’t run verification:

Tampering goes undetected: A malicious actor could alter historical data without triggering alarms.
Compliance gaps: Regulatory frameworks often require proof of integrity, not just theoretical guarantees.
False sense of security: Ledger without verification is like encryption without key management, half a solution.

Benefits of regular verification

Assurance of data integrity: Confirms that your ledger is intact and trustworthy.
Audit readiness: Provides verifiable evidence for compliance audits.
Early detection: Identifies anomalies before they become catastrophic breaches.

Call to action

If you’re using ledger tables in SQL Server or Azure SQL, make verification part of your operational routine. Schedule it. Automate it. Treat it as essential, not optional. Your data, your compliance, and your reputation depend on it.

2025 Year in Review: What’s new across SQL Server, Azure SQL and SQL database in Fabric

Anna Hoffman — Thu, 18 Dec 2025 17:08:23 GMT

What a year 2025 has been for SQL! ICYMI and are looking for some hype, might I recommend you start with this blog from Priya Sathy, the product leader for all of SQL at Microsoft: One consistent SQL: The launchpad from legacy to innovation. In this blog post, Priya explains how we have developed and continue to develop one consistent SQL which “unifies your data estate, bringing platform consistency, performance at scale, advanced security, and AI-ready tools together in one seamless experience and creates one home for your SQL workloads in the era of AI.”

For the FIFTH(!!) year in a row (my heart is warm with the number, I love SQL and #SQLfamily, and time is flying), I am sharing my annual Year in Review blog with all the SQL Server, Azure SQL and SQL database in Fabric news this year. Of course, you can catch weekly episodes related to what’s new and diving deeper on the Azure SQL YouTube channel at aka.ms/AzureSQLYT. This year, in addition to Data Exposed (52 new episodes and over 70K views!). We saw many new series related to areas like GitHub Copilot, SSMS, VS Code, and Azure SQL Managed Instance land in the channel, in addition to Data Exposed.

Microsoft Ignite announcements

Of course, if you’re looking for the latest announcements from Microsoft Ignite, Bob Ward and I compiled this slide of highlights.

Comprehensive list of 2025 updates

You can read this blog (or use AI to reference it later) to get all the updates and references from the year (so much happened at Ignite but before it too!). Here’s all the updates from the year:

SQL Server, Arc-enabled SQL Server, and SQL Server on Azure VMs

Generally Available

Preview

Migrations

Generally Available

Preview

Azure Arc resource discovery in Azure Migrate

Azure SQL Managed Instance

Generally Available

Preview

Azure SQL Database

Generally Available

Preview

Updates across SQL Server, Azure SQL and Fabric SQL database

Generally Available

Preview

Stream data to Azure Event Hubs with Change Event Streaming (Azure SQL DB Public Preview/Fabric SQL Private Preview)
DiskANN vector indexing

SQL database in Microsoft Fabric and Mirroring

Generally Available

Preview

Tools and developer

Blog to Read: How the Microsoft SQL team is investing in SQL tools and experiences
SQL Server Management Studio (SSMS) 22.1
- GitHub Copilot Walkthrough (Preview): Guided onboarding from the Copilot badge.
- Copilot right-click actions (Preview): Document, Explain, Fix, and Optimize.
- Bring your own model (BYOM) support in Copilot (Preview).
- Copilot performance: improved response time after the first prompt in a thread.
- Fixes: addressed Copilot “Run ValidateGeneratedTSQL” loop and other stability issues.
SQL Server Management Studio (SSMS) 22
- Support for SQL Server 2025
- Modern connection dialog as default + Fabric browsing on the Browse tab.
- Windows Arm64 support (initial) for core scenarios (connect + query).
- GitHub Copilot in SSMS (Preview) is available via the AI Assistance workload in the VS Installer.
- T-SQL/UX improvements: open execution plan in new tab, JSON viewer, results grid zooms.
- New index support: create JSON and Vector indexes from Object Explorer
SQL Server Management Studio (SSMS) 21
- Installation and automatic updates via Visual Studio Installer.
- Workloads/components model: smaller footprint + customizable install.
- Git integration is available via the Code tools workload.
- Modern connection dialog experience (Preview).
- New customization options (e.g., vertical tabs, tab coloring, results in grid NULL styling).
- Always Encrypted Assessment in the Always Encrypted Wizard.
- Migration assistance via the Hybrid and Migration workload.
mssql-python Driver
- ODBC: Microsoft ODBC Driver 18.5.2.1 for SQL Server
- OLE DB: Microsoft OLE DB Driver 19.4.1 for SQL Server
- JDBC (latest train): Microsoft JDBC Driver for SQL Server 13.2.1
  - Also updated in 2025: supported JDBC branches received multiple servicing updates (including Oct 13, 2025, security fixes). See the same JDBC release notes for the full list.
- .NET: Microsoft.Data.SqlClient 6.0.2
- Related - some notes on drivers released/updated in 2025 (recap):
MSSQL extension for VS Code 1.37.0
- GitHub Copilot integration : Ask/Agent modes, slash commands, onboarding.
- Edit Data : interactive grid for editing table data (requires mssql.enableExperimentalFeatures: true).
- Data-tier Application dialog : deploy/extract .dacpac and import/export .bacpac (requires mssql.enableExperimentalFeatures: true).
- Publish SQL Project dialog : deploy .sqlproj to an existing DB or a local SQL dev container.
- Added “What’s New” panel + improved query results grid stability/accessibility.
MSSQL extension for VS Code 1.36.0
- Fabric connectivity : browse Fabric workspaces and connect to SQL DBs / SQL analytics endpoints.
- SQL database in Fabric provisioning : create Fabric SQL databases from Deployments.
- GitHub Copilot slash commands : connection, schema exploration, query tasks.
- Schema Compare extensibility: new run command for external extensions/SQL Projects (incl. Update Project from Database support).
- Query results in performance/reliability improvements (incremental streaming, fewer freezes, better settings handling).
SqlPackage 170.0.94 release notes (April 2025)
- Vector: support for vector data type in Azure SQL Database target platform (import/export/extract/deploy/build).
- SQL projects: default compatibility level for Azure SQL Database and SQL database in Fabric set to 170.
- Parquet: expanded supported types (including json, xml, and vector) + bcp fallback for unsupported types.
- Extract: unpack a .dacpac to a folder via /Action:Extract.
- Platform: Remove .NET 6 support; .NET Framework build updated to 4.7.2.
SqlPackage 170.1.61 release notes (July 2025)
- Data virtualization (Azure SQL DB): added support for data virtualization objects in import/export/extract/publish.
- Deployment: new publishing properties /p:IgnorePreDeployScript and /p:IgnorePostDeployScript.
- Permissions: support for ALTER ANY EXTERNAL MIRROR (Azure SQL DB + SQL database in Fabric) for exporting mirrored tables.
- SQL Server 2025 permissions: support for CREATE ANY EXTERNAL MODEL, ALTER ANY EXTERNAL MODEL, and ALTER ANY INFORMATION PROTECTION.
- Fixes: improved Fabric compatibility (e.g., avoid deploying unsupported server objects; fixes for Fabric extraction scripting).
SqlPackage 170.2.70 release notes (October 2025)
- External models: support for external models in Azure SQL Database and SQL Server 2025.
- AI functions: support for AI_GENERATE_CHUNKS and AI_GENERATE_EMBEDDINGS.
- JSON: support for JSON indexes + functions JSON_ARRAYAGG, JSON_OBJECTAGG, JSON_QUERY.
- Vector: vector indexes + VECTOR_SEARCH and expanded vector support for SQL Server 2025.
- Regex: support for REGEXP_LIKE.
Microsoft.Build.Sql 1.0.0 (SQL database projects SDK)
- Breaking: .NET 8 SDK required for dotnet build (Visual Studio build unchanged).
- Globalization support.
- Improved SDK/Templates docs (more detailed README + release notes links).
- Code analyzer template defaults DevelopmentDependency.
- Build validation: check for duplicate build items.
Microsoft.Build.Sql 2.0.0 (SQL database projects SDK)
- Added SQL Server 2025 target platform (Sql170DatabaseSchemaProvider).
- Updated DacFx version to 170.2.70.
- .NET SDK targets imported by default (includes newer .NET build features/fixes; avoids full rebuilds with no changes
Azure Data Studio retirement announcement (retirement February 28, 2026)

Anna’s Pick of the Month Year

It’s hard to pick a highlight representative of the whole year, so I’ll take the cheesy way out: people. I get to work with great people working on a great set of products for great people (like you) solving real world problems for people. So, thank YOU and you’re my pick of the year 🧀

Until next time…

That’s it for now! We release new episodes on Thursdays and new #MVPTuesday episodes on the last Tuesday of every month at aka.ms/azuresqlyt. The team has been producing a lot more video content outside of Data Exposed, which you can find at that link too!

Having trouble keeping up? Be sure to follow us on twitter to get the latest updates on everything, @AzureSQL. And if you lose this blog, just remember aka.ms/newsupdate2025

We hope to see you next YEAR, on Data Exposed!

--Anna and Marisa

Identify causes of auto-resuming serverless workloads in Azure SQL Database

Morgan_Oslake — Tue, 16 Dec 2025 21:41:52 GMT

We are pleased to announce that telemetry is now available in Azure Monitor activity log to identify the causes of auto-resuming serverless workloads in Azure SQL Database. Prior to exposing this telemetry, the correlation of specific auto-resume causes with database activity could be time consuming and imperfect with no programmatic solution.

Serverless auto-pausing and auto-resuming

Serverless in SQL Database automatically scales compute based on workload demand and bills for compute used per second. In the General Purpose tier, serverless also provides an option to automatically pause the database during idle usage periods when only storage related costs are billed. The more a database is idle, the more auto-pausing can help reduce compute costs.

Automatic resuming occurs when database activity returns or certain management related or system operations are performed. Some examples of auto-resume triggers include logins, vulnerability assessment, modification to security settings like data masking rules, and service updates. A comprehensive description of auto-resume triggers is documented in the learning reference for serverless.

Activity log for auto-pause and auto-resume events

The Azure Monitor activity log keeps a record of all auto-pause and auto-resume events for serverless databases. Auto-resume causes are reported in activity log for "Resume Databases" operations under the “Caller” property of the "Succeeded" event, and latencies for each event are reported under “EventProperties”. This event can be monitored to quickly and deterministically identify auto-resume causes without resorting to inefficient guesswork.

Example of Activity log in Azure portal showing an auto-resume event including the cause and latency

In this example, the serverless database is auto-resumed in around 38 seconds in order to perform a security related vulnerability assessment.

Understanding the causes of auto-resuming can help in optimizing database access patterns to minimize auto-resume occurrences, keep the database paused for longer, and reduce compute costs even further.

Learn more

For more information, please see Azure SQL Database serverless and Azure Monitor activity log.

Windows Authentication for Cloud-Native Identities: Modernizing Azure SQL Managed Instance (Preview)

sravani-saluru — Sun, 07 Dec 2025 07:26:57 GMT

Organizations moving to the cloud often face a critical challenge: maintaining seamless authentication for legacy applications without compromising security or user experience. Today, we’re excited to announce support for Windows Authentication for Microsoft Entra principals on Azure SQL Managed Instance, enabling cloud-native identities to authenticate using familiar Windows credentials.

Why This Matters

Traditionally, Windows Authentication relied on on-premises Active Directory, making it difficult for businesses adopting a cloud-only strategy to preserve existing authentication models. With this new capability:

Hybrid Identity Support: Users synchronized between on-premises AD DS and Microsoft Entra ID can continue using a single set of credentials for both environments.
Cloud-Only Identity (Preview): Identities that exist only in Microsoft Entra ID can now leverage Kerberos-based Windows Authentication for workloads like Azure SQL Managed Instance—without requiring domain controllers.

This means organizations can modernize infrastructure while maintaining compatibility with legacy apps, reducing friction during migration.

Key Benefits

Seamless Migration: Move legacy applications to Azure SQL Managed Instance without rewriting authentication logic.
Passwordless Security: Combine Windows Authentication with modern credentials like Windows Hello for Business or FIDO2 keys, enabling MFA and reducing password-related risks.
Cloud-Native Integration: Microsoft Entra Kerberos acts as a cloud-based Key Distribution Center (KDC), issuing Kerberos tickets for cloud resources such as Azure SQL Managed Instance and Azure Files

Breaking Barriers to Cloud Migration

Many enterprises hesitate to migrate legacy apps because they depend on Windows Authentication. By extending this capability to cloud-native identities, we remove a major barrier—allowing customers to modernize at their own pace while leveraging familiar authentication models.

Learn More

Whats new in the Backup/Restore area in SQL Server 2025

Dinakar-Nethi — Tue, 02 Dec 2025 17:39:38 GMT

Following are three “hidden gems” (as one of our customers called them), in the Backup/Restore area we announced with SQL Server 2025.

Backups on Secondary for Always On Availability Groups, ZSTD Compression, and Immutable Backups for Ransomware Protection. These advancements are now ready for production use, built around the needs and requests of the SQL Server customers.

1. Backups on Secondary for SQL Server Always On Availability Groups

Previously in preview, this feature now reaches GA, allowing you to offload backup operations to secondary replicas in Always On Availability Groups. This enhancement optimizes resource utilization and minimizes overhead on primary replicas, ensuring better performance for mission-critical workloads.

What’s New in GA:

Improved reliability and support for production environments.

Key Benefits:

Comprehensive support: Full, differential, and transaction log backups are now fully supported on secondary replicas—not just COPY_ONLY and transaction logs.

Reduced impact on primary replica performance.

Simplified high-availability strategies.

Learn more from the original announcement: Introducing Backups on Secondary for SQL Server Always On Availability Groups.

2. ZSTD Compression in SQL Server 2025

The GA of ZSTD compression brings modern, efficient data compression to SQL Server. ZSTD compression introduces industry-leading performance and efficiency, letting you save storage and speed up workloads.

What’s New in GA:

Full production support for ZSTD across key workloads.

Key Benefits:

Faster compression and decompression compared to legacy algorithms.

Lower storage footprint without sacrificing performance.

Choose your algorithm: ZSTD is now a standard option right alongside MS_XPRESS for row, page, and backup compression.

Tunable compression levels: Administrators can select from LOW, MEDIUM, or HIGH to balance resource use and savings.

Ideal for large-scale data environments.

Explore the preview details: ZSTD Compression in SQL Server 2025.

3. Backups to immutable storage: A Powerful Shield Against Ransomware

Your backups are now safer than ever. Thanks to native support for immutability with Azure Blob Storage, backup files can be rendered tamper-proof—protecting them from ransomware or even accidental deletion.

Key Benefits:

Strong defense against ransomware and malicious tampering.

Compliance with regulatory requirements for data integrity.

Peace of mind for critical backup strategies.

Read the detailed use-case and how-to: Immutability: A Powerful Shield Against Ransomware in SQL Environments.

These features collectively empower organizations to:

Optimize performance and resource utilization.

Reduce operational costs through efficient compression.

Strengthen security posture against evolving threats.

Get Started Today

These features are available to all SQL Server 2025 customers. Ready to elevate your data protection, efficiency, and compliance posture?

Access the official SQL Server 2025 documentation for step-by-step guides via visit Microsoft Learn.

Review upgrade guidance and best practices.

Explore real-world configurations and FAQs.

Upgrade now and unlock the next level of resilience, efficiency, and security for your SQL Server workloads!

Step-by-Step Guide: Route Azure SQL Audit Logs to Multiple Log Analytics Workspaces

sravani-saluru — Fri, 28 Nov 2025 06:55:57 GMT

Scenario:
Many organizations need to route audit logs from Azure SQL Database to more than one Log Analytics workspace. For example, your security team may use Microsoft Sentinel in one workspace, while your application team analyzes logs in another. Azure now makes this possible—here’s how to set it up, and what to watch out for.

Why Send Audit Logs to Multiple Workspaces?

Separation of Duties: Security and application teams can access the logs they need, independently.
Integration with Different Tools: Sentinel may use one workspace for SIEM, while app teams use another for analytics.
Compliance and Regional Needs: Some organizations must store logs in different regions or workspaces for regulatory reasons.

Step-by-Step Guide

Enable Auditing to Log Analytics Workspace

Go to your Azure SQL Server in the Azure Portal.
Under Security, select Auditing.
Set the audit destination to your primary Log Analytics workspace, Click Save.

Tip: Enabling auditing here automatically creates a diagnostic setting for the selected workspace.

Add Diagnostic Settings for Additional Workspaces

In azure portal search for Diagnostic settings.
Search for your subscription and master database of SQL Server to create diagnostics setting at server level
Click + Add diagnostic setting.
Name your setting (e.g., “AuditToAppWorkspace”).
Under Log, select audit, select SQLSecurityAuditEvents (uncheck “DevOpsAudit” if not needed).
Choose an additional Log Analytics workspace as the destination.
Click Save.

create new setting

Note: You can repeat this step to send audit logs to as many workspaces as needed.

Example Use Case

A customer uses:

Workspace A for Microsoft Sentinel (security monitoring)
Workspace B for application analytics

By configuring multiple diagnostic settings, both teams receive the audit data they need—no manual exports required.

Summary

Configuring multiple diagnostic settings allows you to send Azure SQL Database audit logs to several Log Analytics workspaces. This is essential for organizations with different teams or compliance needs. Remember:

Enable auditing first
Add diagnostic settings for each workspace
Monitor for cost and avoid duplicate logs

References:

Azure SQL Database LTR Backup Immutability is now Generally Available

Dinakar-Nethi — Wed, 19 Nov 2025 18:33:38 GMT

Azure SQL Database is a fully managed, always‑up‑to‑date relational database service built for mission‑critical apps. It delivers built‑in high availability, automated backups, and elastic scale, with strong security and compliance capabilities.

Today, I am very excited to announce the General Availability of immutability for Azure SQL DB LTR backups!

Azure SQL Database now supports immutable long‑term retention (LTR) backups, stored in write‑once, read‑many (WORM) state for a fixed (customer configured) period. That means your LTR backups cannot be modified or deleted during the lock window—even by highly privileged identities—helping you preserve clean restore points after a cyberattack and strengthen your compliance posture.

Why this matters: ransomware targets backups

Modern ransomware playbooks don’t stop at encrypting production data—they also attempt to alter or delete backups to block recovery. With backup immutability, Azure SQL Database LTR backups are written to immutable storage and locked for the duration you specify, providing a resilient, tamper‑proof recovery layer so you can restore from a known‑good copy when it matters most.

What we’re announcing

General Availability of Backup Immutability for Long‑Term Retention (LTR) backups in Azure SQL Database. This GA applies to Azure SQL database LTR backups.

What immutability does (and doesn’t) do

Prevents changes and deletion of LTR backup artifacts for a defined, locked period (WORM). This protection applies even to highly privileged identities, reducing the risk from compromised admin accounts or insider misuse.
Helps address regulatory WORM expectations, supporting customers who must retain non‑erasable, non‑rewritable records (for example, requirements under SEC Rule 17a‑4(f), FINRA Rule 4511(c), and CFTC Rule 1.31(c)–(d)). Always consult your legal/compliance team for your specific obligations.
Complements a defense‑in‑depth strategy—it’s not a replacement for identity hygiene, network controls, threat detection, and recovery drills. See Microsoft’s broader ransomware guidance for Azure.

How it works (at a glance)

When you enable immutability on an LTR policy, Azure SQL Database stores those LTR backups on Azure immutable storage in a WORM state. During the lock window, the backup cannot be modified or deleted; after the lock expires, normal retention/deletion applies per your policy.

Key benefits

Ransomware‑resilient recovery: Preserve clean restore points that attackers can’t tamper with during the lock period.
Compliance‑ready retention: Use WORM‑style retention to help meet industry and regulatory expectations for non‑erasable, non‑rewritable storage.
Operational simplicity: Manage immutability alongside your existing Azure SQL Database long‑term retention policies.

Get started

Choose databases that require immutable LTR backups.
Enable immutability on the LTR backup policy and set the retention/lock period aligned to your regulatory and risk requirements.
Validate recovery by restoring from an immutable LTR backup.

Documentation: Learn more about backup immutability for LTR backups in Azure SQL Database in Microsoft Learn.

Tell us what you think

We’d love your feedback on scenarios, guidance, and tooling that would make immutable backups even easier to adopt. Share your experiences and suggestions in the Azure SQL community forums and let us know how immutability is helping your organization raise its cyber‑resilience.

General Availability announcement of Backup/Restore capabilities in SQL Server 2025

Dinakar-Nethi — Wed, 19 Nov 2025 18:15:46 GMT

Over the past several months, we’ve heard from countless customers who are eager for more robust options to protect, compress, and safeguard their SQL Server data. Since introducing these features in public preview, organizations of all sizes have validated their value in real-world workloads and provided invaluable feedback. Today, we are thrilled to announce the General Availability (GA) of three powerful SQL Server 2025 features: Backups on Secondary for Always On Availability Groups, ZSTD Compression, and Immutable Backups for Ransomware Protection. These advancements are now ready for production use, built around the needs and requests of the SQL Server customers.

Backups on Secondary for SQL Server Always On Availability Groups

What’s New in GA:

Improved reliability and support for production environments.

Key Benefits:

Comprehensive support: Full, differential, and transaction log backups are now fully supported on secondary replicas—not just COPY_ONLY and transaction logs.

Reduced impact on primary replica performance.

Simplified high-availability strategies.

Learn more from the original announcement: Introducing Backups on Secondary for SQL Server Always On Availability Groups.

ZSTD Compression in SQL Server 2025

What’s New in GA:

Full production support for ZSTD across key workloads.

Key Benefits:

Faster compression and decompression compared to legacy algorithms.

Lower storage footprint without sacrificing performance.

Choose your algorithm: ZSTD is now a standard option right alongside MS_XPRESS for row, page, and backup compression.

Tunable compression levels: Administrators can select from LOW, MEDIUM, or HIGH to balance resource use and savings.

Ideal for large-scale data environments.

Explore the preview details: ZSTD Compression in SQL Server 2025.

Backups to immutable storage: A Powerful Shield Against Ransomware

Key Benefits:

Strong defense against ransomware and malicious tampering.

Compliance with regulatory requirements for data integrity.

Peace of mind for critical backup strategies.

Read the detailed use-case and how-to: Immutability: A Powerful Shield Against Ransomware in SQL Environments.

These features collectively empower organizations to:

Optimize performance and resource utilization.

Reduce operational costs through efficient compression.

Strengthen security posture against evolving threats.

Get Started Today

These features are available to all SQL Server 2025 customers. Ready to elevate your data protection, efficiency, and compliance posture?

Access the official SQL Server 2025 documentation for step-by-step guides via visit Microsoft Learn.

Review upgrade guidance and best practices.

Explore real-world configurations and FAQs.

Upgrade now and unlock the next level of resilience, efficiency, and security for your SQL Server workloads!

How to get a free Azure SQL Database or Managed Instance

StrahinjaRodic — Wed, 19 Nov 2025 16:56:31 GMT

Next to the performance and security proven engine, with Azure SQL solutions you’re getting dozens of other benefits, such as auto-scaling, auto-patching/maintenance, auto-backups and built-in HA. Free Azure SQL offers fully managed resources with zero cost and zero commitment. There’re two options designed to start for free, test and grow at your pace:

Free Azure SQL Database offer – Ideal for new applications or occasional/light workloads with serverless auto-scale and minimal admin work.

Free Azure SQL Managed Instance offer – Perfect for moderate SQL Server workloads in with near 100% compatibility, cross-DB queries, and SQL Agents.

User can choose one of these two offers or try both of them without any cost!

This guide will help you choose the right option based on your scenario and show you how to get started in minutes. If you already know your way around, skip ahead and start for free now via Azure SQL Hub.

Path #1 – Start, experiment and build new applications in cloud

Azure SQL database free offer is best for building new applications, developing prototypes, or running light workloads in the cloud. This offer lets you create up to 10 Azure SQL databases for free, with no expiration. Each database can use 100,000 vCore-seconds of compute and 32 GB storage per month at no charge – that’s roughly 28 hours of 1 vCore CPU time, refreshed every month, per database. The databases run in the General Purpose tier and are serverless, meaning they automatically scale compute based on load and can pause when idle to save resources.

How to get started with an Azure SQL Database for free

Sign in to Azure and open the Azure SQL Database create page. If you don’t have an Azure account, create one (the Azure Free Account gives you credits and other free services, but this SQL DB free offer works with any subscription). In the Azure Portal, navigate to Azure SQL and choose Create SQL Database – or simply go to the https://aka.ms/azuresqlhub and click “Try Azure SQL Database for free”. This will open the SQL Database deployment blade.
Apply the free offer. At the top of the Create Azure SQL Database form, look for a banner that says “Want to try Azure SQL Database for free?” and click the Apply offer button. (If you used the Try for free link, the offer may be applied automatically.) When applied, you should see the price summary on the right update to Estimated Cost: $0.
Fill in database details. Choose your Azure Subscription and either create or select a Resource Group for this database. Give your database a name (e.g. myFreeDB). For Server, create a new logical server (this is an Azure SQL Server that will host the DB) – provide a unique server name, set admin login and password, and choose a region. Note: All free databases under one subscription must be in the same region (the first free DB’s region becomes fixed for up to 10 free DBs), so pick a region that makes sense for you (ideally where your app runs).
Leave the defaults for compute/storage. In Compute + storage, the form will default to a serverless General Purpose database with a certain compute size. You can always scale later, so it’s fine to start with the defaults.
Set “free limit reached” behavior. In the Basics tab, after applying the offer, you’ll see a setting for Behavior when free limit reached. Choose between:
- Auto-pause the database until next month – if the database runs out of free CPU or storage in a month, it will pause (become inaccessible) until the free quota resets next month. This ensures you never get billed.
- Continue using database for additional charges – the database will not pause if it exceeds free limits; it will continue running and any overage will be billed at standard rates. You still get the first 100k seconds and 32 GB free each month. (Once you choose “continue with charges,” you can’t revert to auto-pause for that database later in the portal).
- If you’re just testing, auto-pause is safest; if you’re building something that needs to run continuously, you might opt to continue (just monitor usage)

Key benefits of the free Database offer

Serverless auto-scaling: The free DB runs in serverless mode, which can automatically pause when idle and automatically resume on activity. This maximizes your free compute: if your app is only active part of the day, the database uses zero vCore seconds while paused.

Monthly reset, no time limit: The free allowances (100k vCore-seconds, 32 GB) renew each month for each database. And unlike some trials, this offer does not expire after several months, you can use it for the lifetime of your subscription. This “free tier” is available to any Azure subscription (new or existing, Pay-Go, CSP, Enterprise, etc.)

Scales with you (optional pay-as-you-go beyond free): If a database hits the free limits in a given month, you have a choice: either let it auto-pause until the next month (so you never incur charges), or switch to Bill overage to keep it running and simply pay for the over-limit usage. Importantly, you don’t lose your data or need to migrate—the transition from free to paid is seamless. And when your database needs more scaling headroom, more storage, or additional performance, switching to other offers in SQL DB is easy, fast, and does not require any application changes. You’ll still enjoy monthly free credits applied to it, and if you stay within the free resource limits each month, it remains completely free.

Path #2 – Already running SQL Server on-premises or in VMs?

Every application needs a database – sometimes just one, sometimes many. Maybe yours began as a small internal tool. Maybe it quietly grew into something business critical. It works. Your application knows how to talk to SQL Server. Your jobs run on schedule. Your database carries years of history, and your backup chain could probably tell the whole story.

Then one day someone asks: “Can we try running this in the cloud?”

The first reaction is often hesitation:

Will everything still work?

Will it be compatible with our SQL Server 20XX version?

Will we need to rewrite part of the app?

And if you’re already running SQL Server (Express, Standard, or Enterprise) and your application depends on features that cloud databases don’t typically support such as:

Isolated environment with dedicated, separate compute

Cross-database queries

SQL Agent jobs

Linked servers

CLR assemblies

Transparent Data Encryption rules already in place

Azure SQL Managed Instance gives you the ability to choose the SQL Server engine (2022, 2025, or always-up-to-date) delivered as a fully managed service – giving you the power of SQL Server with the simplicity of the cloud.

How to get started with SQL MI for free

It’s as easy as it can get – all you need to have is an Azure account for free and Azure subscription. If you already have these two, simply open https://aka.ms/create-free-sqlmi – this link will lead you to create Azure SQL Managed Instance page with free offer automatically applied.

After populating the mandatory (*) fields in the create page, you will get your free SQL managed instance with built-in availability and opened networking defaults. Automatically generated free instance name is customizable as many other options on the create page. After finishing populating the mandatory fields on Basics tab of create page click on "Review + create" and finish creation.

After ~20mins you will be able to find your deployed instance in the Azure portal by using the search bar or finding it within the ‘recent resources’ list on the home page, like on the image below.

After you’ve opened the free SQL MI resource, navigate to the Networking page in Security and copy the public endpoint.

With this endpoint you can now connect to your free SQL managed instance with the tool of your choice, e.g. SSMS 22 or VSCode with MSSQL extension – Voilà! It’s that easy to create a free SQL MI and connect to it.

From here, you can use SSMS Restore wizard or standard T-SQL RESTORE FROM URL command to restore database from backup file. You can either use sample database or your company’s database .bak files to test your real workload with Azure SQL Managed Instance. To restore these after you upload them to Azure Storage.

Key benefits of free Managed Instance offer

You can test your real-life workload for 720vCore hours with a 4-vCore or 8-vCore free SQL managed instance that comes with 64GB of data and backup storage with up to 500 databases.

Benefit	Why it Matters
720vCore hours each month	That means you can run your 4-vCore instance for 180 hours or an 8-vCore instance for 90 hours each month.
Included SQL license	You get hands on enterprise SQL Server – 2022, 2025 or evergreen SQL Server engine version free of charge.
Near 100% compatibility with SQL Server	You don’t have to rewrite your app or re-architect your database model (most of the time)
Start/stop schedule by default	Regular workday (9-5) enabled by default to ensure efficient use (running 4-vCore instance for up to 22 days).
Restore .bak files directly	Upload your backup to Azure storage and restore database. Support for .bak files since SQL Server 2008R2.
SQL Agent Included	Your jobs, schedules, and routines work the way they do today.
Up to 500 databases	With Next-Gen General Purpose tier you can get up to 500 databases.
64GB of data and backup storage	Your database is automatically backed for up to 7 days without by default, and you can store up to 64GB of data.
Automatic Patching and HA	You keep the SQL Server experience you know, without maintaining OS/VMs.

Frequently Asked Questions (FAQs)

What’s the duration of free offer?
- Free Azure SQL Managed Instance offer is available for 12 months since the day of activation for that subscription.
- Free Azure SQL Database offer is available for up to 10 databases per subscription for lifetime.
What happens after the free period?
- Free SQL managed instance will be stopped and you’ll have an option to upgrade it to paid for 30 days. Afterwards it’ll be deleted.
- Free SQL database will be auto-paused until next month unless you explicitly set “Continue using database for additional charges” option for “free limit reached” behavior.
What are the limitations?
- Visit free Azure SQL DB offer limitations page.
- Visit free Azure SQL Managed Instance offer limitations page.
What are the prices for paid Azure SQL SKUs?
Regular prices for Azure SQL services can vary depending on the region, compute model, SQL license and service tier. For more precise information visit:
- Azure SQL Managed Instance pricing
- Azure SQL Database pricing

Closing

Whether you’re building something new or bringing an existing SQL Server workload to the cloud, Azure SQL gives you a way to start free, safely, and on your own terms. No risk, no pressure – just the same familiar SQL experience, with less overhead and more room to grow.

Want to get started with free Azure SQL offers?

Learn more about the free Azure SQL Database offer if you’re building new or serverless workloads.

Learn more about the free Azure SQL Managed Instance offer if you want to test your existing SQL Server workloads in the cloud.

Azure SQL Blog articles

Azure SQL is Deprecating the “No Minimum TLS” (MinTLS None) Configuration

What is changing?

Who is impacted?

Conclusion

Zero Trust for data: Make Microsoft Entra authentication for SQL your policy baseline

Stream data in near real time from SQL MI to Azure Event Hubs - Public preview

How do I modernize an existing application without rewriting it?

What is Change Event Streaming?

Why CES matters for Azure SQL Managed Instance

Incremental modernization for existing applications

Lower operational complexity

Better decoupling across the estate

Typical scenarios

Breaking down monoliths

Real-time integration for line-of-business systems

Real-time analytics

Cache and index refresh

How it works

Conclusion

Availability notes

Useful resources

Database DevOps (preview) in SSMS 22.4.1

Introducing SQL projects in SSMS

What about Visual Studio SQL Server Data Tools (SSDT)?

Get to know SQL projects

Announcing Preview of 160 and 192vCore Premium-series Options for Azure SQL Database Hyperscale

Premium-Series Hyperscale Hardware Overview

Getting started

Resource Limits & Key characteristics

Performance Improvements with 160 and 192 vcores

160 vCores delivers a strong balance of single-query and concurrent performance.

192 vCores is ideal for customers prioritizing maximum throughput, high user concurrency, and large-scale transactional or analytical workloads

TPC-H Power Run (measures single-stream query performance) improves from 217 (128 vCores) to 357 (160 vCores) and remains high at 355 (192 vCores), delivering a +64% increase from 128 → 192 vCores, indicating strong single-query execution and CPU efficiency at larger sizes.

TPC-H Throughput Run (measures multi-stream concurrency) increases from 191 → 360 → 511 QPH, resulting in a +168% gain from 128 → 192 vCores, highlighting significant benefits for highly concurrent, multi-user workloads.

Performance case study (Zava Lending example)

Zava Lending scaled Azure SQL Hyperscale online as demand increased—supporting more users and higher transaction volume with no downtime.

Throughput scaled linearly as compute increased, moving cleanly from 32 → 64 → 128 → 192 vCores to match real workload growth.

192 vCores proved to be the optimal operating point, sustaining peak transaction load without over‑provisioning.

Azure SQL Hyperscale handled mixed OLTP and analytics workloads, including nightly ETL, without becoming a bottleneck.

Every scale operation was performed online, with no service interruption and no application changes.

Preview scope and limitations

During preview:

Next Steps

Versionless keys for Transparent Data Encryption in Azure SQL Database (Generally Available)

Versioned vs. Versionless Key URIs

Versioned Key URI (old approach — explicit version required)

Versionless Key URI (new approach)

Learn more

Stop defragmenting and start living: introducing auto index compaction

Executive summary

Index maintenance without maintenance jobs

Compaction in action

Conclusion

Appendix

Managed Identity Support for Azure SQL Database Import & Export services (preview)

GA of update policy SQL Server 2025 for Azure SQL Managed Instance

What’s new in SQL Server 2025 update policy

Update policy for each modernization strategy

Best practices with the Update policy feature

What’s coming next

Summary

Why Developers and DBAs love SQL’s Dynamic Data Masking (Series-Part 1)

Multiple secondaries for failover groups is now in public preview

What's New?

How to Get Started

Adding Additional Secondary Servers to a Failover Group in the Portal

Using PowerShell

Performing a Failover

Using the Portal

Using PowerShell

Key Benefits

Limitations & Notes

Best Practices

Frequently Asked Questions

Learn More

Why ledger verification is non-negotiable

What is a database digest?

How does ledger verification work?

Why skipping verification is risky

Why Developers and DBAs love SQL’s Dynamic Data Masking (Series-Part 1)