Fabric gives you three engines that can all touch the same event stream, and they overlap enough that the choice is a common source of confusion. Pick by skills, latency target, state and the store the results must end up in.
- Eventstreams are the no-code ingestion and routing engine: you add sources, optionally add transformations on a drag-and-drop canvas, and send events to one or more destinations. An eventstream doesn’t store data permanently; it streams events through and forwards them, with a retention buffer of one to 90 days.
- Spark structured streaming runs in notebooks and Spark job definitions. It models a stream as an unbounded table, supports stateful aggregations, joins, deduplication and custom state, and writes primarily to Delta tables in a lakehouse. It suits teams who write PySpark or Scala and need lakehouse (medallion) output.
- Eventhouses store and query streaming data with Kusto Query Language (KQL). They’re described on Learn as the preferred engine for semi-structured and free-text analysis and for time-based events such as telemetry, logs, IoT and security data. Transformations at ingestion time are done with update policies, and pre-aggregation with materialized views.
The engines are often combined: an eventstream brings events in, routes raw events to an eventhouse for sub-second KQL queries, routes a filtered stream to a lakehouse, and hands alert conditions to Fabric Activator (formerly Data Activator). Figure 11.1 compares the three engines side by side.
| Requirement | Eventstream | Spark structured streaming | Eventhouse (KQL) |
|---|---|---|---|
| Authoring style | No-code canvas, optional SQL operator (preview) | PySpark, Scala or Spark SQL code | KQL queries, management commands, update policies |
| Primary output | Routes to eventhouse, lakehouse, Activator, custom endpoint, derived stream | Delta tables in a lakehouse (also Kafka/Event Hubs sinks) | Native KQL tables queried in place |
| Stores data long term | No (retention 1-90 days, default 1 day) | Yes, in Delta tables | Yes (retention default 3,650 days) |
| Stateful processing | Windowed aggregations, joins | Full: aggregations, stream-stream joins, dedupe, custom state | Update policies, materialized views, query-time windowing |
| Processing model | Continuous, event-based processing | Microbatches by default; Real-time Mode on Runtime 2.0 | Near real time with streaming ingestion; up to the batching time (default 5 minutes) with queued ingestion |
| Best fit | Ingest and route events without code | Lakehouse medallion pipelines, complex code-first logic | Interactive analytics, dashboards, time series, log search |
The Fabric decision guide puts it the same way from the storage side: for streaming event data and high-granularity interactive analytics, use an eventhouse; for big data and data engineering over Delta, use a lakehouse.
Spark structured streaming isn’t automatically the lowest-latency option: it runs microbatches by default, and its Real-time Mode needs Fabric Runtime 2.0 and supports only Kafka-compatible sources and sinks or a custom foreach sink, not Delta tables.
Common trap: Choosing an eventstream as the place to keep historical events - an eventstream only buffers events for its retention period (one day by default, 90 days at most) and you can’t explicitly delete them; persist them by routing to an eventhouse or lakehouse.