Forum Discussion
Mirror replication Premium extremely high consumption issue
Dear Community,
We have switched on the CDF opportunity on 1-2 Mirrored database. We have noticed 30% minutes later we are almost knocked out the F32 license fully.
We have on it extremnely small data. 10-20K records. Even the size is small also. Just rising to the sky without no reason. On the dev we have 20 table with 3K records....
14 Replies
looks microsoft fixed now
Hello DSZ,
Thank you for the update. We're glad to hear that your issue has been resolved. If you have any further questions, please feel free to raise a new post in the community. We are always happy to assist.
Please continue using the Microsoft Fabric community forum.
Hi DSZ,
Thank you for bringing this up. The behavior you’re noticing can occur with Mirroring + CDF, even when dealing with a small amount of data.
The main thing to remember is that capacity consumption isn’t just based on row count; it’s also affected by the change tracking and replication processes. When CDF is enabled on mirrored databases, Fabric runs continuous background tasks like capturing changes, keeping logs, and syncing data. These activities can use a lot of compute, especially right after you turn on CDF.
The number of tables matters as well. If you have several tables, even with only a few thousand records each, multiple tracking and processing pipelines are created, which increases CU usage.
Another factor is the initial synchronization phase. After CDF is enabled, the system may do a catch-up or snapshot process, leading to a temporary spike in F32 capacity usage.
To help pinpoint the cause, you can:
Monitor capacity over time to see if usage settles after the initial phaseDisable CDF briefly to check if it’s the main factor
Enable CDF only on necessary tables
Use the Fabric Capacity Metrics app to see which operations are using the most resources.Thankyou.
Sorry to hear this. In its current form, this feature is essentially unusable, especially considering how long customers have been waiting for it.
It does not make sense that processing roughly 3,000 rows across 10 tables with no changes for 1–2 days still consumes such a high percentage of capacity. If this level of usage is driven by a background process, then the implementation is fundamentally flawed.
At this point, it would almost be more cost‑effective to manually track daily changes on paper and have them entered into a change table by a newly hired person. Even a full F16 capacity cannot reasonably be expected to be fully consumed by such a minimal workload, and this level of consumption poses a serious risk to our business operations.
Mirror + CDF was enabled two days ago, and initially nothing was visible until now, when capacity usage has suddenly escalated and is severely impacting our environment. This behavior is not acceptable from a production‑ready feature.
From our perspective, this strongly indicates a serious defect or bug in the implementation that requires immediate attention.
One additional point: if you have a simple Lakehouse with hundreds of tables and a very high volume of changes, enabling CDF will barely won't be noticeable in terms of impact.
As a workaround to avoid using Mirroring + CDF (if those introduce overhead), you could hash all columns periodically for example, every 1h and compare the hashes to detect changes. Even on 10–20 million records, this approach can be cheaper, consuming around 0.x CU, compared to using this feature at all.
Hi DSZ,
I understand your concern, especially since you’re working with a small data set. The capacity spike you’re experiencing after 1–2 days, even without changes, isn’t typical for this type of workload.
While Mirroring and CDF can add some background processing, the delayed spike suggests Fabric might be running deferred tasks like backlog processing or checkpointing. Still, near-full F32 capacity for static data (3K–20K rows) seems unusually high.
Having multiple tables does increase some overhead, but the usage you’re seeing is more than expected. This could point to an inefficiency or issue with background processing, like repeated retries or reprocessing.
To troubleshoot, you could:
Temporarily disable CDF and see if capacity usage drops
Enable CDF on only a small set of important tables and monitorUse the Fabric Capacity Metrics app to track which operations are using capacityGiven the ongoing impact and delayed spike, it’s a good idea to raise a support ticket. Include your Capacity ID and SKU, when the spike started, confirmation of minimal data changes, and screenshots from Capacity Metrics. This information will help the product team investigate any possible backend issues.
Thank you.
I have an other question on the top why we don't have anymore the option on the UI?
Hi DSZ,
That’s a good point. If the option is no longer showing in the UI, it’s likely due to recent changes or specific conditions in Microsoft Fabric, not something on your side. Since Mirroring + CDF features are still developing, some options might be temporarily hidden, moved, or handled differently as updates roll out. Option visibility can also depend on workspace context, like capacity assignment, or the current state of the mirrored database, and once enabled, the UI may not show the same toggle. It’s also helpful to check permissions for any changes in roles. Given the earlier capacity spike and this missing UI option, this doesn’t seem expected. It would be useful to raise a support ticket with details like capacity SKU, when the option disappeared, and screenshots, so the product team can clarify whether this is a UI change, limitation, or a bug.
Thank you.
Hi DSZ,
we haven't heard back from you regarding our last response and wanted to check if your issue has been resolved.Should you have any further questions, feel free to reach out.
Thank you for being a part of the Microsoft Fabric Community Forum!Hi DSZ ,
Have you been able to resolve the issue after raising the support request?If so, feel free to update this thread with the solution, it could go a long way in helping others who might be facing the same problem.
We appreciate your engagement and look forward to hearing from you!
Hello DSZ, could you share a bit more details regarding the setup you have. Source engine, and mirrored db setup.
It seems, you've applied some extras and charged for them.
By default and by the definition, mirroring is free of charge based on your caacity size where units equal to mirrored TB of data.
F32 => 32TB.However, mirroring DB is fully managed by Microsoft and it's highly optimized for ingestions.
If you create notebook and run
%%sql
describe history `<workspace name>`.<mirrored db name>.<schema>.<table>you will see lots of actions done for table performance optimization. If you set your history to more than 1 day (as it's by default), you might be charged exatly for keeping historical data as they are store in versions.As an experiment, I would advise to stop mirroring the existing instance, create new one with default setup and keep it running for some time (few days). Maybe, it will be self healed 🙂
BR, Taras
Hi DSZ,
Hi
Thank you for sharing the additional information, and thanks to Lozovskyi for the helpful explanation about mirroring internals and history retention. The insight about retained table history and background optimization activity affecting capacity usage is useful, especially since mirrored databases handle multiple internal processes for performance and recovery. Testing with a new mirrored instance using default settings, as suggested, should help determine if the issue is related to configuration or history retention, or if it's due to an unexpected backend behavior. Since the capacity consumption is unusually high, it’s still advisable to continue the investigation with a support ticket so the product team can confirm whether the CU usage matches expected behavior for your setup.
Thank you.
