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.