Azure Digital Twins Alternatives: Managed, Open-Source and MQTT-Based Options

If you are searching for an Azure Digital Twins alternative, you probably like the idea of a modeled, queryable twin graph but want more portability, a simpler stack or a deployment that does not depend on one cloud. This article compares the main families of alternatives: other managed services, open-source twin platforms, and do-it-yourself stacks built on standard MQTT. You will also see working code for a minimal twin graph fed by MQTT so you can judge the DIY route yourself.

New to the concept? The digital twin technology guide explains the fundamentals.

What Azure Digital Twins Actually Provides

Before comparing, it helps to be precise about what you would be replacing. Azure Digital Twins is a platform service for modeling environments. Its main building blocks are:

• DTDL models: JSON-LD based definitions of twin types, their properties, telemetry, components and relationships.
• A twin graph: instances of those models connected by relationships, such as a floor that contains rooms that contain sensors.
• A query language for traversing and filtering the graph.
• Event routes that send twin changes to other Azure services for downstream processing.

Notably, it is not where device data arrives. Device messages typically land in an ingestion service first, and you write glue code, often a serverless function, to update twin properties. You also bring your own storage for history, your own visualization and your own analytics. In other words, it is one layer of a twin solution, not the whole thing.

That framing matters. Most alternatives replace the modeling and graph layer, while the ingestion, history and visualization layers are needed in any architecture.

Why Teams Look for Alternatives

The motivations we hear most often are practical rather than ideological:

1. Portability. Sites run on different clouds or on premises, and the twin must work across all of them.
2. Standard protocols. Teams want devices and gateways to speak plain MQTT rather than a cloud-specific SDK.
3. Simplicity. Many projects need live state and a hierarchy, not a full graph query engine. Several managed services glued together can be heavy for that.
4. Industrial standards. Manufacturers may prefer the Asset Administration Shell or ISA-95 structures over DTDL.
5. Skills and cost predictability. Small teams prefer components they can run, inspect and reason about.

The Alternatives Compared

The open-source digital twin tools comparison goes deeper on Ditto, BaSyx and the visualization side, and the asset administration shell guide covers AAS modeling in detail.

The MQTT-Native Approach in Practice

The lightest alternative treats the MQTT topic hierarchy itself as the backbone of the twin. In a Unified Namespace, each asset publishes its state to a topic that encodes its position: site/area/line/cell/asset. The hierarchy gives you "contains" relationships for free, retained messages give you current state for free, and wildcards give you queries like "everything in line 2".

You then add only what the hierarchy cannot express: typed models, cross-links such as "pump 104 feeds tank 3", and history.

Here is a minimal twin graph service in Python. It subscribes to a namespace, builds a tree of twins from topic paths, stores the latest state of each, and supports a simple query. Run it against the public MQTT test broker with your own random prefix.

import json
import threading

import paho.mqtt.client as mqtt

ROOT = "connectmq/demo/adt-5m1"
twins = {}  # path -> {"state": {...}, "children": set()}
lock = threading.Lock()


def upsert(path, state):
    parts = path.split("/")
    with lock:
        for i in range(1, len(parts) + 1):
            node = "/".join(parts[:i])
            twins.setdefault(node, {"state": {}, "children": set()})
            if i > 1:
                twins["/".join(parts[:i - 1])]["children"].add(node)
        twins[path]["state"].update(state)


def query(prefix, predicate):
    with lock:
        return {p: t["state"] for p, t in twins.items()
                if p.startswith(prefix) and t["state"] and predicate(t["state"])}


def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{ROOT}/+/+/+/+/state", qos=1)


def on_message(client, userdata, msg):
    path = msg.topic[len(ROOT) + 1:-len("/state")]
    upsert(path, json.loads(msg.payload))


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="adt-5m1-graph")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883)
client.loop_start()

input("Publish some states, then press Enter to query...\n")
hot = query("site1/assembly", lambda s: s.get("temp_c", 0) > 70)
print(json.dumps(hot, indent=2))
print("Children of site1/assembly:", sorted(twins.get("site1/assembly", {}).get("children", [])))
client.loop_stop()

Feed it a few states:

mosquitto_pub -h broker.connectmq.com -p 1883 -i adt-5m1-a -r -q 1 \
  -t "connectmq/demo/adt-5m1/site1/assembly/line2/robot3/state" -m '{"temp_c":74,"mode":"auto"}'
mosquitto_pub -h broker.connectmq.com -p 1883 -i adt-5m1-b -r -q 1 \
  -t "connectmq/demo/adt-5m1/site1/assembly/line2/press1/state" -m '{"temp_c":51,"mode":"auto"}'

Because both messages are retained, the graph service rebuilds the current state of every twin as soon as it connects, with no separate database. That is the core of what a twin graph service does, in about forty lines. For production you would add a model registry (DTDL or JSON Schema files describing each asset type), persist history in a time-series database, and expose the query through an API.

If you already have DTDL models from an Azure project, you do not have to throw them away. DTDL is an open specification; you can keep the interface files as documentation and validation schemas, and map each model's telemetry and properties to topics. The DTDL guide shows how.

What You Give Up and What You Gain

Be honest about trade-offs before switching.

You give up a managed graph query engine, built-in model validation and integration with the rest of the Azure ecosystem. If your organization runs everything else on Azure and needs complex multi-hop graph queries over many entities, staying may be the right answer.

You gain a twin that works anywhere MQTT works, which is effectively everywhere: PLC gateways, ESP32 boards, Node-RED, Python, browsers over WebSocket. Every consumer reads the same live data. The architecture is easy to explain, and each layer, from broker to storage to 3D, can be swapped independently.

A sensible middle path is common: keep the MQTT namespace as the system of record for live state, and project it into whichever graph or AAS tool a specific application needs.

Migration Checklist

1. Inventory your DTDL models and twin instances, and note which relationships are hierarchical versus cross-links.
2. Design a topic hierarchy that mirrors the hierarchical relationships, following ISA-95 levels where possible.
3. Point gateways at an MQTT broker and publish state as retained messages, telemetry as non-retained.
4. Replace event routes with MQTT subscribers: a historian writer, an alerting service, a 3D viewer.
5. Store cross-link relationships and model metadata in a small registry service or configuration repository.
6. Run old and new paths in parallel for a few weeks and compare state before switching consumers over.

Choosing the Broker

In an MQTT-native twin, the broker is the one component everything depends on, so it should not be a hobby server under someone's desk. A managed MQTT broker gives you TLS endpoints, authentication and capacity without operating the infrastructure.

ConnectMQ supports MQTT 3.1.1 and 5.0, TCP and TLS for gateways, WebSocket and Secure WebSocket for browser twins, and detects ISA-95 and Unified Namespace topics in its portal, showing devices by hierarchy level. It does not try to be a twin platform itself; you connect your graph service, historian and viewers as ordinary MQTT clients, which keeps the architecture portable. If you need the broker inside your own cloud account, the BYOC plan runs it there, managed by ConnectMQ.

Build a Portable Twin on ConnectMQ

Start with the namespace: publish retained state for a handful of assets and connect a viewer and a graph service. Create a free ConnectMQ Serverless broker, no credit card required, and you will have a portable foundation for your twin in minutes.

Frequently Asked Questions

What is the best Azure Digital Twins alternative?

It depends on what you need. Eclipse Ditto suits device-centric twins with APIs, Eclipse BaSyx suits Asset Administration Shell projects, and an MQTT-native stack suits teams that want portable live state with minimal infrastructure.

Can I reuse my DTDL models elsewhere?

Yes. DTDL is an open specification, so the files remain useful as schemas and documentation. You can map telemetry and properties to MQTT topics and validate payloads against them.

Do I need a graph database for a digital twin?

Not always. A topic hierarchy covers containment relationships, and retained messages cover current state. Add a graph store only when you need complex queries across many cross-linked entities.

Is MQTT enough for a production twin?

MQTT handles live data distribution. A production twin also needs history storage, a model registry and visualization, which connect to the broker as MQTT clients.