Mirror replication Premium extremely high consumption issue

[DSZ]

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....

[Lozovskyi]

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

[v-sgandrathi]

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!

[v-sgandrathi]

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!

[v-sgandrathi]

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.

[DSZ]

I have an other question on the top why we don't have anymore the option on the UI?

[v-sgandrathi]

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 capacity

Given 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.

[v-sgandrathi]

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.

[DSZ]

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.

[DSZ]

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.

[v-sgandrathi]

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.