Vibration and light sensors across a museum network's storage vaults emit millions of timestamped readings per day, and conservation staff need fast time-series queries filtering by branch, sensor type, and time window. Which Fabric data store is designed for this workload?
Select an answer to reveal the explanation.
Short Explanation
Sensor readings pile up fast and mostly get asked about by time window. An Eventhouse is built exactly for that: it stores high-volume telemetry and answers time-series questions through KQL far faster than a general-purpose relational store would.
Full Explanation
An Eventhouse is Fabric's Real-Time Intelligence store for high-volume, time-stamped data like sensor telemetry, and it is queried with KQL, a language purpose-built for time-series filtering, aggregation, and pattern-matching at scale. That combination directly matches conservation staff filtering millions of daily readings by branch, sensor type, and time window. A Warehouse can technically hold time-series data, but its T-SQL, relational-join model is not optimized for the kind of time-windowed, high-cardinality telemetry queries KQL handles natively, and normalized joins add overhead this workload doesn't need. A Power BI report is a visualization and modeling layer that consumes data from an underlying store; it is not itself a data store and cannot ingest or index millions of raw sensor readings per day. A Lakehouse with no Delta tables, holding only raw files, throws away the tabular structure and query performance that even basic sensor analytics needs, and it still lacks the time-series-optimized indexing an Eventhouse provides out of the box. When validating the choice, check that the Eventstream feeding the Eventhouse is configured with an appropriate ingestion and retention policy, since raw telemetry volume can grow quickly and drive up storage and query cost if left unmanaged.