What it does

Sets expectations for data freshness when Link to Fabric replicates Dataverse data into Microsoft Fabric. It groups real production workloads by load pattern — how much data changes and how it arrives — so you can find the profile closest to your environment and use its measured latency as a planning reference.

Key facts

• Figures are indicative telemetry from real environments, not an SLA. They shift with volume, churn, table mix and configuration.
• Freshness depends far more on load pattern than on industry or app family. The headline measure is P95 freshness latency (95% of changes land within it).
• Typical CRM and mainstream ERP workloads: most changes land within a few minutes, most within ~10 minutes. Only at very high volume (hundreds of millions of changes/day) does the typical figure itself reach tens of minutes.
• Reference points from the article's measured high-volume tables (P50 / P95): moderate CRM ~2 min / ~19 min; steady ERP posting ~1.5 min / ~13 min; extreme continuous ERP ~7 min / ~47 min; invoice-burst ERP ~10 min / ~92 min.
• Main drivers of slower sync: large initial load, high data churn, wide/large tables, many tables sharing throughput, long-running source transactions holding the watermark, and Change Data Feed (CDF) on the Delta tables.
• Numbers are measured on the top five high-volume tables per environment — deliberately the worst case. Low-volume tables sync much faster.

When to use / skip

Reach for this when a client asks "how fresh will my Fabric data be?" and you need a defensible planning answer rather than a guess. Use it to set tolerance expectations before committing to near-real-time reporting off replicated Dataverse data. Skip it if you're only moving low-volume config tables — those land fast and the worst-case figures here will mislead you into over-engineering.

Configuration decisions

• Which load pattern in the article actually matches the client — get the change-volume-per-day and table mix before picking a profile.
• Whether to enable Change Data Feed: it adds change-tracking work to every write and increases latency, so only turn it on where a downstream consumer genuinely needs it.
• How many tables to put in a single link — throughput is shared, so splitting very heavy tables out can help freshness on the ones that matter.
• Whether your reporting SLA can live with the P95 tail, not just the median.

Gotchas

• Latency is measured from a row's modified timestamp, and some parent-row resyncs don't bump that timestamp — which can produce false, extremely high latency readings. Don't panic at an outlier on a table with unreliable timestamps.
• Environment operations (solution installs, platform/environment upgrades) temporarily consume capacity and slow sync while they run — expect spikes during release windows.
• Heavy or long-running transaction locks on a table block the sync engine from reading those rows until the locks release, so a batchy source app produces lagging tails unrelated to overall load.
• Burst workloads (invoice runs, mass postings) briefly outrun the sync path; the backlog drains and freshness returns — but the P95 during the burst can be an order of magnitude worse than steady state.

Consultant notes

• The single most useful thing you can do on a Fabric-reporting engagement is reset the "real-time" expectation early. Clients hear replication and assume seconds; show them the P95 tail for a workload like theirs and design the dashboards' refresh cadence around it.
• Profile the client's actual churn before quoting a number. The industry label is nearly irrelevant — a "financial services" tenant with light change behaves nothing like one running continuous posting.
• CDF is the quiet latency tax. If someone enabled it speculatively, that alone can explain freshness complaints; check for it before blaming the platform.
• For burst-heavy ERP customers (utility billing, month-end), plan reporting SLAs around the burst window, not the steady state — that's where the 90-minute-plus tails live.

---

Planning reference — figures are point-in-time telemetry; revisit if Microsoft republishes the measured latencies or CDF behaviour changes.