Forum Discussion
Post PatronFabric - Mirroring SQLServer MI - update policy
Hi fabricpribeiro,
Hope you're doing well.
The Update Policy is an instance level sitting in AzureSQLMI that controls which SQL engine features are available and how the internal database format is versionning. So, there are 3 update policies available, not just 2 😉 :
- SQL Server 2022 (engine features aligned with SQL Server 2022)
- SQL Server 2025 (engine features alignes with SQL Server 2025)
- Always up to date (always get the latest features as soon as available in Azure)
Q1) SqlMI with SQL Server 2022 update policy should use Fabric mirroring for SQL Server 2016-2022, which uses CDC insted of the change feed.
Q2) Mirroring for SqlMI using the 2025 or always up to date update policies uses the fabric mirroing change feed feauture.
Q3) CDC works by asynchronously scanning the transaction log to find changes, then writing them to dedicate change tables (one per tracked source table). A SQL Server Agent job is responsible for that log scan and write. Fabric's replication layer then polls those change tables and pulls changes into Onelake.
The change feed (2025) is different, rather than routing changes through change tables, the change feed scans the transaction log at high frequency and publishes committed changes directly to a landing zone in Onelake. There are no change tables to maintain, no SQL Server Agent jobs to keep healthy, and no cleanup jobs running in the background purging old change records.
There are also operational differences around schema changes. For example, in SQL Server 2016-2022, when there is a DDL change, mirroring fails with an error saying the table definition has changed since CDC was enabled. In SQL Server 2025, when there is a DDL change, a complete data snapshot restarts for the changed table and data is reseeded automatically.
And the permissions model is cleaner which means rather than requiring sysadmin elevation to configure CDC, SQL Server 2025mirroring uses a system assigned managed identity to handle outbound authentification to Fabric.
Q4) You can enable the SQL Server 2025 update policy via the Azure portal by going to your SqlMI, then sitting, then maintenance and updates, then select the SQL Server 2025 bubble, then confirm. No scripts are required, instead you can use PowerShell/CLI/REST API.
However, there is an irreversibility warning to be aware of, when you change the update policy to SQL Server 2025, the internal database format is upgraded permanently. You cannot change the policy back to SQL Server 2022, and you can no longer use the features and benefits that require the SQL Server 2022 update policy.
Q5) SQL Server 2025 became the default update policy in the Azure portal during last month (March 2026). Since we are now in April 2026, a new instance deployed today will come with SQL Server 2025 by default which is exactly what you are looking for Fabric mirroring whith change feed. So, if you create new instances without explicity specifying the update policy in your IaC templates, you automatically get SQL Server 2025, which is probably what you want, but it should be a conscious decision, not a default you discover later.
Here's my recommandation :
Scenario What you get Action needed New SqlMI deployed today Sql Server 2025 by default confirm in Azure portal, proceed with change feed mirroring Existing SqlMI on 2022 CDC based mirroring, needs data gateway Evaluate upgrading to 2025 (irreversibility!!!) Existing SqlMI on Always up to date change feed mirroring no change needed Here's my advice : (request SQL Server 2025 (or always up to date) before setting up Fabric mirroring) The change feed approach is more robust operationally especially given that schema changes in prod are common and CDC based mirroring will break silently on them. The upgrade itself is just a portal click, but since it is irreversible, make sure the team is aligned and it's done in a controlled change window. Also be aware of that the SQL Server 2022 update policy will reach end of lifetime on January 11 2028, so you will have to migate away from it 🙂
Hope this helps. Feel free to ask me questions if needed, and don’t forget to Accept as Solution if this guidance worked for you. That's motivate me to keep helping.
Best regards,
Oussama (Data Consultant & Fabric's Expert)
Super UserHi fabricpribeiro,
Great questions this is one of the less documented nuances of SQL MI Mirroring. Let me go through each point:
What is the "update policy"?
The update policy controls the SQL Server engine version your Managed Instance uses internally. It has two options:
- SQL Server 2022 update policy → engine aligned with SQL Server 2022 (currently the default for all existing and new instances)
- SQL Server 2025 update policy (= "Always up to date") → engine aligned with SQL Server 2025
Think of it like choosing the SQL engine generation for your MI.
Q1 & Q2 : 2022 uses CDC, 2025 uses Change Feed?
Exactly right :
- 2022 policy → Fabric uses the CDC (Change Data Capture) mechanism → you follow the SQL Server 2016-2022 Mirroring path
- 2025 policy → Fabric uses the native Change Feed mechanism → you follow the Azure SQL MI Mirroring path
Q3 : What's the difference between CDC and Change Feed?
| CDC 2022 | Change Feed (2025) | |
| Latency | Higher | Lower |
| Overhead on source | More | Less |
| Setup | Requires CDC enabled per table | Automatic |
| Maturity | Proven, Stable | Newer, recommanded going forward |
Change Feed is more efficient and is the recommended approach when possible.
Q4 : What do you gain by moving to 2025? Scripts needed?
Benefits: lower replication latency, less overhead, simpler setup (no CDC configuration per table), access to SQL Server 2025 engine features.
The switch is done in the Azure Portal → SQL Managed Instance → Settings → Update Policy. No SQL scripts needed it's a configuration change. However, be aware:
It may involve a brief engine upgrade (similar to a version update)
It cannot easily be reverted once applied
Test in non-production first
Q5 : New instances deployed today which policy?
New instances still default to the SQL Server 2022 update policy. You need to explicitly change it to 2025 during provisioning or after. So yes, if you want Change Feed for Fabric Mirroring, request the 2025 policy before setting up the mirror.
Recommendation for your architecture: if you're designing from scratch, request the SQL Server 2025 update policy upfront it gives you the better mirroring path and future-proofs the instance.
References:
- https://learn.microsoft.com/en-us/azure/azure-sql/managed-instance/update-policy?view=azuresql&tabs=azure-portal
- Tutorial: Configure Mirroring from Azure SQL MI
- Limitations — Azure SQL MI Mirroring
Hope this clarifies the architecture decision!
fabricpribeiroeven, if its 2025 policy, meaning, Always up to date, do I still need to have an on-prem data gateway or a vnet data gateway? or its not necessary ? because I believe that our public interfaces are not available. And as far as I am aware, they seem to be using on-prem gateway, but probably its better to use a Virtual Network Gateway? as probably its faster ? if so, what do I need to configure it?
Thank you so much
- oussamahaimoud
Memorable Member
Hi fabricpribeiro,
If your data is not publicly accessible, you still need a gateway that hasn’t changed.
- If On-prem data → use On-premises Data Gateway.
- If Private Azure (VNet / Private Endpoints) → use VNet Data Gateway.
- If Public endpoints → no gateway needed.
So, in your case (no public access), a gateway is required. Now, the question is which one to choose?
- Stay with On-prem gateway if your data is still on local servers.
- Move to VNet gateway if your data is in Azure (cleaner, managed, no VM).
In conclusion, VNet gateway isn’t automatically faster, it’s just more modern and easier to manage in cloud setups.
- lbendlin
Another point of view: VNet gateways have a much higher cost and you have no control over their mashup engine version. We prefer to use On-Prem gateway over VNet gateway.
