A schema registry is a shared service that stores the agreed shape of the messages flowing through a streaming pipeline and enforces the rules for how that shape may change. When SCADA telemetry moves through a broker like Kafka or Event Hubs, producers and consumers are decoupled and may be updated at different times, so a registry acts as the referee that keeps them speaking the same language. It holds the Avro or Protobuf definitions, versions them, and refuses changes that would break existing readers. This page explains what a registry enforces, how backward and forward compatible evolution works as new tags appear, and how it stops one bad producer from poisoning every consumer.
Schema registry for telemetry in one line: A schema registry is a central store of message schemas, usually Avro or Protobuf, that a streaming platform consults to serialize and validate telemetry. It gives producers and consumers a shared contract, versions each schema, and enforces compatibility rules so that adding or changing fields does not silently break downstream readers.
In a streaming pipeline the producer and the consumer never talk directly; they exchange messages through a broker and may be deployed, restarted, and upgraded independently. That decoupling is powerful but it removes the natural place where two systems agree on a message format. A schema registry restores that agreement by holding the canonical schema for each stream, so a producer registers the shape it writes and a consumer looks up the shape it should expect, and both are working from the same definition rather than from a shared assumption that quietly drifts.
Avro and Protobuf are the usual formats for these contracts because they are compact binary encodings with an explicit, machine-readable schema, unlike free-form JSON where the structure lives only in the code that happens to read it. With a registry, each message on the wire carries a small schema identifier rather than the full schema, so the consumer can fetch the exact definition that produced the bytes and deserialize them correctly. This keeps messages small while guaranteeing the reader always has the right blueprint, even for an old message written by a since-upgraded producer.
The contract also makes the data self-describing in a way plain telemetry rarely is. Field names, types, defaults, and documentation live in the registered schema, so a new consumer or an analytics tool can discover what a stream contains without reverse-engineering it from sample messages. For industrial telemetry, where a single pipeline may carry readings from many device types over many years, this durable, versioned definition of the payload is what keeps the data usable long after the engineers who first designed it have moved on.
Industrial systems are never static: new sites come online, new sensors are added, and a stream that started with a handful of tags grows over time. The registry manages this growth by versioning each schema and checking every proposed new version against a compatibility rule before it is allowed. The two rules that matter most are backward compatibility, meaning a new schema can still read data written under the old one, and forward compatibility, meaning an old consumer can still read data written under the new one. Full compatibility satisfies both.
The reason this is enforced rather than left to good intentions is that producers and consumers upgrade on their own schedules. If a producer starts sending a new field before consumers are ready, forward compatibility ensures the old consumers simply ignore what they do not understand rather than crashing. If a consumer upgrades first and expects a new field, backward compatibility with a default value ensures it can still process older messages that lack it. In practice this means additive changes with defaults are safe, while removing a required field or changing a field's type is a breaking change the registry will reject.
This is exactly the behavior an evolving tag set needs. Adding a new optional measurement to a telemetry schema, giving it a sensible default, and registering the new version lets producers begin emitting it immediately while every existing consumer keeps working untouched, upgrading only when it actually wants the new data. The registry turns what would otherwise be a coordinated flag-day change across the whole pipeline into an incremental, low-risk addition, which is essential when the pipeline spans many independently maintained producers and consumers.
Without a registry, nothing stops a producer from starting to emit malformed or incompatibly changed messages, and the damage lands on the consumers. A single misconfigured field, a type quietly changed from a number to a string, or a renamed key can cause every downstream reader to fail deserialization, and because the bad messages sit in the same stream as good ones, they can stall or crash consumers across the whole pipeline. Diagnosing this after the fact, from a flood of parse errors, is painful and slow.
A registry moves that failure to the left, catching it at the moment the bad schema is proposed rather than after poison messages are already in the stream. When a producer registers a new schema, the registry validates it against the compatibility rules for that stream and rejects it outright if it would break existing consumers, so the incompatible change never reaches the broker in the first place. The producer gets an immediate, clear error at deploy time, which is far easier to fix than a downstream outage traced back through hours of data.
For a platform like Merobix consolidating streaming telemetry from many field sources into a common pipeline, this guardrail is what makes the pipeline safe to evolve at scale. New device types and new tags can be added continuously, each as a compatible schema version, with the registry guaranteeing that no single source can introduce a shape that breaks the dashboards, alerting, and storage reading from the same streams. The result is a pipeline that grows steadily without the periodic breakages that come from unmanaged, ad hoc payload changes.
Backward compatibility means a consumer using the new schema can still read data written under the old schema, which is what lets consumers upgrade before producers. Forward compatibility means a consumer using the old schema can still read data written under the new schema, which is what lets producers upgrade before consumers. Full compatibility satisfies both, so the two sides can upgrade in any order.
A registry works best with a format that has an explicit, machine-readable schema, which is why Avro and Protobuf are the common choices, though some registries also support JSON Schema. These formats let each message reference a compact schema identifier instead of carrying the full definition, so consumers fetch the exact schema that produced the bytes. Free-form JSON without a declared schema gives the registry nothing to enforce.
When a producer tries to register a new schema version, the registry checks it against the stream's compatibility rules and rejects any change that would break existing consumers, such as removing a required field or changing a type. Because the incompatible schema is refused before it reaches the broker, poison messages never enter the stream. The producer sees the error at deploy time rather than causing a downstream outage.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.