If you spend any time around Industry 4.0, industrial data architecture, or modern manufacturing software, you\u2019ll hear two terms thrown around a lot: Unified Namespace (UNS)<\/strong> and MQTT<\/strong>.<\/p>\n They\u2019re related, but they are not the same thing<\/strong>.<\/p>\n That confusion matters because it leads to bad architectural decisions. I\u2019ve seen teams say they are \u201cbuilding an UNS\u201d when what they really mean is \u201cwe installed an MQTT broker.\u201d That\u2019s like saying you\u2019ve designed a city because you poured a road.<\/p>\n MQTT can be part of a Unified Namespace architecture. In many cases, it\u2019s a very good fit. But MQTT is the transport. A UNS is the information architecture.<\/p>\n If you get that distinction wrong, you can end up with a connected system that still isn\u2019t usable.<\/p>\n Here\u2019s the simplest way to think about it:<\/p>\n MQTT is a lightweight publish\/subscribe protocol. It helps systems exchange messages efficiently.<\/p>\n A Unified Namespace is a structured, governed way of organising industrial and business data so that different systems can share a common context.<\/p>\n You can implement an UNS using MQTT. But MQTT on its own is not an UNS.<\/p>\n MQTT is a messaging protocol built around publish\/subscribe communication.<\/p>\n A publisher sends a message to a topic. A subscriber listens to that topic. A broker sits in the middle and handles delivery.<\/p>\n That\u2019s useful because it allows systems to exchange data without every producer being tightly coupled to every consumer.<\/p>\n In manufacturing, that makes MQTT attractive for:<\/p>\n MQTT is especially powerful because it is simple and flexible.<\/p>\n But that flexibility is also the trap.<\/p>\n You can publish almost anything, to almost anywhere, in almost any format. If nobody agrees on structure, naming, payload design, ownership, and meaning, the result is not architecture. It\u2019s just message traffic.<\/p>\n A Unified Namespace is an architectural model<\/strong> for representing the current state and events of the business in a shared, structured way.<\/p>\n In practical terms, a good UNS gives you:<\/p>\n The important point is this:<\/p>\n A UNS is not just a broker.<\/strong><\/p>\n It is the structure of the business and the operating context expressed in a way that systems can consume consistently.<\/p>\n That\u2019s why people often describe it as a single source of truth for the current state and events<\/strong>.<\/p>\n Not a database. Not a historian. Not just a network transport.<\/p>\n An architecture.<\/p>\n The confusion is understandable.<\/p>\n Many UNS implementations use MQTT as the backbone. So teams see topics flowing through a broker and assume the broker is<\/em> the Unified Namespace.<\/p>\n But the broker is only one layer.<\/p>\n If all you have is:<\/p>\n Then you do not<\/strong> have a Unified Namespace.<\/p>\n You have MQTT traffic.<\/p>\n A UNS requires more than connectivity. It requires consistency.<\/p>\n Here\u2019s the practical difference in one sentence:<\/p>\n MQTT gives you transport; a UNS gives you meaning.<\/strong><\/p>\n That difference shows up in several ways.<\/p>\n MQTT can deliver:<\/p>\n That may be technically valid.<\/p>\n But an UNS asks:<\/p>\n Without that context, downstream systems still need custom interpretation.<\/p>\n A useful UNS usually has a predictable hierarchy.<\/p>\n A common manufacturing approach is to use an ISA-95-style structure such as:<\/p>\n or:<\/p>\n That structure matters because it gives every subscriber a reliable way to locate information and understand context.<\/p>\n MQTT does not force you to do this. A UNS does.<\/p>\n MQTT doesn\u2019t care what is in the payload.<\/p>\n A UNS does.<\/p>\n If one publisher sends the temperature as:<\/p>\n and another sends:<\/p>\n That may still \u201cwork\u201d at a transport level, but it creates unnecessary integration effort.<\/p>\n A Unified Namespace needs conventions for:<\/p>\n Otherwise, every consumer becomes another custom integration.<\/p>\n You can swap broker technologies. You can bridge brokers. You can scale transport in different ways.<\/p>\n The UNS should still make sense.<\/p>\n That\u2019s how you know you\u2019re thinking architecturally rather than just wiring things together.<\/p>\n This is where the distinction becomes expensive.<\/p>\n When teams mistake MQTT for a Unified Namespace, they usually end up with one or more of these problems:<\/p>\n One useful way to structure an UNS is to align it with ISA-95 concepts.<\/p>\n You don\u2019t need a perfect standards exercise. You just need a stable backbone that matches how factories actually think.<\/p>\n ISA-95 gives you a semantic hierarchy such as:<\/p>\n That makes it easier to create a namespace that scales logically and maps better to business and operational systems.<\/p>\n It also helps bridge the gap between shop-floor data and business systems, because many enterprise systems already think in similar structural terms.<\/p>\n That\u2019s one reason ISA-95 is still useful in modern industrial data architecture: not as red tape, but as a practical organising model.<\/p>\n A lot of people also assume a Unified Namespace is the place where all historical data lives.<\/p>\n That\u2019s not quite right.<\/p>\n A UNS is usually best understood as the place where you can observe the current state<\/strong> and the stream of events.<\/p>\n Historical storage still matters, but that is usually handled by:<\/p>\n In other words:<\/p>\n That distinction is useful because it stops people from expecting the UNS to be everything.<\/p>\n This is not just a technical argument.<\/p>\n It matters because a proper Unified Namespace changes how quickly you can solve new business problems.<\/p>\n Once you have:<\/p>\n Then every new use case becomes easier.<\/p>\n Examples:<\/p>\n That\u2019s why an UNS is often a stronger foundation for digital transformation than another isolated application.<\/p>\n It shifts the model from point-to-point integration<\/strong> to a shared operational context<\/strong>.<\/p>\n Imagine a manufacturer wants to improve line visibility, downtime tracking, and quality response.<\/p>\n A basic MQTT-only approach might look like this:<\/p>\n Everything is connected, but nothing is really unified.<\/p>\n A UNS-based approach would look more like this:<\/p>\n That\u2019s a very different level of reuse and clarity.<\/p>\n In many manufacturing environments, the answer is both<\/strong>.<\/p>\nThe short version<\/h2>\n
\n
What MQTT actually is<\/h2>\n
\n
What a Unified Namespace actually is<\/h2>\n
\n
Why people confuse UNS with MQTT<\/h2>\n
\n
The practical difference<\/h2>\n
1. MQTT moves messages. UNS provides context.<\/h3>\n
\n
machine1\/temp = 83.2<\/code><\/li>\nline3\/state = running<\/code><\/li>\nalarm\/active = true<\/code><\/li>\n<\/ul>\n\n
2. MQTT can be flat. UNS should be structured.<\/h3>\n
{enterprise}\/{site}\/{area}\/{line}\/{cell}\/{station}\/{state}\/...<\/code><\/p>\n{enterprise}\/{site}\/{area}\/{line}\/{cell}\/{events}\/...<\/code><\/p>\n3. MQTT does not guarantee semantics. UNS requires them.<\/h3>\n
{ \"value\": 21.4 }<\/code><\/pre>\n{ \"tempC\": 21.4, \"quality\": \"ok\", \"ts\": \"2026-04-06T02:00:00Z\" }<\/code><\/pre>\n\n
4. MQTT is infrastructure. UNS is architecture.<\/h3>\n
What goes wrong when teams treat MQTT as the UNS<\/h2>\n
Topic sprawl
\nNo shared topic structure. Different teams publish in different styles. Nobody knows where things belong.<\/h3>\nReinvented integrations
\nConsumers still need custom logic for each data source because payloads and naming aren\u2019t standardised.<\/h3>\nNo trust in the data
\nMultiple systems publish similar values with no clear ownership. Which machine state is authoritative? Which OEE number is the right one?<\/h3>\nFlat connectivity without operational value
\nSystems are technically connected, but you still can\u2019t easily build cross-functional workflows, analytics, or AI tools on top of them.<\/h3>\nToo many direct reads from source systems
\nInstead of publishing once and reusing many times, multiple consumers poll the same PLCs, tags, or systems repeatedly. That increases complexity and load without improving architecture.<\/h3>\n<\/h2>\n
This is one of the biggest practical advantages of a proper Unified Namespace: you acquire and normalise data once, then let many consumers reuse it.<\/h2>\n
<\/h2>\n
Where ISA-95 fits in<\/h2>\n
\n
Current state vs history: another important distinction<\/h2>\n
\n
\n
Why this matters for digital transformation<\/h2>\n
\n
\n
A practical manufacturing example<\/h2>\n
\n
\n
So do you need MQTT, UNS, or both?<\/h2>\n