EMQX: the MQTT broker that moved to BSL 1.1

What EMQX is for, and who ends up running it

EMQX is an MQTT broker written in Erlang. The README describes it as a platform for connecting devices, routing messages in real time and integrating with backend systems, aimed at AI, IoT, Industrial IoT, connected vehicles and smart cities. The protocol surface is wider than MQTT alone: the README lists MQTT 5.0, 3.1.1 and 3.1, MQTT over QUIC, and gateways for LwM2M, CoAP and MQTT-SN. That gateway list is the practical dividing line. If your fleet speaks only MQTT, the gateways are unused weight. If part of the fleet speaks CoAP or LwM2M, running one broker instead of a broker plus protocol adapters removes a hop and a second set of credentials. The repository topics repeat the same audience: aiot, iiot, lorawan, lwm2m, m2m, manufacturing, connected vehicles. This is infrastructure for teams with a device fleet and a backend to feed, not a library you embed in an application.

How the broker, the rule engine and the message queue fit together

The pieces described in the README form a pipeline. Clients connect over MQTT or a gateway protocol; the broker holds sessions and subscriptions; the SQL-based Rule Engine processes, transforms, enriches and filters data in flight; bridges then forward that data to external systems. The README names Kafka, RabbitMQ, Pulsar and RocketMQ for message queues, PostgreSQL, MySQL, MongoDB, Redis, ClickHouse and InfluxDB for databases, and AWS Kinesis, GCP Pub/Sub, Azure Event Hub and Confluent Cloud for cloud services, plus webhooks for anything else. Message Queue is a separate construct: it extends MQTT with durable storage, configurable queue lifecycle, TTL and size limits, load-balanced consumption and optional last-value semantics that keep only the newest message per topic. That last option is a real design decision. Last-value semantics discard history on purpose, which suits device state and is wrong for anything you need to replay. Flow Designer is a drag-and-drop canvas over the same rules and integrations, and the README places Schema Registry, Schema Validation and Message Transformation under Smart Data Hub, which it links to the cloud documentation rather than the self-hosted docs. Read that distinction before assuming schema validation is a local feature. Clustering is masterless, according to the README, and Cluster Linking is offered for connecting clusters across regions.

Installing EMQX: what the repository actually gives you

The README does not carry install steps. The repository is a build tree: apps/, bin/, rel/, plugins/, a Makefile, an env.sh, a mix.exs and a mix wrapper. The Makefile sets PROFILE to emqx-enterprise by default and lists REL_PROFILES as only emqx-enterprise, with PKG_PROFILES as emqx-enterprise-pkg. The build also pulls a dashboard artefact, pinned by EMQX_DASHBOARD_VERSION, currently 2.3.1. So building from source means a rebar3 and Elixir toolchain, not a single compiler invocation. The Makefile's own targets show the sequence:

make ensure-rebar3
make elixir-common-deps
make mix-deps-get

Those targets prepare rebar3 and the Elixir dependencies that the build needs. The default goal is the PROFILE target, and `make all` builds every profile in PROFILES. For a first real use, the documented entry points are the download page linked from the project's site and the Docker image that the related searches refer to as `emqx emqx docker`; the README itself does not print a docker run line, so take the tag and command from the official image page rather than from this article. Once a node is up, the README points at the dashboard as the place where rules, bridges and gateways are configured, and the docs site carries the per-feature pages linked throughout the README. If you only want to evaluate the broker, the release artefacts and the container image avoid the Erlang build entirely.

The BSL 1.1 change is the constraint that matters most

Starting from v5.9.0, EMQX unified the former Open Source and Enterprise editions into one offering under the Business Source License 1.1, and the README links a blog post explaining the change. The repository's LICENSE file is the authoritative text; GitHub reports the licence as NOASSERTION because BSL 1.1 is not a recognised SPDX identifier in that field. Two consequences follow. First, the older split, where an open source edition and a commercial edition had different feature sets, no longer describes the project: there is one codebase and one licence. Second, the related searches still include phrases like EMQX Community Edition and EMQX open source, which reflect the pre-5.9 layout rather than the current one. The README does not state the change date of BSL 1.1 or what happens to versions released under the earlier licence, so if your use depends on the previous terms, verify it against the LICENSE file and the blog post rather than assuming. I am not giving legal advice here; the point is that licence review belongs before the proof of concept, not after it.

Scale claims, release lines and what the README leaves open

The README claims 100M+ concurrent MQTT clients in a single cluster and millions of messages per second with sub-millisecond latency. Those are vendor figures with no stated hardware, message size or QoS, so treat them as a ceiling to test against your own workload, not a planning number. The release list shows two lines running in parallel: 6.3.1 and 6.3.0 labelled EMQX Enterprise (LTS), and e5.10.5 labelled EMQX Enterprise 5.10.5. The naming is inconsistent with the unified-edition story in the README, and the README does not explain which line a new deployment should start on or how long the 5.x line stays supported. That is a gap worth resolving with the project before you pin a version. The last push to the repository was on 2026-09-20, so the codebase is under current development. The README also does not document rollback or downgrade between releases, and it does not describe upgrade procedures; those live in the docs site if they exist at all. Any production plan should include a tested upgrade path between the release line you choose and its successor.

When EMQX is the wrong broker

EMQX is the wrong tool when you need a permissively licensed broker and cannot accept BSL 1.1. It is also the wrong tool when the rule engine and the integration catalogue are the reason you are looking at it, but you plan to run on the cloud: the README links Schema Registry, Schema Validation and Message Transformation to the cloud documentation, so those specific features are not presented as self-hosted ones. A third case is operational weight. The build depends on rebar3, Elixir and a pinned dashboard artefact, and the deployment surface includes gateways, bridges, message queues and clustering. If you have a few thousand devices and one backend, that surface is cost without benefit; a smaller broker with a plain publish/subscribe model will be easier to reason about. Finally, if your protocol is not on the list, EMQX does not help you: MQTT, MQTT-SN, CoAP, LwM2M and MQTT over QUIC are what the README covers.

A real alternative: Mosquitto and the difference in approach

The most direct comparison is Eclipse Mosquitto, the small MQTT broker that ships as a single daemon with a configuration file and no rule engine. The difference is architectural, not just size. Mosquitto brokers messages; anything you want to transform, filter or forward is your code, subscribing to topics and writing to your own database or queue. EMQX puts that processing inside the broker as SQL rules and bridges, so a message can arrive on an MQTT topic and land in Kafka or PostgreSQL without an intermediate service to run and monitor. The trade is that you now operate a larger system with its own configuration model, and the licence is BSL 1.1 rather than the EPL used by Mosquitto. Choose Mosquitto when the pipeline is simple and you would rather write the consumer yourself; choose EMQX when the transformation and fan-out are the work, and when CoAP or LwM2M devices have to reach the same broker as MQTT devices.

Editorial conclusion

Adopt EMQX when you need MQTT 5.0 plus gateway protocols such as CoAP or LwM2M in one Erlang cluster, and when BSL 1.1 is acceptable for how you plan to offer the service. Do not adopt it if you need an OSI-approved licence, or if a single-node broker with no rule engine is enough for your device count. Before committing, read LICENSE and the licence section of the README, check what your intended production use is under BSL 1.1, and confirm the release line you want, since the recent releases are 6.3.1 and e5.10.5.

Frequently asked questions

Official sources

1. emqx/emqx on GitHub
2. Issues
3. Project website
4. README
5. Releases