Azure SQL Blog articles

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

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

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

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

At a glance:

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

Why this matters:

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

You’ve got two straightforward options:

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

Getting started:

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

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

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

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

Pass resource IDs (not names) in your calls

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

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

Portal experience

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

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

Notes

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

Sample 1: REST API — Export using one UAMI:

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

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

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

Sample 3: PowerShell — Export using two UAMIs:

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

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

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

Sample 5: Azure CLI — Export using two UAMIs:

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

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

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

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

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

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

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

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

What’s new in SQL Server 2025 update policy

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

Update policy for each modernization strategy

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

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

Best practices with the Update policy feature

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

What’s coming next

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

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

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

Update policy transitions

Summary

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

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

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

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

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

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

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

Scenario: Hiding customer phone numbers from support queries

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

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

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

Using the ‘Default’ Mask in T-SQL :

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

SQL

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

CREATE TABLE SupportCustomers (

    CustomerID   INT PRIMARY KEY,

    Name         NVARCHAR(100),

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

);

-- Step 2: Insert sample data

INSERT INTO SupportCustomers (CustomerID, Name, Phone)

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

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

CREATE USER SupportAgent WITHOUT LOGIN;

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

GRANT SELECT ON SupportCustomers TO SupportAgent;

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

EXECUTE AS USER = 'SupportAgent';

SELECT Name, Phone FROM SupportCustomers WHERE CustomerID = 1

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

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

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

How this helps Developers :

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

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

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

Less application code to write and maintain for masking

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

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

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

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

Reference Links :

Dynamic Data Masking - SQL Server | Microsoft Learn

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

Multiple secondaries for failover groups is now in public preview

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

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

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

What's New?

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

How to Get Started

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

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

Adding Additional Secondary Servers to a Failover Group in the Portal

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

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

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

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

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

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

Using PowerShell

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

Example - Create a failover group with multiple secondaries:

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

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

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

Performing a Failover

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

Using the Portal

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

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

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

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

Using PowerShell

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

Example:

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

Key Benefits

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

Limitations & Notes

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

Best Practices

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

Frequently Asked Questions

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

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

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

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

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

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

Learn More

Why ledger verification is non-negotiable

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

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

What is a database digest?

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

How does ledger verification work?

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

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

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

Why skipping verification is risky

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

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

Benefits of regular verification

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

Call to action

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

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

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

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

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

Microsoft Ignite announcements

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

Comprehensive list of 2025 updates

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

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

Generally Available

Preview

Migrations

Generally Available

Preview

Azure Arc resource discovery in Azure Migrate

Azure SQL Managed Instance

Generally Available

Preview

Azure SQL Database

Generally Available

Preview

Updates across SQL Server, Azure SQL and Fabric SQL database

Generally Available

Preview

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

SQL database in Microsoft Fabric and Mirroring

Generally Available

Preview

Tools and developer

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

Anna’s Pick of the Month Year

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

Until next time…

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

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

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

--Anna and Marisa

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

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

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

Serverless auto-pausing and auto-resuming

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

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

Activity log for auto-pause and auto-resume events

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

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

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

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

Learn more

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

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

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

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

Why This Matters

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

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

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

Key Benefits

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

Breaking Barriers to Cloud Migration

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

Learn More

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

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

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

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

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

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

What’s New in GA:

Improved reliability and support for production environments.

Key Benefits:

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

Reduced impact on primary replica performance.

Simplified high-availability strategies.

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

2. ZSTD Compression in SQL Server 2025

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

What’s New in GA:

Full production support for ZSTD across key workloads.

Key Benefits:

Faster compression and decompression compared to legacy algorithms.

Lower storage footprint without sacrificing performance.

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

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

Ideal for large-scale data environments.

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

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

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

Key Benefits:

Strong defense against ransomware and malicious tampering.

Compliance with regulatory requirements for data integrity.

Peace of mind for critical backup strategies.

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

These features collectively empower organizations to:

Optimize performance and resource utilization.

Reduce operational costs through efficient compression.

Strengthen security posture against evolving threats.

Get Started Today

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

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

Review upgrade guidance and best practices.

Explore real-world configurations and FAQs.

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

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

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

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

Why Send Audit Logs to Multiple Workspaces?

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

Step-by-Step Guide

Enable Auditing to Log Analytics Workspace

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

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

Add Diagnostic Settings for Additional Workspaces

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

create new setting

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

Example Use Case

A customer uses:

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

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

Summary

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

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

References:

Azure SQL Database LTR Backup Immutability is now Generally Available

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

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

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

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

Why this matters: ransomware targets backups

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

What we’re announcing

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

What immutability does (and doesn’t) do

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

How it works (at a glance)

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

Key benefits

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

Get started

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

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

Tell us what you think

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

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

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

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

Backups on Secondary for SQL Server Always On Availability Groups

What’s New in GA:

Improved reliability and support for production environments.

Key Benefits:

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

Reduced impact on primary replica performance.

Simplified high-availability strategies.

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

ZSTD Compression in SQL Server 2025

What’s New in GA:

Full production support for ZSTD across key workloads.

Key Benefits:

Faster compression and decompression compared to legacy algorithms.

Lower storage footprint without sacrificing performance.

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

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

Ideal for large-scale data environments.

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

Backups to immutable storage: A Powerful Shield Against Ransomware

Key Benefits:

Strong defense against ransomware and malicious tampering.

Compliance with regulatory requirements for data integrity.

Peace of mind for critical backup strategies.

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

These features collectively empower organizations to:

Optimize performance and resource utilization.

Reduce operational costs through efficient compression.

Strengthen security posture against evolving threats.

Get Started Today

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

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

Review upgrade guidance and best practices.

Explore real-world configurations and FAQs.

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

How to get a free Azure SQL Database or Managed Instance

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

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

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

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

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

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

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

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

How to get started with an Azure SQL Database for free

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

Key benefits of the free Database offer

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

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

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

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

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

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

The first reaction is often hesitation:

Will everything still work?

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

Will we need to rewrite part of the app?

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

Isolated environment with dedicated, separate compute

Cross-database queries

SQL Agent jobs

Linked servers

CLR assemblies

Transparent Data Encryption rules already in place

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

How to get started with SQL MI for free

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

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

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

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

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

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

Key benefits of free Managed Instance offer

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

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

Frequently Asked Questions (FAQs)

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

Closing

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

Want to get started with free Azure SQL offers?

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

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

Announcing Public Preview: Auditing for Fabric SQL Database

sravani-saluru — Tue, 18 Nov 2025 17:33:47 GMT

We’re excited to announce the public preview of Auditing for Fabric SQL Database—a powerful feature designed to help organizations strengthen security, ensure compliance, and gain deep operational insights into their data environments.

Why Auditing Matters

Auditing is a cornerstone of data governance. With Fabric SQL Database auditing, you can now easily track and log database activities—answering critical questions like who accessed what data, when, and how. This supports compliance requirements (such as HIPAA and SOX), enables robust threat detection, and provides a foundation for forensic investigations.

Key Highlights

Flexible Configuration: Choose from default “audit everything,” preconfigured scenarios (like permission changes, login attempts, data reads/writes, schema changes), or define custom action groups and predicate filters for advanced needs.

Seamless Access: Audit logs are stored in One Lake, making them easily accessible via T-SQL or One Lake Explorer.

Role-Based Access Control: Configuration and log access are governed by both Fabric workspace roles and SQL-level permissions, ensuring only authorized users can view or manage audit data.

Retention Settings: Customize how long audit logs are retained to meet your organization’s policy.

How It Works

Audit logs are written to a secure, read-only folder in One Lake and can be queried using the sys. fn_get_audit_file_v2 T-SQL function. Workspace and artifact IDs are used as identifiers, ensuring logs remain consistent even if databases move across logical servers. Access controls at both the workspace and SQL database level ensure only the right people can configure or view audit logs.

Example Use Cases

Compliance Monitoring: Validate a full audit trail for regulatory requirements.

Security Investigations: Track specific events like permission changes or failed login attempts.

Operational Insights: Focus on specific operations (e.g., DML only) or test retention policies.

Role-Based Access: Verify audit visibility across different user roles.

Getting Started

You can configure auditing directly from the Manage SQL Auditing blade in the Fabric Portal. Choose your preferred scenario, set retention, and (optionally) define custom filters—all through a simple, intuitive interface.

Learn more about auditing for Fabric SQL database here

Data exposed session with demo here

Generally Available: Azure SQL Managed Instance Next-gen General Purpose

UrosMilanovic — Tue, 02 Dec 2025 22:26:11 GMT

Overview

Next-gen General Purpose is the evolution of General Purpose service tier that brings significantly improved performance and scalability to power up your existing Azure SQL Managed Instance fleet and helps you bring more mission-critical SQL workloads to Azure. We are happy to announce that Next-gen General Purpose is now Generally Available (GA) delivering even more scalability, flexibility, and value for organizations looking to modernize their data platform in a cost-effective way.

The new #SQLMINextGen General Purpose tier delivers a built-in performance upgrade available to all customers at no extra cost. If you are an existing SQL MI General Purpose user, you get faster I/O, higher database density, and expanded storage - automatically.

Summary Table: Key Improvements

Capability	Current GP	Next-gen GP	Improvement
Average I/O Latency	5-10 ms	3-4 ms	2x lower
Max Data IOPS	30-50k	80k	60% better
Max Storage	16 TB	32 TB	2x better
Max Databases/Instance	100	500	5x better
Max vCores	80	128	40% better

But that’s just the beginning.

The new configuration sliders for additional IOPS and memory provide enhanced flexibility to tailor performance according to your requirements. Whether you require more resources for your application or seek to optimize resource utilization, you can adjust your instance settings to maximize efficiency and output.

This release isn’t just about speed - It’s about giving you improved performance where it matters, and mechanisms to go further when you need them.

Customer story - A recent customer case highlights how Hexure reduced processing time by up to 97.2% using Azure SQL Managed Instance on Next-gen General Purpose.

What’s new in Next-gen General Purpose (Nov 2025)?

1. Improved baseline performance with the latest storage tech

Azure SQL Managed Instance is built on Intel® Xeon® processors, ensuring a strong foundation for enterprise workloads. With the next-generation General Purpose tier, we’ve paired Intel’s proven compute power with advanced storage technology to deliver faster performance, greater scalability, and enhanced flexibility - helping you run more efficiently and adapt to growing business needs.

The SQL Managed Instance General Purpose tier is designed with full separation of compute and storage layers. The Classic GP version uses premium page blobs for the storage layer, while the Next-generation GP tier has transitioned to Azure’s latest storage solution, Elastic SAN. Azure Elastic SAN is a cloud-native storage service that offers high performance and excellent scalability, making it a perfect fit for the storage layer of a data-intensive PaaS service like Azure SQL Managed Instance.

Simplified Performance Management

With ESAN as the storage layer, the performance quotas for the Next-gen General Purpose tier are no longer enforced for each database file. The entire performance quota for the instance is shared across all the database files, making performance management much easier (one fewer thing to worry about). This adjustment brings the General Purpose tier into alignment with the Business Critical service tier experience.

2. Resource flexibility and cost optimization

The GA of Next-gen General Purpose comes together with the GA of a transformative memory slider, enabling up to 49 memory configurations per instance. This lets you right-size workloads for both performance and cost. Memory is billed only for the additional amount beyond the default allocation. Users can independently configure vCores, memory, and IOPS for optimal efficiency.

To learn more about the new option for configuring additional memory, check the article: Unlocking More Power with Flexible Memory in Azure SQL Managed Instance.

3. Enhanced resource elasticity through decoupled compute and storage scaling operations

With Next-gen GP, both storage and IOPS can be resized independently of the compute infrastructure, and these changes now typically finish within five minutes - a process known as an in-place upgrade. There are three distinct types of storage upgrade experiences depending on the kind of storage upgrade performed and whether failover occurs.

In-place update: same storage (no data copy), same compute (no failover)
Storage re-attach: Same storage (no data copy), changed compute (with failover)
Data copy: Changed storage (data copy), changed compute (with failover)

The following matrix describes user experience with management operations:

Operation	Data copying	Failover	Storage upgrade type
IOPS scaling	No	No	In-place
Storage scaling*	No*	No	In-place
vCores scaling	No	Yes**	Re-attach
Memory scaling	No	Yes**	Re-attach
Maintenance Window change	No	Yes**	Re-attach
Hardware change	No	Yes**	Re-attach
Update policy change	Yes	Yes	Data copy

* If scale down is >5.5TB, seeding

** In case of update operations that do not require seeding and are not completed in place (examples are scaling vCores, scaling memory, changing hardware or maintenance window), failover duration of databases on the Next-gen General Purpose service tier scales with the number of databases, up to 10 minutes. While the instance becomes available after 2 minutes, some databases might be available after a delay. Failover duration is measured from the moment when the first database goes offline, until the moment when the last database comes online.

Furthermore, resizing vCores and memory is now 50% faster following the introduction of the Faster scaling operations release.

No matter if you have end-of-month peak periods, or there are ups and downs of usage during the weekdays and the weekend, with fast and reliable management operations, you can run multiple configurations over your instance and respond to peak usage periods in a cost-effective way.

4. Reserved instance (RI) pricing

With Azure Reservations, you can commit to using Azure SQL resources for either one or three years, which lets you benefit from substantial discounts on compute costs. When purchasing a reservation, you'll need to choose the Azure region, deployment type, performance tier, and reservation term.

Reservations are only available for products that have reached general availability (GA), and with this update, next-generation GP instances now qualify as well. What's even better is that classic and next-gen GP share the same SKU, just with different remote storage types. This means any reservations you've purchased automatically apply to Next-gen GP, whether you're upgrading an existing classic GP instance or creating a new one.

What’s Next?

The product group has received considerable positive feedback and welcomes continued input. The initial release will not include zonal redundancy; however, efforts are underway to address this limitation. Next-generation General Purpose (GP) represents the future of the service tier, and all existing classic GP instances will be upgraded accordingly. Once upgrade plans are finalized, we will provide timely communication regarding the announcement.

Conclusion

Now in GA, Next-gen General Purpose sets a new standard for cloud database performance and flexibility. Whether you’re modernizing legacy applications, consolidating workloads, or building for the future, these enhancements put more power, scalability, and control in your hands - without breaking the bank.

If you haven’t already, try out the Next-gen General Purpose capabilities for free with Azure SQL Managed Instance free offer. For users operating SQL Managed Instance on the General Purpose tier, it is recommended to consider upgrading existing instances to leverage the advantages of next-gen upgrade – for free.

Welcome to #SQLMINextGen.

Boosted by default. Tuned by you.

Learn more

What is Azure SQL Managed Instance

Try Azure SQL Managed Instance for free

Next-gen General Purpose – official documentation

Analyzing the Economic Benefits of Microsoft Azure SQL Managed Instance

How 3 customers are driving change with migration to Azure SQL

Accelerate SQL Server Migration to Azure with Azure Arc

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

NikolaZagorac — Wed, 19 Nov 2025 21:14:03 GMT

If near-real time integration is something you are looking to implement and you were looking for a simpler way to get the data out of SQL, keep reading. SQL is making it easier to integrate and Change Event Streaming is a feature continuing this trend.

Modern applications and analytics platforms increasingly rely on event-driven architectures and real-time data pipelines. As the businesses speed up, real time decisioning is becoming especially important. Traditionally, capturing changes from a relational database requires complex ETL jobs, periodic polling, or third-party tools. These approaches often consume significant cycles of the data source, introduce operational overhead, and pose challenges with scalability, especially if you need one data source to feed into multiple destinations.

In this context, we are happy to release Change Event Streaming ("CES") feature into Public Preview for Azure SQL Database. This feature enables you to stream row-level changes - inserts, updates, and deletes - from your database directly to Azure Event Hubs in near real time.

Change Event Streaming addresses the above challenges by:

Reducing latency: Changes are streamed (pushed by SQL) as they happen. This is in contrast with traditional CDC (change data capture) or CT (change tracking) based approaches, where an external component needs to poll SQL at regular intervals. Traditional approaches allow you to increase polling frequency, but it gets difficult to find a sweet spot between minimal latency and minimal overhead due to too frequent polls.
Simplifying architecture: No need for Change Data Capture (CDC), Change Tracking, custom polling or external connectors - SQL streams directly to configured destination. This means simpler security profile (fewer authentication points), fewer failure points, easier monitoring, lower skill bar to deploy and run the service. No need to worry about cleanup jobs, etc. SQL keeps track of which changes are successfully received by the destination, handles the retry logic and releases log truncation point. Finally, with CES you have fewer components to procure and get approved for production use.
Decoupling: The integration is done on the database level. This eliminates the problem of dual writes - the changes are streamed at transaction boundaries, once your source of truth (the database) has saved the changes. You do not need to modify your app workloads to get the data streamed - you tap right onto the data layer - this is useful if your apps are dated and do not possess real-time integration capabilities. In case of some 3rd party apps, you may not even have an option to do anything other than database level integration, and CES makes it simpler. Also, the publishing database does not concern itself with the final destination for the data - Stream the data once to the common message bus, and you can consume it by multiple downstream systems, irrespective of their number or capacity - the (number of) consumers does not affect publishing load on the SQL side. Serving consumers is handled by the message bus, Azure Event Hubs, which is purpose built for high throughput data transfers.

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

Key Scenarios for CES

Event-driven microservices: They need to exchange data, typically thru a common message bus. With CES, you can have automated data publishing from each of the microservices. This allows you to trigger business processes immediately when data changes.
Real-time analytics: Stream operational data into platforms like Fabric Real Time Intelligence or Azure Stream Analytics for quick insights.
Breaking down the monoliths: Typical monolithic systems with complex schemas, sitting on top of a single database can be broken down one piece at a time: create a new component (typically a microservice), set up the streaming from the relevant tables on the monolith database and tap into the stream by the new components. You can then test run the components, validate the results against the original monolith, and cutover when you build the confidence that the new component is stable.
Cache and search index updates: Keep distributed caches and search indexes in sync without custom triggers.
Data lake ingestion: Capture changes continuously into storage for incremental processing.
Data availability: This is not a scenario per se, but the amount of data you can tap into for business process mining or intelligence in general goes up whenever you plug another database into the message bus. E.g. You plug in your eCommerce system to the message bus to integrate with Shipping providers, and consequently, the same data stream is immediately available for any other systems to tap into.

How It Works

CES uses transaction log-based capture to stream changes with minimal impact on your workload. Events are published in a structured JSON format following the CloudEvents standard, including operation type, primary key, and before/after values. You can configure CES to target Azure Event Hubs via AMQP or Kafka protocols.

For details on configuration, message format, and FAQs, see the official documentation:

Get Started

Public preview

CES is available today in public preview for Azure SQL Database and as a preview feature in SQL Server 2025.

Private preview

CES is also available as a private preview for Azure SQL Managed Instance and Fabric SQL database: you can request to join the private preview by signing up here: https://aka.ms/sql-ces-signup

We encourage you to try the feature out and start building real-time integrations on top of your existing data. We welcome your feedback—please share your experience through Azure Feedback portal or support channels. The comments below on this blog post will also be monitored, if you want to engage with us. Finally, CES team can be reached via email: sqlcesfeedback [at] microsoft [dot] com.

Useful resources

Free Azure SQL Database.

Free Azure SQL Managed Instance.

General Availability Announcement: Regex Support in SQL Server 2025 & Azure SQL

abhimantiwari — Tue, 18 Nov 2025 16:05:57 GMT

We’re excited to announce the General Availability (GA) of native Regex support in SQL Server 2025 and Azure SQL — a long-awaited capability that brings powerful pattern matching directly into T-SQL. This release marks a significant milestone in modernizing string operations and enabling advanced text processing scenarios natively within the database engine.

What is Regex?

The other day, while building LEGO with my 3-year-old — an activity that’s equal parts joy and chaos — I spent minutes digging for one tiny piece and thought, “If only Regex worked on LEGO.”

That moment of playful frustration turned into a perfect metaphor.

Think of your LEGO box as a pile of data — a colorful jumble of tiny pieces. Now imagine trying to find every little brick from a specific LEGO set your kid mixed into the pile. That’s tricky — you’d have to sift through each piece one by one.

But what if you had a smart filter that instantly found exactly those pieces?

That’s what Regex (short for Regular Expressions) does for your data. It’s a powerful pattern-matching tool that helps you search, extract, and transform text with precision.

With Regex now natively supported in SQL Server 2025 and Azure SQL, this capability is built directly into T-SQL — no external languages or workarounds required.

What can Regex help you do?

Regex can help you tackle a wide range of data challenges, including:

Enhancing data quality and accuracy by validating and correcting formats like phone numbers, email addresses, zip codes, and more.
Extracting valuable insights by identifying and grouping specific text patterns such as keywords, hashtags, or mentions.
Transforming and standardizing data by replacing, splitting, or joining text patterns — useful for handling abbreviations, acronyms, or synonyms.
Cleaning and optimizing data by removing unwanted patterns like extra whitespace, punctuation, or duplicates.

Meet the new Regex functions in T-SQL

SQL Server 2025 introduces seven new T-SQL Regex functions, grouped into two categories: scalar functions (return a value per row) and table-valued functions (TVFs) (return a set of rows). Here’s a quick overview:

Function	Type	Description
REGEXP_LIKE	Scalar	Returns TRUE if the input string matches the Regex pattern
REGEXP_COUNT	Scalar	Counts the number of times a pattern occurs in a string
REGEXP_INSTR	Scalar	Returns the position of a pattern match within a string
REGEXP_REPLACE	Scalar	Replaces substrings that match a pattern with a replacement string
REGEXP_SUBSTR	Scalar	Extracts a substring that matches a pattern
REGEXP_MATCHES	TVF	Returns a table of all matches including substrings and their positions
REGEXP_SPLIT_TO_TABLE	TVF	Splits a string into rows using a Regex delimiter

These functions follow the POSIX standard and support most of the PCRE/PCRE2 flavor of regular expression syntax, making them compatible with most modern Regex engines and tools.

They support common features like:

Character classes (\d, \w, etc.)
Quantifiers (+, *, {n})
Alternation (|)
Capture groups ((...))

You can also use Regex flags to modify behavior:

'i' – Case-insensitive matching
'm' – Multi-line mode (^ and $ match line boundaries)
's' – Dot matches newline
'c' – Case-sensitive matching (default)

REGEXP_LIKE, REGEXP_MATCHES and REGEXP_SPLIT_TO_TABLE functions are available only under compatibility level 170 and above. If your database compatibility level is lower than 170, SQL Server can’t find and run these functions. Other regular expression functions are available at all compatibility levels. You can check compatibility level in the sys.databases view or in database properties. You can change the compatibility level of a database with the following command:

ALTER DATABASE [DatabaseName] SET COMPATIBILITY_LEVEL = 170;

Examples: Regex in Action

Let’s explore how these functions solve tricky real-world data tasks that were hard to do in earlier SQL versions.

REGEXP_LIKE: Data Validation — Keeping data in shape

Validating formats like email addresses or phone numbers used to require multiple functions or external tools. With REGEXP_LIKE, it’s now a concise query. For example, you can check whether an email contains valid characters before and after the @, followed by a domain with at least two letters like .com, .org, or .co.in.

SELECT [Name], Email, CASE WHEN REGEXP_LIKE (Email, '^[A-Za-z0-9._+]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$') THEN 'Valid Email' ELSE 'Invalid Email' END AS IsValidEmail FROM (VALUES ('John Doe', 'john@contoso.com'), ('Alice Smith', 'alice@fabrikam.com'), ('Bob Johnson', 'bob@fabrikam.net'), ('Charlie Brown', 'charlie@contoso.co.in'), ('Eve Jones', 'eve@@contoso.com')) AS e(Name, Email);

We can further use REGEXP_LIKE in CHECK constraints to enforce these rules at the column level (so no invalid format ever gets into the table). For instance:

CREATE TABLE Employees ( ..., Email VARCHAR (320) CHECK (REGEXP_LIKE (Email, '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$')), Phone VARCHAR (20) CHECK (REGEXP_LIKE (Phone, '^(\d{3})-(\d{3})-(\d{4})$')) );

This level of enforcement significantly enhances data integrity by ensuring that only correctly formatted values are accepted into the database.

REGEXP_COUNT: Count JSON object keys

Count how many top-level keys exist in a JSON string — no JSON parser needed!

SELECT JsonData, REGEXP_COUNT(JsonData, '"[^"]+"\s*:', 1, 'i') AS NumKeys FROM (VALUES ('{"name":"Abhiman","role":"PM","location":"Bengaluru"}'), ('{"skills":["SQL","T-SQL","Regex"],"level":"Advanced"}'), ('{"project":{"name":"Regex GA","status":"Live"},"team":["Tejas","UC"]}'), ('{"empty":{}}'), ('{}')) AS t(JsonData);

REGEXP_INSTR: Locate patterns in logs

Find the position of the first error code (ERR-XXXX) in log messages — even when the pattern appears multiple times or in varying locations.

SELECT LogMessage, REGEXP_INSTR(LogMessage, 'ERR-\d{4}', 1, 1, 0, 'i') AS ErrorCodePosition FROM (VALUES ('System initialized. ERR-1001 occurred during startup.'), ('Warning: Disk space low. ERR-2048. Retry failed. ERR-2049.'), ('No errors found.'), ('ERR-0001: Critical failure. ERR-0002: Recovery started.'), ('Startup complete. Monitoring active.')) AS t(LogMessage);

REGEXP_REPLACE: Redact sensitive data

Mask SSNs and credit card numbers in logs or exports — all with a single, secure query.

SELECT sensitive_info, REGEXP_REPLACE(sensitive_info, '(\d{3}-\d{2}-\d{4}|\d{4}-\d{4}-\d{4}-\d{4})', '***-**-****') AS redacted_info FROM (VALUES ('John Doe SSN: 123-45-6789'), ('Credit Card: 9876-5432-1098-7654'), ('SSN: 000-00-0000 and Card: 1111-2222-3333-4444'), ('No sensitive info here'), ('Multiple SSNs: 111-22-3333, 222-33-4444'), ('Card: 1234-5678-9012-3456, SSN: 999-88-7777')) AS t(sensitive_info);

REGEXP_SUBSTR: Extract and count email domains

Extract domains from email addresses and group users by domain.

SELECT REGEXP_SUBSTR(Email, '@(.+)$', 1, 1, 'i', 1) AS Domain, COUNT(*) AS NumUsers FROM (VALUES ('Alice', 'alice@contoso.com'), ('Bob', 'bob@fabrikam.co.in'), ('Charlie', 'charlie@example.com'), ('Diana', 'diana@college.edu'), ('Eve', 'eve@contoso.com'), ('Frank', 'frank@fabrikam.co.in'), ('Grace', 'grace@example.net')) AS e(Name, Email) WHERE REGEXP_LIKE (Email, '^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$') GROUP BY REGEXP_SUBSTR(Email, '@(.+)$', 1, 1, 'i', 1);

REGEXP_MATCHES: Extract multiple emails from text

Extract all email addresses from free-form text like comments or logs — returning each match as a separate row for easy parsing or analysis.

SELECT * FROM REGEXP_MATCHES ('Contact us at support@example.com or sales@example.com', '[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}');

This query identifies and returns both email addresses found in the string — no need for loops, manual parsing, or external scripting.

REGEXP_SPLIT_TO_TABLE: Break down structured text

Split a string into rows using a Regex delimiter — ideal for parsing logs, config entries, or form data.

SELECT * FROM REGEXP_SPLIT_TO_TABLE ('Name: John Doe; Email: john.doe@example.com; Phone: 123-456-7890', '; ');

This query breaks the input string into rows for each field, making it easier to parse and process the data — especially when dealing with inconsistent or custom delimiters.

To explore more examples, syntax options, and usage details, head over to the https://learn.microsoft.com/en-us/sql/t-sql/functions/regular-expressions-functions-transact-sql?view=sql-server-ver17.

Writing complex Regex patterns can be tricky. Let Copilot help you generate and test patterns based on your requirements — right inside your SQL editor. Try asking Copilot for regex patterns!

Conclusion

The addition of Regex functionality in SQL Server 2025 and Azure SQL is a major leap forward for developers and DBAs. It eliminates the need for external libraries, CLR integration, or complex workarounds for text processing.

With Regex now built into T-SQL, you can:

Validate and enforce data formats
Sanitize and transform sensitive data
Search logs for complex patterns
Extract and split structured content

And this is just the beginning. Regex opens the door to a whole new level of data quality, text analytics, and developer productivity — all within the database engine. So go ahead and Regex away!

Your feedback and partnership continue to drive innovation in Azure SQL and SQL Server — thank you for being part of it.

Securing Azure SQL Database with Microsoft Entra Password-less Authentication: Migration Guide

PDasgupta — Tue, 18 Nov 2025 04:35:55 GMT

The Secure Future Initiative is Microsoft’s strategic framework for embedding security into every layer of the data platform—from infrastructure to identity. As part of this initiative, Microsoft Entra authentication for Azure SQL Database offers a modern, password less approach to access control that aligns with Zero Trust principles. By leveraging Entra identities, customers benefit from stronger security postures through multifactor authentication, centralized identity governance, and seamless integration with managed identities and service principals. Onboarding Entra authentication enables organizations to reduce reliance on passwords, simplify access management, and improve auditability across hybrid and cloud environments. With broad support across tools and platforms, and growing customer adoption, Entra authentication is a forward-looking investment in secure, scalable data access.

Migration Steps Overview

Organizations utilizing SQL authentication can strengthen database security by migrating to Entra Id-based authentication. The following steps outline the process.

Identify your logins and users – Review the existing SQL databases, along with all related users and logins, to assess what’s needed for migration.
Enable Entra auth on Azure SQL logical servers by assigning a Microsoft Entra admin.
Identify all permissions associated with the SQL logins & Database users.
Recreate SQL logins and users with Microsoft Entra identities.
Upgrade application drivers and libraries to min versions & update application connections to SQL Databases to use Entra based managed identities.
Update deployments for SQL logical server resources to have Microsoft Entra-only authentication enabled.
For all existing Azure SQL Databases, flip to Entra‑only after validation.
Enforce Entra-only for all Azure SQL Databases with Azure Policies (deny).

Step 1: Identify your logins and users - Use SQL Auditing

Consider using SQL Audit to monitor which identities are accessing your databases. Alternatively, you may use other methods or skip this step if you already have full visibility of all your logins.

Configure server‑level SQL Auditing. For more information on turning the server level auditing: Configure Auditing for Azure SQL Database series - part1 | Microsoft Community Hub

SQL Audit can be enabled on the logical server, which will enable auditing for all existing and new user databases. When you set up auditing, the audit log will be written to your storage account with the SQL Database audit log format.

Use sys.fn_get_audit_file_v2 to query the audit logs in SQL. You can join the audit data with sys.server_principals and sys.database_principals to view users and logins connecting to your databases.

The following query is an example of how to do this:

SELECT (CASE WHEN database_principal_id > 0 THEN dp.type_desc ELSE NULL END) AS db_user_type , (CASE WHEN server_principal_id > 0 THEN sp.type_desc ELSE NULL END) AS srv_login_type , server_principal_name , server_principal_sid , server_principal_id , database_principal_name , database_principal_id , database_name , SUM(CASE WHEN succeeded = 1 THEN 1 ELSE 0 END) AS sucessful_logins , SUM(CASE WHEN succeeded = 0 THEN 1 ELSE 0 END) AS failed_logins FROM sys.fn_get_audit_file_v2( '<Storage_endpoint>/<Container>/<ServerName>', DEFAULT, DEFAULT, '2023-11-17T08:40:40Z', '2023-11-17T09:10:40Z') -- join on database principals (users) metadata LEFT OUTER JOIN sys.database_principals dp ON database_principal_id = dp.principal_id -- join on server principals (logins) metadata LEFT OUTER JOIN sys.server_principals sp ON server_principal_id = sp.principal_id -- filter to actions DBAF (Database Authentication Failed) and DBAS (Database Authentication Succeeded) WHERE (action_id = 'DBAF' OR action_id = 'DBAS') GROUP BY server_principal_name , server_principal_sid , server_principal_id , database_principal_name , database_principal_id , database_name , dp.type_desc , sp.type_desc

Step 2: Enable Microsoft Entra authentication (assign admin)

Follow this to enable Entra authentication and assign a Microsoft Entra admin at the server. This is mixed mode; existing SQL auth continues to work.

WARNING: Do NOT enable Entra‑only (azureADOnlyAuthentications) yet. That comes in Step 7.

Entra admin Recommendation: For production environments, it is advisable to utilize an PIM Enabled Entra group as the server administrator for enhanced access control.

Step 3: Identity & document existing permissions (SQL Logins & Users)

Retrieve a list of all your SQL auth logins. Make sure to run on the master database.:

SELECT * FROM sys.sql_logins

List all SQL auth users, run the below query on all user Databases. This would list the users per Database.

SELECT * FROM sys.database_principals WHERE TYPE = 'S'

Note: You may need only the column ‘name’ to identify the users.

List permissions per SQL auth user:

SELECT database_principals.name , database_principals.principal_id , database_principals.type_desc , database_permissions.permission_name , CASE WHEN class = 0 THEN 'DATABASE' WHEN class = 3 THEN 'SCHEMA: ' + SCHEMA_NAME(major_id) WHEN class = 4 THEN 'Database Principal: ' + USER_NAME(major_id) ELSE OBJECT_SCHEMA_NAME(database_permissions.major_id) + '.' + OBJECT_NAME(database_permissions.major_id) END AS object_name , columns.name AS column_name , database_permissions.state_desc AS permission_type FROM sys.database_principals AS database_principals INNER JOIN sys.database_permissions AS database_permissions ON database_principals.principal_id = database_permissions.grantee_principal_id LEFT JOIN sys.columns AS columns ON database_permissions.major_id = columns.object_id AND database_permissions.minor_id = columns.column_id WHERE type_desc = 'SQL_USER' ORDER BY database_principals.name

Step 4: Create SQL users for your Microsoft Entra identities

You can create users(preferred) for all Entra identities.

Learn more on Create user The "FROM EXTERNAL PROVIDER" clause in TSQL distinguishes Entra users from SQL authentication users.

The most straightforward approach to adding Entra users is to use a managed identity for Azure SQL and grant the required three Graph API permissions. These permissions are necessary for Azure SQL to validate Entra users.

User.Read.All: Allows access to Microsoft Entra user information.
GroupMember.Read.All: Allows access to Microsoft Entra group information.
Application.Read.ALL: Allows access to Microsoft Entra service principal (application) information.

For creating Entra users with non-unique display names, use Object_Id in the Create User TSQL:

-- Retrieve the Object Id from the Entra blade from the Azure portal. CREATE USER [myapp4466e] FROM EXTERNAL PROVIDER WITH OBJECT_ID = 'aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb'

For more information on finding the Entra Object ID: Find tenant ID, domain name, user object ID - Partner Center | Microsoft Learn

Alternatively, if granting these API permissions to SQL is undesirable, you may add Entra users directly using the T-SQL commands provided below. In these scenarios, Azure SQL will bypass Entra user validation.

Create SQL user for managed identity or an application -

This T-SQL code snippet establishes a SQL user for an application or managed identity. Please substitute the `MSIname` and `clientId` (note: use the client id, not the object id), variables with the Display Name and Client ID of your managed identity or application.

-- Replace the two variables with the managed identity display name and client ID declare @MSIname sysname = '<Managed Identity/App Display Name>' declare @clientId uniqueidentifier = '<Managed Identity/App Client ID>'; -- convert the guid to the right type and create the SQL user declare @castClientId nvarchar(max) = CONVERT(varchar(max), convert (varbinary(16), @clientId), 1); -- Construct command: CREATE USER [@MSIname] WITH SID = @castClientId, TYPE = E; declare nvarchar(max) = N'CREATE USER [' + @MSIname + '] WITH SID = ' + @castClientId + ', TYPE = E;' EXEC (@cmd)

For more information on finding the Entra Client ID: Register a client application in Microsoft Entra ID for the Azure Health Data Services | Microsoft Learn

Create SQL user for Microsoft Entra user -

Use this T-SQL to create a SQL user for a Microsoft Entra account. Enter your username and object Id:

-- Replace the two variables with the MS Entra user alias and object ID declare sysname = '<MS Entra user alias>'; -- (e.g., username@contoso.com) declare uniqueidentifier = '<User Object ID>'; -- convert the guid to the right type declare @castObjectId nvarchar(max) = CONVERT(varchar(max), convert (varbinary(16), ), 1); -- Construct command: CREATE USER [@username] WITH SID = @castObjectId, TYPE = E; declare nvarchar(max) = N'CREATE USER [' + + '] WITH SID = ' + @castObjectId + ', TYPE = E;' EXEC (@cmd)

Create SQL user for Microsoft Entra group -

This T-SQL snippet creates a SQL user for a Microsoft Entra group. Set groupName and object Id to your values.

-- Replace the two variables with the MS Entra group display name and object ID declare @groupName sysname = '<MS Entra group display name>'; -- (e.g., ContosoUsersGroup) declare uniqueidentifier = '<Group Object ID>'; -- convert the guid to the right type and create the SQL user declare @castObjectId nvarchar(max) = CONVERT(varchar(max), convert (varbinary(16), ), 1); -- Construct command: CREATE USER [@groupName] WITH SID = @castObjectId, TYPE = X; declare nvarchar(max) = N'CREATE USER [' + @groupName + '] WITH SID = ' + @castObjectId + ', TYPE = X;' EXEC (@cmd)

For more information on finding the Entra Object ID: Find tenant ID, domain name, user object ID - Partner Center | Microsoft Learn

Validate SQL user creation -

When a user is created correctly, the EntraID column in this query shows the user's original MS Entra ID.

select CAST(sid as uniqueidentifier) AS EntraID, * from sys.database_principals

Assign permissions to Entra based users –

After creating Entra users, assign them SQL permissions to read or write by either using GRANT statements or adding them to roles like db_datareader. Refer to your documentation from Step 3, ensuring you include all necessary user permissions for new Entra SQL users and that security policies remain enforced.

Step 5: Update Programmatic Connections

Change your application connection strings to managed identities for SQL authentication and test each app for Microsoft Entra compatibility.

Upgrade your drivers to these versions or newer.

JDBC driver version 7.2.0 (Java)
ODBC driver version 17.3 (C/C++, COBOL, Perl, PHP, Python)
OLE DB driver version 18.3.0 (COM-based applications)
Microsoft.Data.SqlClient 5.2.2+ (ADO.NET)
Microsoft.EntityFramework.SqlServer 6.5.0 (Entity Framework)

System.Data.SqlClient(SDS) doesn't support managed identity; switch to Microsoft.Data.SqlClient(MDS).
If you need to port your applications from SDS to MDS the following cheat sheet will be helpful: https://github.com/dotnet/SqlClient/blob/main/porting-cheat-sheet.md.
Microsoft.Data.SqlClient also takes a dependency on these packages & most notably the MSAL for .NET (Version 4.56.0+).

Here is an example of Azure web application connecting to Azure SQL, using managed identity.

Step 6: Validate No Local Auth Traffic

Be sure to switch all your connections to managed identity before you redeploy your Azure SQL logical servers with Microsoft Entra-only authentication turned on.

Repeat the use of SQL Audit, just as you did in Step 1, but now to confirm that every connection has moved away from SQL authentication.

Once your server is up and running with only Entra authentication, any connections still based on SQL authentication will not work, which could disrupt services.

Test your systems thoroughly to verify that everything operates correctly.

Step 7: Enable Microsoft Entra‑only & disable local auth

Once all your connections & applications are built to use managed identity, you can disable the SQL Authentication, by turning the Entra-only authentication via Azure portal, or using the APIs.

Step 8: Enforce at scale (Azure Policy)

Additionally, after successful migration and validation, it is recommended to deploy the built-in Azure Policy across your subscriptions to ensure that all SQL resources do not use local authentication. During resource creation, Azure SQL instances will be required to have Microsoft Entra-only authentication enabled.

This requirement can be enforced through Azure policies.

Best Practices for Entra-Enabled Azure SQL Applications

Use exponential backoff with decorrelated jitter for retrying transient SQL errors, and set a max retry cap to avoid resource drain.
Separate retry logic for connection setup and query execution.
Cache and proactively refresh Entra tokens before expiration.
Use Microsoft.Data.SqlClient v3.0+ with Azure.Identity for secure token management.
Enable connection pooling and use consistent connection strings.
Set appropriate timeouts to prevent hanging operations.
Handle token/auth failures with targeted remediation, not blanket retries.
Apply least-privilege identity principles; avoid global/shared tokens.
Monitor retry counts, failures, and token refreshes via telemetry.
Maintain auditing for compliance and security.
Enforce TLS 1.2+ (Encrypt=True, TrustServerCertificate=False).
Prefer pooled over static connections.
Log SQL exception codes for precise error handling.
Keep libraries and drivers up to date for latest features and resilience.

References

Use this resource to troubleshoot issues with Entra authentication (previously known as Azure AD Authentication): Troubleshooting problems related to Azure AD authentication with Azure SQL DB and DW | Microsoft Community Hub
To add Entra users from an external tenant, invite them as guest users to the Azure SQL Database's Entra administrator tenant. For more information on adding Entra guest users: Quickstart: Add a guest user and send an invitation - Microsoft Entra External ID | Microsoft Learn

Conclusion

Migrating to Microsoft Entra password-less authentication for Azure SQL Database is a strategic investment in security, compliance, and operational efficiency. By following this guide and adopting best practices, organizations can reduce risk, improve resilience, and future-proof their data platform in alignment with Microsoft’s Secure Future Initiative.

Improved Connectivity Types in Azure SQL Managed Instance

ZoranRilak — Wed, 22 Oct 2025 22:12:31 GMT

As part of its ongoing connectivity overhaul, Azure SQL Managed Instance is removing the last obstacles to broader use of the redirect connection type. The more performant connection type now operates only on port 1433 and provides fallback support for older TDS clients.

What are "Proxy" and "Redirect"?

Proxy and redirect are two different connectivity mechanisms that can be selected on the instance level to govern SQL client connections on managed instances' VNet-local endpoint. These mechanisms implement two separate data flows between a SQL client and the instance's underlying database engine.

When an instance's connection type is set to proxy, an internal gateway component accepts the connection and opens a new one to the primary replica. The gateway then remains involved until the client disconnects, shuttling the data back and forth between the connection from the client and the connection to the database engine – a process commonly known as proxying, hence the name.

By contrast, when an instance's connection type is set to redirect, the gateway immediately tells an incoming T-SQL client to abandon the current connection and connect to the primary replica instead. The client follows up to start talking directly to the SQL engine without the gateway in the picture. This makes the connection more resilient since it no longer breaks when the gateway undergoes a planned failover. It is also more performant since there's no unnecessary copying of the data between a pair of connections.

So, then it would be reasonable to ask...

What's stopping me from using redirect right now?

Good question! Even though it's more performant, redirect wasn't the winning choice in all scenarios until recently.

The client and/or its SQL driver had to understand Tabular Data Stream (TDS) version 7.4 or higher, available since SQL Server 2012 (which is when the TDS redirection handshake was introduced). Older SQL drivers have no mechanism to retarget the primary. Worse, sometimes those older drivers are baked into the client backend or executable, or are written in discontinued frameworks, or may simply not have their source code and build systems available anymore.
The client needed to be able to establish a connection across a broad range of ports where the primary might be listening – from 11000 through 11999. That's a thousand target ports open for inbound traffic! Not only does this number raise the hackles of conscientious InfoSec officers concerned about data exfiltration, but it also creates an additional requirement for your networking that is specific to managed instances. That's yet another service-specific deployment detail to keep track of.

Good news, though: we've removed both limitations!

Redirect now handles older clients as if the "proxy" connection type were set. This happens on a per-connection basis, though, so while modern SQL drivers will be redirected, any older driver will be transparently proxied. Overall, this hardens your entire fleet of clients against transient gateway disconnections and ekes out maximum performance.
Redirect now only requires inbound port 1433 to be open. We've changed the mechanism by which the correct replica is selected so that all replicas now listen on SQL Server's standard TDS port. Simply put, no matter which connection type is set, all managed instances now only expect inbound traffic on port 1433 – and your SQL clients' outbound traffic to managed instances will always only target that port.

So, what's changed?

In a nutshell:

Redirect no longer requires ports 11000-11999 for inbound traffic. When the connection type is set to redirect, a connecting client is no longer redirected to a port in the 11000-11999 range. All redirection requests are now to port 1433.
Redirect may choose to proxy a client based on its capabilities. Older (pre-TDS 7.4) SQL drivers that do not support redirection won't receive a redirect message. Instead, the gateway will proxy them transparently. Because this happens on a per-connection basis, you can have redirect as your connection type and rest assured that any legacy clients will still be able to connect. Doing so hardens your entire fleet of clients against gateway disconnections and ekes out maximum network performance.
New managed instances default to the redirect connection type. If your deployment scripts explicitly set the connection type to proxy, that setting will be respected (see below).
Default connection type is now replaced with redirect. If your deployment doesn't specify this value or sets it to default, then the instance will automatically adopt the redirect connection type. (It may take up to 24 hours for this change to propagate.)
Instances with the connection type set to default prior to October 2025 are now explicitly set to proxy. Because default now evaluates to redirect, we've preserved the previous behavior to avoid confusion.
The new redirect behavior also applies when you connect to the Business Critical tier's secondary replicas via the VNet-local endpoint.

And one thing that stays the same:

If you use failover groups, do keep in mind that the geo-replication traffic still requires ports 11000-11999 to be open. This is a separate requirement that happens to reuse the same range of ports.

What you should do

If you're creating a new managed instance in a new subnet, you're all set; no need to reconfigure anything or open any extra ports. Your new instances will use redirect by default.

For your existing instances and deployment procedures, you may want to change the connection type from proxy to redirect. At the same time:

Verify that your TDS drivers don't misreport their versions or provide only partial support for TDS 7.4. If your clients use the recommended versions of drivers and tools or higher, you're all set. However, we're aware that some organizations may use custom-made TDS drivers and drivers that don't exactly comply with the TDS spec. Or, you might just need additional time to validate your network settings. That's why we're keeping the explicit proxy option around.
Double-check that your clients' network access adheres to the requirements for managed instance VNet-local endpoints. Some of the most common issues we've seen in the past include treating the instance's VNet-local endpoint as if it were a fixed IP address (it does change!) and filtering inbound traffic to allow connections on port 1433 to only the instance's current IP address or FQDN rather than the entire subnet range, as is correct (redirect can target the entire subnet via a service FQDN).

You can learn more about the new redirect behavior in our documentation on the connection types.

Let me know if you find this useful or run into issues. As always, feel free to follow up with a comment or a question and I'll get back to you as soon as possible.

Until next time,
-Zoran

Multiple geo-replicas for Azure SQL Hyperscale is now in public preview

mhyon — Fri, 17 Oct 2025 14:50:25 GMT

Active geo-replication for Azure SQL is a business continuity solution that lets you perform quick disaster recovery of individual databases if there is a regional disaster or a large-scale outage. Up to four geo-secondaries could be created for an Azure SQL database except for Hyperscale, until now.

We’re excited to announce that Azure SQL Database Hyperscale support for up to four geo-replicas is available now in public preview. This enhancement gives you greater flexibility for disaster recovery, regional scale-out, and migration scenarios.

What’s New?

Create up to four read-only geo-replicas for each Hyperscale database, in the same or different Azure regions.
Use the additional geo-replicas to add read scale-out capabilities to additional regions.
More flexibility to facilitate database migrations and zone redundancy changes.

How to Get Started

Getting started with multiple geo-replicas in Azure SQL Hyperscale is straightforward.

In the Azure Portal, you can add multiple geo-replicas using the same process that you currently use to add a geo-replica.

Go to your Hyperscale database in the Azure portal.
Open the “Replicas” blade under “Data management”.
Create a replica from the portal
Click “Create replica”.
TIP: If you want the geo-replica enabled for zone redundancy, remember to click on "Configure database" in the "Compute + storage" section during this step. The zone redundancy setting is not automatically inherited from the primary database when creating the geo-replica.
Select the target server
Review and create

Creating a geo-replica can also be done with command line tools like PowerShell.

Example:

New-AzSqlDatabaseSecondary

-DatabaseName mydb1

-ServerName sqlserver1

-ResourceGroupName myrg

-PartnerResourceGroupName myrg

-PartnerServerName sqlserver2

-AllowConnections “All”

Performing a Failover

Performing a failover in the portal is the same process with multiple geo-replicas. Click on the ellipses in the row of the replica to which you want to fail over and choose Failover or Forced failover.

Perform a failover in the portal

For PowerShell, use the Set-AzSqlDatabaseSecondary cmdlet.

Example:

Set-AzSqlDatabaseSecondary

-DatabaseName mydb1

-PartnerResourceGroupName myrg

-ServerName sqlserver2

-ResourceGroupName myrg

-Failover

Limitations & Notes

You can create up to four geo-replicas per database.
Geo-replicas must be created on different logical servers.
Chaining (creating a geo-replica of a geo-replica) is not supported.
If you would like zone redundancy enabled for the geo-replica, you must configure that setting during the create geo-replica process since the setting is not automatically inherited from the primary database.

Learn More:

Azure SQL Blog articles

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

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

What’s new in SQL Server 2025 update policy

Update policy for each modernization strategy

Best practices with the Update policy feature

What’s coming next

Summary

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

Multiple secondaries for failover groups is now in public preview

What's New?

How to Get Started

Adding Additional Secondary Servers to a Failover Group in the Portal

Using PowerShell

Performing a Failover

Using the Portal

Using PowerShell

Key Benefits

Limitations & Notes

Best Practices

Frequently Asked Questions

Learn More

Why ledger verification is non-negotiable

What is a database digest?

How does ledger verification work?

Why skipping verification is risky

Benefits of regular verification

Call to action

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

Microsoft Ignite announcements

Comprehensive list of 2025 updates

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

Migrations

Azure SQL Managed Instance

Azure SQL Database

Updates across SQL Server, Azure SQL and Fabric SQL database

SQL database in Microsoft Fabric and Mirroring

Tools and developer

Anna’s Pick of the Month Year

Until next time…

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

Serverless auto-pausing and auto-resuming

Activity log for auto-pause and auto-resume events

Learn more

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

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

2. ZSTD Compression in SQL Server 2025

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

Get Started Today

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

Azure SQL Database LTR Backup Immutability is now Generally Available

Why this matters: ransomware targets backups

What we’re announcing

What immutability does (and doesn’t) do

How it works (at a glance)

Key benefits

Get started

Tell us what you think

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

ZSTD Compression in SQL Server 2025

Backups to immutable storage: A Powerful Shield Against Ransomware

Get Started Today

How to get a free Azure SQL Database or Managed Instance

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

How to get started with an Azure SQL Database for free

Key benefits of the free Database offer

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

How to get started with SQL MI for free

Key benefits of free Managed Instance offer

Frequently Asked Questions (FAQs)

Closing

Announcing Public Preview: Auditing for Fabric SQL Database

Generally Available: Azure SQL Managed Instance Next-gen General Purpose

Overview

Summary Table: Key Improvements

Customer story - A recent customer case highlights how Hexure reduced processing time by up to 97.2% using Azure SQL Managed Instance on Next-gen General Purpose.

What’s new in Next-gen General Purpose (Nov 2025)?

1. Improved baseline performance with the latest storage tech

2. Resource flexibility and cost optimization

3. Enhanced resource elasticity through decoupled compute and storage scaling operations

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