Forum Discussion
Mirror replication Premium extremely high consumption issue
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 phase
Disable 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,
Your workaround of using periodic hashing for change detection is a reasonable option, particularly when you want predictable and lower compute usage with scheduled processing.
However, it’s important to note this method isn’t directly comparable to Mirroring + CDF, since they serve different purposes:
Mirroring + CDF offers continuous, near real-time change tracking with built-in reliability and integration within Fabric.
Hash-based comparison is a batch-oriented, custom solution that trades real-time capability for controlled resource usage.
CDF introduces background processes like change capture, log scanning, and checkpointing, which can use capacity even with minimal or no data changes.
Still, your point about capacity consumption is valid, the delayed spike after 1-2 days with small datasets appears higher than expected.
While hashing can help optimize costs temporarily, the behavior you’re seeing may point to deferred processing, retries, or inefficiencies with small datasets. It’s advisable to raise a support ticket to confirm if this is a backend issue or a known limitation.
Create a Fabric and Power BI Support Ticket - Power BI | Microsoft LearnThank you.
