EMQ makes machines talk. The value is in who listens.

A car is an awkward place to run a software integration. It moves. Its connection comes and goes. Meanwhile, someone wants its status, someone wants to send it a configuration update, and someone else is building the application that turns those messages into a service. The car has no interest in how elegantly these departments have arranged their responsibilities.

In 2018, SAIC Volkswagen began designing a new Internet of Vehicles platform. The communications brief involved concurrency, latency and throughput. The organizational brief was just as revealing: let the vehicle system and the business applications evolve without every change becoming a negotiation between them. EMQ’s MQTT broker, EMQX, became the intermediary.

The car does not care about your architecture

MQTT is a publish-and-subscribe messaging protocol. A device publishes to a topic; interested applications subscribe. The broker handles the distribution. Think of a temperature reading announced once and delivered to several listeners, rather than a sensor maintaining a separate conversation with every application. Commands can travel in the opposite direction.

SAIC Volkswagen used EMQX Enterprise to connect vehicles, handle authentication and route messages. Its rule engine bridged data into Kafka for asynchronous consumption. That last detail matters. MQTT handled the device-facing conversation; Kafka remained part of the downstream architecture. The platform launched in 2020. EMQ’s historical account describes hundreds of thousands of connected vehicles, with a million then anticipated for 2021.

The transferable idea is separation: applications can use a standard messaging interface instead of continually rebuilding vehicle integration. In practice, the cleverness is less theatrical than a self-driving demonstration. It is making an ordinary data exchange repeatable.

A broker before a business

EMQ dates the software project to 2013 and the company to 2017. The distinction is useful. Before there was a commercial organization, there was a broker that developers could inspect and use. Co-founder and CEO Feng Lee built the project around Erlang/OTP, a technology associated with concurrent, distributed, fault-tolerant systems.

Erlang is an apt choice for a business whose central task is keeping many conversations alive. EMQ later sponsored the Erlang Ecosystem Foundation and became an OASIS Open Foundational Sponsor, participating in the standards community around MQTT. Its expertise sits in protocols, distributed messaging and integration rather than the manufacture of the things sending messages.

In December 2020, EMQ announced nearly 150 million yuan in Series B funding, led by Hillhouse Ventures with GGV participating alongside existing investors. The company said the money would support staffing, organization, customer service and an expanded product portfolio. Infrastructure is sold as software; delivering it also requires people who answer when production becomes inconvenient.

“When we launched EMQX under Apache 2.0 in 2013, we prioritized openness and collaboration.”

Feng Lee, co-founder and CEO / May 2025

The factory floor speaks several dialects

A messaging broker cannot help equipment it cannot understand. EMQX Neuron addresses that earlier problem: connecting industrial assets through more than 70 protocols and exposing their data through interfaces including OPC UA and MQTT. It can filter, transform and aggregate readings near the equipment before forwarding them.

EMQ’s Swire Coca-Cola account supplies a tangible example. The bottler wanted to monitor production-line valves and anticipate deterioration. Its existing Kepware-based arrangement, the account says, conflicted with a containerized technology strategy and left intelligence to higher-level systems. Swire introduced Neuron for data acquisition and edge processing.

Valve status, pressure, current and timing signals became inputs to local feature extraction. Lightweight health models trained in the cloud were deployed at the edge. Structured results then flowed through EMQX Enterprise to time-series databases and operational displays. EMQ reports fewer unplanned shutdowns and a move toward predictive maintenance. The mechanism is more useful than the adjective: inspect the signals locally, then send information that a maintenance team can act on.

EMQX Edge performs a different nearby job. It brokers MQTT messages locally and bridges selected data upstream, with buffering for interrupted connections. Neuron translates equipment; Edge organizes local messaging. A factory that loses its cloud link still needs its local systems to speak.

Move the messages, keep the devices

An anonymous agricultural-technology customer in EMQ’s case studies ran into cost-predictability and scaling constraints with a public-cloud IoT service. Its migration had two paths. Updateable devices received a changed MQTT SDK. For legacy devices, the team reproduced authentication logic with HTTP authentication and access-control interfaces, then changed DNS routing.

Field gateways aggregated sensor data. EMQX’s rules routed messages into RabbitMQ exchanges, while commands could travel back to valves. The lesson is pleasantly unglamorous: inventory what devices can change, preserve the authentication behavior of those that cannot, and distinguish data collection from the business systems consuming it. A migration becomes more tractable when it stops demanding that every piece of equipment be new.

The price of keeping things talking

EMQ sells several allocations of responsibility. With self-managed Enterprise, the customer operates the infrastructure. EMQX Cloud supplies a managed service. Bring-your-own-cloud places it in the customer’s cloud account while EMQ manages the platform. The distinction affects who handles upgrades, monitoring and the next troublesome Tuesday.

Serverless charges for usage above allowances and supports up to 1,000 connections. Dedicated Flex provides an isolated cluster, with a published 99.99% uptime SLA. Starting prices are a planning input: traffic, sessions, integration needs and operational staffing determine whether a plan suits the work. A large device count alone is a poor shopping list.

Licensing changed in May 2025. From EMQX 5.9, EMQ consolidated its community and enterprise editions under Business Source License 1.1. Its explanation cited the resource cost of maintaining separate codebases and the desire to fund further development. The code remains available, but production rights have conditions. Non-production use and eligible single-node production have free allowances; hosted or embedded offerings to third parties are excluded from the single-node grant. Production clustering requires attention to commercial terms. Each version converts to Apache 2.0 after four years.

That change reveals the commercial tension inside the product. A common codebase can expose more capabilities while the company charges for uses requiring enterprise infrastructure. A team choosing EMQX should evaluate the license alongside its technical design, particularly before assuming a prototype can simply grow into a free production cluster.

A message needs somewhere to stay

EMQ’s expansion follows the data. EMQX Tables, generally available since December 2025, adds managed time-series storage inside EMQX Cloud. Its rule-engine integration, schema inference and SQL support address the next question after delivery: how does an application retrieve and analyze what happened?

January 2026 brought MQTT Streams and native Parquet output in Enterprise 6.1. April’s 6.2 added agent discovery and governance. In July, EMQ announced an integration partnership with DADOS, pairing MQTT transport with an in-memory industrial intelligence layer. These additions place EMQ closer to the systems making decisions from live telemetry.

The September 2026 Enterprise 6.3 LTS release concentrated on security defaults, optional hardening and finer operational control. That is a revealing counterweight to the AI pitch. More ambitious applications still depend on credentials, authorization and predictable behavior under load.

Start with one useful signal

EMQ competes with MQTT options including HiveMQ, Mosquitto and VerneMQ, and with managed offerings such as AWS IoT Core. Its distinctive case is the span of the suite: industrial protocol access, local messaging, distributed brokerage and downstream integration. Those capabilities matter most when a team actually needs that span.

For a small, straightforward MQTT deployment, a simpler broker may be sufficient. For a plant, confirm the exact drivers and operating requirements. For a remote site, test interrupted connections and recovery. For any deployment, measure the behavior of slow consumers and verify authentication before scaling. A broker does not make bad sensor data accurate or an AI decision sound.

MQTTX offers a practical place to begin: connect, publish a message and observe subscriptions. Then add one useful route to a real destination. EMQ’s proposition becomes easier to judge when the question is concrete: can this reading reach this application, and can the command get back? A talking machine is interesting. A message arriving where someone can use it is worth paying for.