A team I was talking with recently had a familiar mid-market reporting problem. Their nightly refresh took eight hours. The data lived in on-premises SQL Server, stitched together with linked servers, and almost none of the tables had indexes. Reports were stale by the time anyone opened them, and if a job failed overnight, they were stale for a full day.

They wanted to move to Fabric and build semantic models on top. The first question on the table was whether to connect the linked server to Eventhouse or Eventstream to “keep the data real time.”

It is a reasonable question. Fabric markets Real-Time Intelligence heavily, and “real time” is exactly what an eight-hour refresh is not. But it was the wrong tool for the job, and the reason why is worth unpacking, because I see this confusion constantly.

Two different questions

Before picking a Fabric item, figure out which question the business is actually asking.

• “Is my data current?” The business wants reports, semantic models and dashboards that reflect what is in the source system right now, not as of last night.
• “Did something just happen?” The business wants to detect and react to events as they occur: a sensor spike, a failed inspection, a suspicious transaction, a log error.

The first question is answered by Mirroring. The second is answered by Eventhouse and Eventstream. Most reporting teams are asking the first question while using the vocabulary of the second.

What Mirroring actually does

Mirroring continuously replicates an operational database into OneLake as Delta tables. After an initial snapshot, only changes flow across. For SQL Server 2016 through 2022, it uses Change Data Capture and connects through an on-premises data gateway. SQL Server 2025 uses its built-in change feed and requires the instance to be connected to Azure Arc.

Three properties make it the right fit for reporting workloads:

• It is one-way. The mirrored database in Fabric is a read-only replica. All inserts, updates and deletes still originate in the source system. For most organizations that is a feature: the system of record stays the system of record.
• It lands in Delta. Mirrored tables can feed a Lakehouse through shortcuts and support Direct Lake semantic models, which read from OneLake without a scheduled import refresh.
• The economics are favorable. Replication compute does not consume capacity, and mirroring storage is free up to 1 TB per capacity unit. You pay for the compute used to query the data, as you would anywhere else in Fabric.

Put those together and the eight-hour window does not get shorter. It goes away.

What Eventhouse actually does

Eventhouse is Fabric’s home for streaming, time-series, log and other event-based data. An Eventhouse contains one or more KQL databases. Eventstream handles ingestion, transformation and routing from sources such as Event Hubs, Kafka, IoT devices and database CDC feeds. Once the data lands in a KQL database, it is organized around arrival time for fast KQL analysis, Real-Time Dashboards and Activator rules.

That is a powerful stack, and it earns its keep when the value is in the event itself: telemetry, logs, fraud signals, operational alerts. It is not designed to be a replica of your ERP tables for a finance semantic model, and using it that way means building and maintaining stream processing for a problem that does not need it.

Side by side

	Mirroring	Eventhouse + Eventstream
Question it answers	Is my data current?	Did something just happen?
Typical source	Operational databases (SQL Server, Azure SQL, Snowflake, Oracle and others)	Event streams: IoT, logs, Kafka, Event Hubs, database CDC
Lands as	Delta tables in OneLake, a read-only replica	Time-indexed tables in a KQL database
Analyze or act with	T-SQL, Spark, Direct Lake semantic models	KQL, T-SQL, Real-Time Dashboards, Activator
Latency	Near real time, continuous replication	Seconds from event to insight or action
Effort	Configure, select tables, done	Design streams, transforms, retention, alerts
Cost profile	Replication compute free; storage free up to 1 TB per CU	Standard capacity consumption for ingestion and queries

The prerequisite nobody wants to hear about

Back to that team with the eight-hour refresh. Mirroring was the answer, but their unindexed tables were a problem for more than query speed.

On SQL Server 2016 through 2022, Mirroring cannot replicate a table without a primary key. A schema built on heaps with no keys is not ready to mirror. Adding primary keys would make mirroring possible. Adding the right indexes would also cut their current refresh time significantly, so the cleanup pays off twice.

A few other limits are worth checking before you commit:

• A maximum of 1,000 tables per mirrored database.
• Some data types do not replicate, including xml, geography, hierarchyid, sql_variant, text/ntext and computed columns.
• Schema changes on 2016-2022 require disabling and re-enabling CDC on the table, which triggers a reseed. Stopping and restarting a mirror reseeds everything.
• Row-level security and object-level permissions in the source do not carry over to OneLake. Plan security on the Fabric side.

None of these are deal-breakers. All of them are cheaper to find in week one than in month three.

When you need both

This does not have to be either/or. Microsoft has added a preview capability that sends Mirroring’s Delta Change Data Feed (CDF) into Eventstream. The pattern is simple: mirror the operational database for reporting, then filter and route row changes, such as a failed inspection or an order over a threshold, to Activator for immediate action. CDF is a paid extended capability enabled at the mirrored-database level, so use it only where incremental event processing is worth the added cost.

The decision rule

If the goal is reports and semantic models that reflect the source system, start with Mirroring.

If the goal is detecting and acting on events in seconds, use Eventstream and Eventhouse.

If the goal is both, mirror first and stream only the changes that need a reaction.

For the team with the eight-hour refresh, the plan became: add primary keys and indexes to the source tables, mirror into Fabric, transform into reporting tables, and build Direct Lake semantic models. No streaming architecture required. Most of the time, “real time” means “current,” and Mirroring is how you get there.