Forum Discussion
Mirror replication Premium extremely high consumption issue
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.
