Azure SQL Blog articles

Regex support for LOB types in T-SQL—available in Azure SQL & SQL Server 2025

abhimantiwari — Fri, 22 May 2026 20:28:26 GMT

At a glance — Native regular expression (regex) functions in T-SQL now accept varchar(max) and nvarchar(max) inputs of up to 2 MB across all seven regex functions, including the two table-valued functions (REGEXP_MATCHES and REGEXP_SPLIT_TO_TABLE). This capability ships in SQL Server 2025 CU5 and is already available in Azure SQL Database, SQL Database in Fabric and Azure SQL Managed Instance configured with the Always-up-to-date update policy. It will reach Managed Instances on the SQL Server 2025 update policy as part of the CU5 rollout. You no longer need to split log files, HTML documents, or large JSON payloads into 8,000-byte chunks just to run a pattern match.

1. Introduction

Regular expressions have long been a cornerstone of modern data processing — used for validation, parsing, transformation, and extracting structured insights from unstructured text. With SQL Server 2025 and Azure SQL, regex is now a first-class T-SQL capability, removing the historical need to rely on SQLCLR functions or application-tier processing.

While the initial release made native regex broadly available, large-object (LOB) inputs were not yet supported on every function. CU5 closes that gap.

Under the hood, T-SQL regex implements POSIX Extended Regular Expression (ERE) semantics, augmented by a curated set of Perl-style features, and is powered by the RE2 engine. RE2 is a linear-time, non-backtracking implementation, which means it is not susceptible to catastrophic backtracking (a class of denial-of-service issue commonly known as ReDoS). That guarantee becomes far more important when the input is a 1.8 MB log blob than when it is an 8,000-byte string.

Release timeline

Milestone	What shipped
Ignite 2025 — General Availability	Regex went GA in SQL Server 2025 and Azure SQL. LOB inputs were initially supported only on REGEXP_LIKE, REGEXP_COUNT, and REGEXP_INSTR. LOB support on REGEXP_REPLACE and REGEXP_SUBSTR was deferred, and the two table-valued functions (TVFs) accepted only non-LOB string types.
Azure SQL (post-GA service updates)	LOB inputs enabled across all seven functions.
SQL Server 2025 CU5	LOB inputs up to 2 MB enabled on all seven functions in the SQL Server.

What’s new in CU5

varchar(max) and nvarchar(max) inputs are accepted on every regex function.
The input string is capped at 2 MB per function call. The pattern is still capped at 8,000 bytes, which is far larger than any maintainable regular expression should ever need.
Behavior is consistent between Azure SQL and SQL Server, so code you write today is fully portable.

Note — The 2 MB limit applies to the input passed to a single function call, not to the column or row. A single value in a varchar(max) column can still store up to 2 GB; the constraint is that no single regex evaluation can consume more than 2 MB of that value.

Prerequisites

SQL Server 2025 CU5 or later, or Azure SQL Database, or SQL Database in Fabric or Azure SQL Managed Instance configured with the SQL Server 2025 / Always-up-to-date update policy.
The two table-valued functions (REGEXP_MATCHES and REGEXP_SPLIT_TO_TABLE) require database compatibility level 170, unless the database-scoped configuration ALLOW_BUILTIN_TVF_IN_ALL_COMPAT_LEVELS (preview) is enabled.

Note — On Azure SQL Managed Instance (Always-up-to-date), this capability is rolling out region by region. It is already live in regions where the rollout has completed and will light up in the remaining regions as the deployment finishes. Instances on the SQL Server 2025 update policy will receive it as part of the CU5 rollout — coming soon.

Verify compatibility level (170 required for the TVFs) –

SELECT name, compatibility_level FROM sys.databases WHERE name = DB_NAME(); -- If necessary: -- ALTER DATABASE [<your-database>] SET COMPATIBILITY_LEVEL = 170;

2. Working with LOB Data

This section demonstrates the CU5 capabilities against a realistic LOB data. We build a LogEntries table whose RawPayload column holds multi-KB to multi-MB chunks of web server and application output, plus an HtmlPages table for HTML cleansing examples.

2.1 Create the sample schema and data

IF OBJECT_ID('dbo.LogEntries', 'U') IS NOT NULL DROP TABLE dbo.LogEntries; IF OBJECT_ID('dbo.HtmlPages', 'U') IS NOT NULL DROP TABLE dbo.HtmlPages; CREATE TABLE dbo.LogEntries ( LogId BIGINT IDENTITY(1,1) PRIMARY KEY, Source SYSNAME NOT NULL, IngestedAt DATETIME2(3) NOT NULL DEFAULT SYSUTCDATETIME(), RawPayload VARCHAR(MAX) NOT NULL -- LOB column ); CREATE TABLE dbo.HtmlPages ( PageId INT IDENTITY(1,1) PRIMARY KEY, Url NVARCHAR(2048) NOT NULL, Body NVARCHAR(MAX) NOT NULL -- LOB column (Unicode) );

Now generate realistically large rows. The REPLICATE(CAST(... AS varchar(max)), n) pattern is required because REPLICATE returns NULL when the result would exceed 8,000 bytes unless its first argument is a max type.

-- Synthetic web access-log payload (~252 KB in row 1, plus a separate ~586 KB row). DECLARE @logLine VARCHAR(500) = '127.0.0.1 - alice [21/May/2026:10:15:32 +0000] "GET /api/orders/42 HTTP/1.1" 200 1532 ' + 'user-agent="Mozilla/5.0" ip=10.0.0.7 email=alice@contoso.com card=4111-1111-1111-1234' + CHAR(10); DECLARE @bigLog VARCHAR(MAX) = REPLICATE(CAST(@logLine AS VARCHAR(MAX)), 1500) -- ~252 KB + '127.0.0.1 - mallory [21/May/2026:10:16:01 +0000] "POST /login HTTP/1.1" 500 0 ' + 'ip=203.0.113.99 ssn=123-45-6789' + CHAR(10); INSERT INTO dbo.LogEntries (Source, RawPayload) VALUES ('web-01', @bigLog), -- ~252 KB ('web-02', REPLICATE(CAST('OK ' AS VARCHAR(MAX)), 200000)); -- ~586 KB -- Synthetic HTML page (~775 KB / ~396,000 characters). DECLARE @htmlChunk NVARCHAR(MAX) = N'<div class="row"><p>Hello <b>world</b>! Contact <a href="mailto:bob@contoso.com">bob</a>.</p></div>'; INSERT INTO dbo.HtmlPages (Url, Body) VALUES (N'https://contoso.example/page-1', N'<html><head><title>Big Page</title></head><body>' + REPLICATE(@htmlChunk, 4000) + N'</body></html>'); -- Confirm payload sizes in bytes. SELECT LogId, Source, DATALENGTH(RawPayload) AS PayloadBytes FROM dbo.LogEntries; SELECT PageId, DATALENGTH(Body) AS BodyBytes, LEN(Body) AS BodyChars FROM dbo.HtmlPages;

Results:

LogId	Source	PayloadBytes
1	web-01	258,110
2	web-02	600,000

PageId	BodyBytes	BodyChars
1	792,124	396,062

Before CU5, feeding any of these payloads into REGEXP_REPLACE, REGEXP_SUBSTR, REGEXP_MATCHES, or REGEXP_SPLIT_TO_TABLE would have failed with a type-mismatch error or required a LEFT(RawPayload, 8000)-style truncation. The same queries now run end-to-end.

2.2 REGEXP_LIKE — Filter rows by LOB content

-- Find logs that contain at least one HTTP 5xx response. SELECT LogId, Source, DATALENGTH(RawPayload) AS PayloadBytes FROM dbo.LogEntries WHERE REGEXP_LIKE(RawPayload, '"[A-Z]+\s[^"]+\sHTTP/1\.[01]"\s5[0-9]{2}\s');

REGEXP_LIKE is a Boolean predicate: it evaluates to true when the pattern matches anywhere in the input and false otherwise. Because it returns a Boolean rather than a bit, use it directly in WHERE, CASE WHEN, IIF, or CHECK constraint contexts — do not compare it with = 1 or = 0 (the parser rejects that syntax).

Note — REGEXP_LIKE itself requires database compatibility level 170. The other scalar regex functions (REGEXP_COUNT, REGEXP_INSTR, REGEXP_REPLACE, REGEXP_SUBSTR) are available at all compatibility levels.

Results:

LogId	Source	PayloadBytes
1	web-01	258,110

2.3 REGEXP_COUNT — Counting at scale

-- Per-row tally of GET requests, POST requests, and 5xx responses -- across the entire LOB payload. SELECT LogId, Source, REGEXP_COUNT(RawPayload, '"GET\s') AS Gets, REGEXP_COUNT(RawPayload, '"POST\s') AS Posts, REGEXP_COUNT(RawPayload, '\s5[0-9]{2}\s') AS ServerErrors FROM dbo.LogEntries;

Results:

LogId	Source	Gets	Posts	ServerErrors
1	web-01	1,500	1	1
2	web-02	0	0	0

2.4 REGEXP_INSTR — Locate the first error

-- 1-based character position (or 0 if no match) of the FIRST 5xx response in each payload. SELECT LogId, Source, REGEXP_INSTR(RawPayload, '\s5[0-9]{2}\s', 1, 1, 0) AS FirstErrorPos FROM dbo.LogEntries;

Parameter recap: REGEXP_INSTR(string, pattern, start, occurrence, return_option [, flags [, group ]]). A return_option of 0 returns the starting position of the match; 1 returns the position immediately after the last character of the match.

Results:

LogId	Source	FirstErrorPos
1	web-01	258,072
2	web-02	0

2.5 REGEXP_REPLACE — Redact sensitive data in place

PII redaction over LOB payloads was one of the most-requested CU5 scenarios. Before CU5, it required a custom chunked-replace routine; it is now a single expression.

-- Redact credit-card-shaped tokens, U.S. SSN-shaped tokens, and email addresses -- across the entire payload. SELECT LogId, REGEXP_REPLACE( REGEXP_REPLACE( REGEXP_REPLACE( RawPayload, '\b[0-9]{4}[- ]?[0-9]{4}[- ]?[0-9]{4}[- ]?[0-9]{4}\b', '****-****-****-****'), '\b[0-9]{3}-[0-9]{2}-[0-9]{4}\b', '***-**-****'), '\b[A-Za-z0-9._%+\-]+@[A-Za-z0-9.\-]+\.[A-Za-z]{2,}\b', '[redacted-email]' ) AS RedactedPayload FROM dbo.LogEntries;

Or strip every HTML tag from an nvarchar(max) page in a single call:

SELECT PageId, LEN(Body) AS OriginalLen, LEN(REGEXP_REPLACE(Body, N'<[^>]+>', N'')) AS TextOnlyLen FROM dbo.HtmlPages;

Results — the ~775 KB HTML document collapses from 396,062 to 100,008 characters of plain text in a single call:

PageId	OriginalLen	TextOnlyLen
1	396,062	100,008

2.6 REGEXP_SUBSTR — Extract a single value

-- Pull the first IPv4 address out of each log payload. SELECT LogId, REGEXP_SUBSTR(RawPayload, '\b(?:[0-9]{1,3}\.){3}[0-9]{1,3}\b', 1, -- start position 1, -- occurrence 'c', -- flags: case-sensitive 0 -- group: 0 returns the whole match ) AS FirstIp FROM dbo.LogEntries;

To return the contents of a specific capture group instead of the entire match, pass its 1-based group number as the final argument.

Results:

LogId	FirstIp
1	127.0.0.1
2	NULL

2.7 REGEXP_MATCHES — Every match, set-based

This is where the combination of TVF and LOB delivers the largest productivity gain: extract every structured value from a megabyte of unstructured text in a single set-based query, with no client round-trips.

REGEXP_MATCHES returns one row per match with these columns:

Column	Type	Description
match_id	bigint	Sequence number of the match (1-based).
start_position	int	1-based start index of the match.
end_position	int	1-based end index of the match.
match_value	same type as string_expression	The entire matched substring.
substring_matches	json	JSON array describing each capture group, with the shape [{"value":"…","start":N,"length":N}, …].

-- Every email address in every log payload, alongside its row of origin. SELECT l.LogId, m.match_id, m.match_value AS EmailFound FROM dbo.LogEntries AS l CROSS APPLY REGEXP_MATCHES( l.RawPayload, '\b[A-Za-z0-9._%+\-]+@[A-Za-z0-9.\-]+\.[A-Za-z]{2,}\b' ) AS m ORDER BY l.LogId, m.match_id;

Capture groups are even more useful — you can project the parts of every log line as columns by reading from the substring_matches JSON document:

-- Parse Common-Log-Format-ish entries into ip, user, status, and bytes columns. -- The pattern has four capture groups, accessed below as $[0] through $[3]. SELECT l.LogId, m.match_id, JSON_VALUE(m.substring_matches, '$[0].value') AS Ip, JSON_VALUE(m.substring_matches, '$[1].value') AS UserName, JSON_VALUE(m.substring_matches, '$[2].value') AS Status, JSON_VALUE(m.substring_matches, '$[3].value') AS Bytes FROM dbo.LogEntries AS l CROSS APPLY REGEXP_MATCHES( l.RawPayload, '^([0-9.]+)\s-\s(\S+)\s\[[^\]]+\]\s"[^"]+"\s([0-9]{3})\s([0-9]+)', 'm' -- multi-line: ^ and $ anchor to each line, not just the whole input ) AS m ORDER BY l.LogId, m.match_id;

Important — Without the 'm' flag, the ^ anchor matches only at the start of the entire 250 KB input, so you would receive exactly one match for the first line. The multi-line flag is what unlocks per-line extraction.

Results (first two parsed rows):

LogId	match_id	Ip	UserName	Status	Bytes
1	1	127.0.0.1	alice	200	1532
1	2	127.0.0.1	alice	200	1532

2.8 REGEXP_SPLIT_TO_TABLE — Shred a LOB into rows

-- Project the entire log payload as one row per non-empty line. SELECT l.LogId, s.ordinal AS [LineNo], s.value AS LineText FROM dbo.LogEntries AS l CROSS APPLY REGEXP_SPLIT_TO_TABLE(l.RawPayload, '\r?\n') AS s WHERE l.LogId = 1 AND s.value <> '' ORDER BY s.ordinal;

You now have a tabular projection of a multi-megabyte text blob without leaving the engine. You can feed it into a CTE, aggregate it, join it to dimension tables, or materialize it into a staging table — all set-based.

Results (first three rows):

LogId	ordinal	LineText (first 80 chars)
1	1	127.0.0.1 - alice [21/May/2026:10:15:32 +0000] "GET /api/orders/42 HTTP/1.1" 200
1	2	127.0.0.1 - alice [21/May/2026:10:15:32 +0000] "GET /api/orders/42 HTTP/1.1" 200
1	3	127.0.0.1 - alice [21/May/2026:10:15:32 +0000] "GET /api/orders/42 HTTP/1.1" 200

Tip — composing LOB regex pipelines — CROSS APPLY (and OUTER APPLY when you need to preserve rows that produce no matches) is the primary composition primitive. You can stack REGEXP_SPLIT_TO_TABLE (lines) feeding REGEXP_MATCHES (fields per line) feeding ordinary aggregates, all within a single query plan.

2.9 The 2 MB ceiling — strategies for larger inputs

The 2 MB limit applies to the input string of a single regex call. If the value passed to a regex function exceeds 2 MB, the call raises an error (error number 19311, severity 16) rather than silently truncating. That is the intended behavior — silent truncation would hide correctness bugs.

In practice, 2 MB is a generous ceiling: a single log file or HTML document of that size is already unusual, and most real-world LOB data sit comfortably below it. When individual values do exceed the limit, the most reliable approach is to split them into smaller logical units before they land in the column you want to query — for example, by writing one log line, one document section, or one record per row at ingestion time. Because every regex function (including the two TVFs) shares the same 2 MB ceiling, sharding at query time is not generally feasible; doing it at the load path keeps every regex call well under the limit and avoids per-query workarounds.

Bytes vs. characters — The 2 MB limit is measured in bytes, not characters, and the byte count is based on the UTF-8 encoding of the input regardless of the column’s declared type. ASCII characters take 1 byte each, so plain ASCII text can run to roughly two million characters; non-ASCII characters take 2–4 bytes in UTF-8, so fewer characters fit. Keep in mind that DATALENGTH() reports storage size in the column’s own encoding, which may differ from the UTF-8 byte count used by the limit, and LEN() (which counts characters) is best avoided as a sizing check here.

To measure the UTF-8 byte length that the limit actually checks, cast the value to varchar(max) under a UTF-8 collation and take its DATALENGTH:

SELECT DATALENGTH( CONVERT(varchar(max), Body COLLATE Latin1_General_100_CI_AS_SC_UTF8) ) AS Utf8Bytes FROM dbo.HtmlPages;

Anything above 2 * 1024 * 1024 (2,097,152) bytes will be rejected by a regex call on that value.

Have a scenario that genuinely needs more than 2 MB? If your workload requires regex evaluation on individual values larger than the current 2 MB ceiling, we would like to hear about it. Please share the details — data shape, payload size, pattern, and business need — on the Azure SQL feedback portal. Customer feedback directly informs how we prioritize future limit changes.

2.10 Cleanup

DROP TABLE IF EXISTS dbo.LogEntries; DROP TABLE IF EXISTS dbo.HtmlPages;

3. Summary

What changed in CU5

Before CU5 — LOB inputs were accepted on REGEXP_LIKE, REGEXP_COUNT, and REGEXP_INSTR. The remaining functions — REGEXP_REPLACE, REGEXP_SUBSTR, and the two TVFs (REGEXP_MATCHES, REGEXP_SPLIT_TO_TABLE) — required non-LOB string inputs, which often meant truncating with LEFT(..., 8000) or chunking in the application tier.
After CU5 (and already in Azure SQL) — All seven functions accept varchar(max) and nvarchar(max) inputs of up to 2 MB. The pattern remains capped at 8,000 bytes.

Quick reference

Function	Returns	LOB input (CU5)	Common use case
REGEXP_LIKE	Boolean (predicate)	Yes	Filter rows in WHERE / CASE / CHECK predicates
REGEXP_COUNT	int	Yes	Count occurrences of a pattern
REGEXP_INSTR	int	Yes	Position of the nth match
REGEXP_REPLACE	string	Yes	Redact, cleanse, or normalize text
REGEXP_SUBSTR	string	Yes	Extract a single value
REGEXP_MATCHES (TVF)	(match_id, start_position, end_position, match_value, substring_matches)	Yes	Extract every match plus capture groups (via JSON), set-based
REGEXP_SPLIT_TO_TABLE (TVF)	(value, ordinal)	Yes	Split a LOB into rows by a regex delimiter

Automatic Connectivity Tests for Azure SQL Managed Instance

ZoranRilak — Thu, 14 May 2026 15:56:24 GMT

To further enhance connectivity monitoring and improve service reliability, we’re introducing automatic internal connectivity tests for all Azure SQL Managed Instances. These tests are fully automated and require no action from you. Beginning May 2026, the tests will be continuously performed at regular intervals on all managed instances. By proactively monitoring internal network connections, we’re able to quickly identify potential issues and maintain stable end-to-end connectivity.

These tests are performed from a pair of internal IP addresses from the subnet range that hosts the managed instance, so they do not require any external inbound or outbound connectivity. Please note that additional IP addresses will be reserved for these tests and that tests may leave traces in your observability logs.

Automatic tests diagnose issues in internal service and network availability. This results in accelerated issue discovery and shorter time to mitigate incidents that involve degraded connectivity of managed instances’ internal networking components. This suite of connectivity tests examines internal network connections at several levels, boosting the supportability and visibility into the service’s internal state and offering you peace of mind regarding your managed instances.

Do note that your audit and security systems, if configured to track certain types of events emitted by SQL Server, may record failed login attempts. Those are normal and expected byproducts of the end-to-end connectivity test suite. If you would prefer to not have those events register in your SQL Server audit logs, SQL error logs, or captured Extended Events, we provide you with their event signatures so you can set up event filters or configure your SIEM system to ignore them: Observing failed logins caused by end-to-end tests.

You can read more about the automated connectivity tests at Automatic internal connectivity tests for Azure SQL Managed Instance.

Dynamic Data Masking – What it is, What it isn’t, and How to use it effectively

MadhumitaTripathyMSFT — Mon, 20 Apr 2026 09:09:39 GMT

In this post, we’ll explain the core purpose of Dynamic Data Masking (to ease application development), how it works, and its proper use cases – as well as its limitations. If you’re considering using Dynamic Data Masking or reviewing your data security strategy, this information will help you make informed decisions.

What Dynamic Data Masking is designed for
Dynamic Data Masking Dynamic Data Masking - SQL Server | Microsoft Learn is a database feature that can be used to alter how certain data elements are presented in query results for users who do not have privileged access or required permission. For example, a query on an email column may return a masked value such as jXXX@XXXX.com rather than the full address, depending on user permissions, while the original data remains unchanged in storage.

Masking rules are defined within the database schema and are applied to query results for applicable users at runtime. This approach can simplify application developer’s job and reduce the need for application‑level logic that modifies how sensitive values are displayed across different application(s) or reports. DDM can help prevent accidental or casual exposure of sensitive information.

How Does DDM differ from other security features?
Dynamic Data Masking affects only what users see in query results—it does not protect the underlying data. Unlike encryption Always Encrypted - SQL Server | Microsoft Learn or Row‑Level security Row-Level Security - SQL Server | Microsoft Learn, DDM does not encrypt data, filter rows, or override SQL permissions. Users with elevated privileges (such as UNMASK, db_owner, or sysadmin) always see unmasked data or can modify or remove masking rules.

What DDM doesn’t protect against

Because Dynamic Data Masking is applied when query results are returned, there are several considerations to be aware of:

Inference through queries: In some scenarios, users with database access may be able to make inferences about masked values by applying query filters or conditions that rely on underlying stored data. The database is still comparing the real values under the hood, so these queries work. It’s an expected behavior given DDM’s design.

Privileged users: Users who are granted sufficient database permissions, such as the ability to alter table schemas, can directly disable or remove masking. Users with sysadmin, db_owner or CONTROL permission can view unmasked data. Thus, controlling and auditing who holds such privileges is vital.

Metadata visibility: Masking rules and associated columns can be discoverable through system metadata.

Data movement: Because masking is defined at the schema level in a given database instance, backups or exported datasets may contain unmasked values depending on permissions and configuration.

Understanding these design characteristics is important when incorporating DDM into a broader data governance or privacy strategy.

Proper use and best practices for DDM

Organizations may consider using Dynamic Data Masking in scenarios where consistent display of sensitive values is needed across application(s) or reporting environments. Some implementation considerations include:

Using DDM to help standardize how sensitive fields are displayed in query results and reduce developmental effort for data masking

Combining DDM with other database or access‑control features as part of a layered data protection strategy

Reviewing which users are granted permissions to view unmask data or alter masking configurations.

Implementing auditing or monitoring database activity as part of broader governance practices

Educating internal stakeholders on how masking operates at the query‑result level

Testing masking configurations in non‑production environments prior to deployment

Conclusion

Dynamic Data Masking can be useful in scenarios where organizations want to manage how sensitive data is displayed in application outputs without modifying stored values. It is designed to operate as part of a broader data access or governance approach rather than as a standalone protection mechanism for stored data. When implemented alongside complementary database features and appropriate access controls, DDM may help support more consistent handling of sensitive values across environments.

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

TameikaL — Wed, 29 Apr 2026 18:01:42 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 retired, 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 retired for new servers, and existing servers configured with No Minimum TLS will be upgraded to 1.2.

What is changing?

After July 31, 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 as part of the retirement 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 31, 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 31, 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 31, 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 retirement 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

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.

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 Blog articles

Regex support for LOB types in T-SQL—available in Azure SQL & SQL Server 2025

1. Introduction

Release timeline

What’s new in CU5

Prerequisites

2. Working with LOB Data

2.1 Create the sample schema and data

2.2 REGEXP_LIKE — Filter rows by LOB content

2.3 REGEXP_COUNT — Counting at scale

2.4 REGEXP_INSTR — Locate the first error

2.5 REGEXP_REPLACE — Redact sensitive data in place

2.6 REGEXP_SUBSTR — Extract a single value

2.7 REGEXP_MATCHES — Every match, set-based

2.8 REGEXP_SPLIT_TO_TABLE — Shred a LOB into rows

2.9 The 2 MB ceiling — strategies for larger inputs

2.10 Cleanup

3. Summary

What changed in CU5

Quick reference

Further reading

Automatic Connectivity Tests for Azure SQL Managed Instance

Dynamic Data Masking – What it is, What it isn’t, and How to use it effectively

Azure SQL is Retiring 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

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