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