When a plant decides to build its analytics on Microsoft's cloud, the telemetry usually has to pass through a front door before it reaches Synapse, Fabric, or a lakehouse, and Azure Event Hubs is that front door. It is a managed ingestion service designed to swallow high volumes of events and hold them briefly while downstream consumers read at their own pace. This page explains how SCADA telemetry gets published into Event Hubs, how partitioning and throughput units decide whether it keeps up under load, and how Event Hubs Capture quietly writes the stream to storage as it flows.
SCADA to Event Hubs integration in one line: SCADA to Azure Event Hubs integration is the practice of streaming plant telemetry into Azure Event Hubs, a managed event ingestion service that acts as the entry point into Azure analytics like Synapse and Microsoft Fabric. An edge gateway or integration service publishes tag readings as events, often keyed by site so that a site's data stays ordered, and Event Hubs buffers them across partitions for downstream consumers. Capacity is provisioned in throughput units, and Event Hubs Capture can automatically land the raw stream as Parquet files in Azure storage without any additional code.
Inside an event hub, events are spread across a fixed number of partitions, and each partition is an ordered log that a consumer reads in sequence. When a publisher sets a partition key on an event, Event Hubs hashes that key to choose a partition, and all events with the same key land in the same partition, preserving their order relative to one another. For SCADA telemetry, choosing the site or gateway identifier as the partition key is a natural fit, because it keeps every reading from a given site in order while still spreading the overall load across partitions. Keying by something with far too many distinct values, such as an individual tag, can leave partitions unevenly loaded, so the key is usually chosen at the site or asset-group level.
Throughput units are how Event Hubs meters capacity in its standard model, and each unit grants a fixed allowance of ingress and egress. The subtle part for SCADA is that field polling is often bursty rather than smooth. A collector that reads a large block of tags on a synchronized interval will push a spike of events every few seconds and sit quiet in between, and it is the peak of that burst, not the average, that has to fit within the provisioned throughput. Provision for the average and the peaks get throttled, which shows up as publishers being slowed and events backing up at the edge. Sizing for the burst, or smoothing the publish rate at the gateway so the peaks are less severe, is what keeps ingestion clean.
Partition count and throughput interact, because a single partition also has its own ceiling on how fast it can accept and serve events. If all the load is funneled through one partition key, that partition can become a bottleneck even when the overall throughput budget is generous, so a healthy design spreads sites across enough partitions that no single one carries a disproportionate share. Getting the partition key and the partition count right together is usually more important than simply buying more throughput units.
One of the most useful features for a telemetry pipeline is Event Hubs Capture, which automatically writes the events flowing through a hub into Azure storage without any consumer code. Capture is configured with a time and size window, and whenever either threshold is reached it flushes a batch of events into a file, commonly Avro in the native form or Parquet where that output is available, organized into a folder path that encodes the namespace, hub, partition, and timestamp. For a lakehouse built on Azure Data Lake Storage, this means the raw telemetry is landing as analytics-friendly files continuously, as a byproduct of ingestion, rather than requiring a separate job to persist it.
This gives a clean separation between the streaming and the historical views of the same data. A real-time consumer, such as a stream processor or a live dashboard feed, reads events from the hub as they arrive for immediate use, while Capture writes the identical events to storage for the batch and analytics side to pick up later. The files Capture produces become the bronze, or raw, layer of a lakehouse, from which downstream jobs in Synapse or Fabric refine tag readings into cleaned and aggregated tables. Because Capture is driven by the hub itself, there is no risk of a custom persistence job falling behind and losing data during a busy period.
The main things to plan around Capture are the file cadence and the folder layout. Windows that flush too often produce many small files that are inefficient for analytics engines to scan, while windows that flush rarely delay how quickly the historical layer sees fresh data, so the window is tuned to the query patterns downstream. The partition-and-time folder structure Capture writes should also line up with how the lakehouse tables expect to be partitioned, so that queries filtered by time and site can prune files rather than scanning the whole lake.
Event Hubs is deliberately protocol-flexible on the way in, which matters because SCADA edges rarely speak a single language. It accepts events over AMQP and HTTPS, and it exposes a Kafka-compatible endpoint, so a gateway that already publishes to a Kafka topic can often be pointed at Event Hubs with a configuration change rather than a rewrite. This lets a plant standardize its cloud front door on Event Hubs even when the field side is a patchwork of MQTT bridges, Kafka producers, and custom collectors, each feeding the hub through whichever interface it already speaks.
It helps to be clear about what Event Hubs is and is not. It is an ingestion and buffering layer, not a database and not a historian, and it retains events only for a configured window before they age out. Its job is to decouple the field, which produces telemetry continuously and unpredictably, from the analytics systems, which consume on their own schedule, and to absorb bursts so neither side has to match the other's pace exactly. The durable record lives in whatever Capture or a downstream consumer writes to storage, not in the hub itself, so the retention window is sized to cover the longest a consumer might fall behind, not to serve as long-term storage.
This is where a cloud monitoring platform fits alongside Event Hubs rather than competing with it. A platform such as Merobix can collect and normalize SCADA tags at the edge and publish clean, consistently formatted events into the hub, so the Azure analytics stack receives well-shaped telemetry instead of raw device chatter. At the same time, that monitoring layer keeps operators watching current plant state directly, which means Event Hubs and the analytics behind it can focus on the historical and fleet-wide questions while the live operational view is handled where field teams already look.
The site or gateway identifier is usually the right partition key, because it keeps every reading from a given site in order while spreading the overall load across partitions. Keying by individual tag creates too many distinct keys and can leave partitions unevenly loaded, and using no key at all sacrifices per-site ordering. Choosing the key at the site or asset-group level balances ordering against even distribution.
Size throughput units to the peak of your polling bursts rather than the average, because SCADA collectors often read large blocks of tags on a synchronized interval and push spikes of events that must fit within the provisioned capacity. Provisioning for the average causes throttling during the bursts, which backs events up at the edge. Smoothing the publish rate at the gateway can reduce the peaks and let you provision less capacity.
Capture automatically writes the events flowing through a hub into Azure storage as files, without any consumer code, flushing a batch whenever a configured time or size window is reached. This lands the raw telemetry continuously as the bronze layer of a lakehouse, so a real-time consumer and the historical storage both receive the same events. Tuning the flush window trades file size and count against how quickly the historical layer sees fresh data.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.