EMQX or Kafka for IoT data: when each one fits
A team collecting device data often has to decide whether it needs an MQTT broker, an event streaming platform, or both. EMQX fits when the main problem is getting device traffic in: many devices connecting over MQTT, per-message QoS levels, MQTT 5.0 features such as session and shared subscription behavior, and a SQL-based rule engine that routes messages to downstream systems. Kafka fits when the main problem is what happens after data arrives: durable retention that lets consumers replay history, consumer groups that read at their own pace, and stream processing across many internal applications. Many teams find they need the first to accept devices and the second to keep and analyze the data, which is why the question is rarely a pure either-or.
The decision turns on four conditions. First, the device protocol: if devices speak MQTT, CoAP or LwM2M natively, EMQX covers those through its listed gateways, while Kafka expects producers to be written against its client libraries or reached through an adapter. Second, licensing for clusters: EMQX moved to the Business Source License 1.1 with version 5.9.0, and from that version a cluster of more than one node requires a license file, so a single-node production grant is not the same as a production cluster. Confirm the current terms in the EMQX license file and with the vendor before you size a fleet. Third, retention: decide how long raw device data must be kept and who replays it. Fourth, who operates the stack. Kafka brokers, KRaft metadata and Java runtime upgrades are a recurring operating task, and an MQTT cluster adds its own connection capacity and certificate work.
A common pattern is to terminate device connections in EMQX and bridge selected topics into Kafka, using EMQX's listed Kafka integration. Before committing, ask the EMQX and Kafka owners to agree on topic naming, message schema, delivery guarantees across the bridge and where the license file for each cluster is held. Test a failover in each layer, including what happens to buffered messages if the Kafka side is unavailable. Document which team owns each hop. An illustrative example: a fleet of 20,000 sensors (illustrative only) may need a clustered broker for connection load, but a single Kafka cluster for analytics, and the license and operating questions then apply to both systems separately.
Which platform fits which IoT scenario
This table maps common IoT situations to the platform that fits each one better, with the condition under which the other option would win. Read each row as a starting point: the deciding factors are usually where devices connect, how long telemetry must be kept, and who consumes it.
| Scenario | Better fit and reason | When the other option wins |
|---|---|---|
| Devices speak MQTT directly | EMQX. It accepts MQTT 5.0, 3.1.1 and 3.1 connections from devices, supports QoS, and handles authentication with username and password, JWT, PSK or X.509 certificates over TLS. | Kafka wins only if devices can be given a Kafka client or a gateway that speaks Kafka protocol. Kafka has no native MQTT device connection model. |
| Devices behind a gateway that already publishes to Kafka | Kafka. If the gateway or edge layer already writes telemetry to topics, adding EMQX adds a broker to operate without a new capability. | EMQX wins if the gateway cannot hold device sessions, retained messages or QoS guarantees and you need the broker to manage device connections directly. |
| Long-term replay of telemetry | Kafka. Its log-based design is built for durable retention and replaying past events to new consumers. Confirm retention settings and storage sizing for your volumes. | EMQX wins if replay needs are short and the data only has to reach a database or another system through its rule engine and integrations. |
| Stream processing and analytics | Kafka, paired with a stream processing layer such as Kafka Streams. Consumers read ordered partitions and process data at their own pace. | EMQX wins if the processing is simple filtering, routing or transformation in its SQL-based rule engine before data reaches storage. |
| Single-site pilot with a few hundred devices | EMQX on a single node. The Business Source License allows production use of one node, provided the service is not offered to third parties. Confirm the terms for your use. | Kafka wins if the pilot already feeds an existing Kafka estate, since adding a second messaging layer then adds effort without new capability. |
| Multi-site fleet with clustered brokers | EMQX, with a license file loaded for clusters of more than one node. Its masterless clustering suits devices spread across sites that connect to a local broker. | Kafka wins if the fleet's data is centralized in one data platform and device connectivity is handled by existing gateways outside the broker. |
| Mixed device fleet feeding a central data platform | Both, with EMQX bridged into Kafka. EMQX terminates device sessions and forwards telemetry to Kafka topics through its data integration. | A single platform is enough if all devices can reach Kafka directly and the team does not need MQTT session handling at the edge. |
How each platform is built and what that means for operations
EMQX holds device connections in a clustered broker, while Kafka keeps partitioned logs under a KRaft controller layer. Each card below names a design decision that changes sizing, failure handling, upgrades or who owns the work.
Masterless clustering in EMQX
EMQX runs as a masterless cluster, so no single node coordinates the others. Since 5.9.0, a cluster of more than one node needs a license file loaded before it starts, which makes licensing part of the scaling plan. Ask how client sessions and subscriptions behave when a node leaves the cluster, and test that behavior in your own topology before go-live.
The broker holds device connections
EMQX is connection-oriented: each device keeps an MQTT session open, and the QoS level chosen per message decides how deliveries are acknowledged. Sizing starts from concurrent connections and message rate, with disk as a secondary factor. Confirm connection limits, session persistence and TLS handshake load for your chosen edition with the vendor before you size the nodes.
KRaft-only control since Kafka 4.0
Kafka 4.0 supports only KRaft mode, so cluster metadata lives inside Kafka and ZooKeeper is no longer part of the stack. ZooKeeper-based clusters must migrate to KRaft before they move to any 4.x release, and KRaft clusters older than 3.3.x should first reach 3.9.x. Plan that migration as its own project with a tested rollback path.
Partitioned logs and Kafka Connect
Kafka brokers keep partitioned, replicated logs, so disk growth follows retention settings and partition count. Kafka Connect runs as a separate process in standalone or distributed mode, and Kafka 4.0 requires Java 17 for brokers and Connect. Decide who owns the Connect workers and their REST API before you build pipelines from device data.
Upgrade cadence and supported lines
Kafka aims for three releases a year and supports rolling upgrades from each of the last three releases to the latest. The supported lines today are 4.3.1, 4.2.2 and 4.1.2, so older lines need a move before their support ends. Test each upgrade on a staging cluster that matches production partition counts, and confirm the EMQX release line you plan to run before you commit to a version.
Security and ACL defaults
Kafka security is optional, so clusters can run unsecured or mix secured and unsecured listeners unless you enforce SSL or SASL. In KRaft clusters, ACLs sit in the metadata log, and resources without ACLs are limited to super users unless allow.everyone.if.no.acl.found is set to true. On the EMQX side, check username and password, JWT, PSK and X.509 options against your device fleet.
Capabilities that separate EMQX and Kafka
This table compares the capabilities that decide whether a device-facing broker, a streaming log or both should own each part of an IoT data path. Read each row as a question to answer for your own devices and downstream consumers, since the two systems were designed for different first jobs. The main takeaway is that EMQX covers device connections and MQTT semantics, while Kafka covers retention, replay and consumer-side processing, and many teams use both.
| Capability | EMQX | Apache Kafka |
|---|---|---|
| MQTT and device protocols | MQTT 5.0, 3.1.1 and 3.1, plus MQTT over QUIC; MQTT-SN, CoAP and LwM2M through gateways | No MQTT protocol support; devices typically reach Kafka through a bridge or a client library |
| QoS and retained messages | MQTT QoS levels and retained messages are part of the broker's native delivery model | Delivery guarantees are set by producer and consumer configuration, not MQTT QoS; confirm the mapping with your team |
| Persistent sessions | Supports MQTT persistent sessions for devices that reconnect intermittently; confirm session limits for your version | No device session concept; consumer group offsets track read position for each application |
| Authentication options | Username and password, JWT, PSK and X.509 certificates over TLS/SSL and secure WebSocket | SSL or SASL; SASL mechanisms are GSSAPI, PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER |
| Encryption and security posture | TLS/SSL and secure WebSocket connections; confirm listener settings in your deployment | SSL/TLS is optional and clusters can mix secured and unsecured listeners; enforce it in configuration |
| Authorization model | Confirm the access control options for your edition and license tier before design | In KRaft, StandardAuthorizer stores ACLs in the metadata log; resources without ACLs are limited to super users by default |
| Rule engine and integration | SQL-based rule engine with data integration to more than 50 systems, including Kafka | Kafka Connect provides source and sink connectors, run in standalone or distributed mode through a REST API |
| Retention and replay | Designed for message delivery to subscribers; confirm any message storage and replay features you need | Durable, log-based retention with replay by offset, which is the core reason to choose Kafka for downstream analytics |
What the EMQX license and Kafka license each allow
EMQX unified its former Open Source and Enterprise editions into one offering starting with version 5.9.0, and that offering is licensed under the Business Source License 1.1 rather than Apache 2.0. The license grants production use of a single node, which is the most common starting point for a device pilot or a small deployment. The grant has limits that matter for product teams: the node may not be offered to third parties on a hosted or embedded basis, so a service you sell to customers on top of EMQX falls outside the single-node grant.
- Production grant: Production use of one node is allowed under the license text, without a separate license file.
- Hosted limit: Offering EMQX to third parties on a hosted basis is not covered by the single-node grant.
- Embedded limit: Shipping EMQX inside your own product for customers is not covered by the single-node grant either.
- Scope of the grant: The grant applies to the EMQX broker as distributed in the 5.9.0 line and later under this license.
- Version boundary: Releases before 5.9.0 were under Apache 2.0, so the terms for older versions differ from the current offering.
If your architecture places EMQX in your own cloud accounts for your own devices, the single-node grant may cover you, but a device-as-a-service model or an OEM build may not. Have counsel read the LICENSE file against your exact delivery model before you commit.
The single-node grant does not carry over to multi-node designs. From EMQX 5.9.0, deploying a cluster of more than one node requires loading a license file. For most industrial and fleet deployments, clustering is the reason EMQX is chosen, since it provides the connection capacity and availability that a single broker cannot. The license file is therefore a line item in the design, not an optional extra.
- Trigger: Any deployment with more than one EMQX node in a cluster needs a license file loaded.
- Design impact: High availability and horizontal connection scale both fall under the clustering requirement.
- Procurement: Ask EMQX how license files are issued, renewed and tied to node counts before sizing a cluster.
- Alternative path: Some teams keep a single node per site and bridge data upward, which avoids clustering at each site but changes the failure model.
- Documentation: The README describes the requirement; confirm the current terms in the repository and with the vendor.
Before you design a multi-node EMQX cluster, confirm with EMQX which license file applies to your node count and what happens at renewal.
The EMQX license includes a grant for educational and non-profit users. Under the license text, those users may use the software in production without restriction when the use is non-commercial. This matters for universities, research labs and charities running environmental or health sensor networks where budgets and purposes are not commercial. The grant depends on the purpose and the organization type, so it is not a general free tier.
- Who qualifies: Educational and non-profit users are named in the license text as eligible.
- Condition: The use must be non-commercial for the grant to apply.
- Unrestricted production: Within the grant, production use is not limited by the single-node rule stated in the license.
- Mixed use: A university spin-off or a non-profit that sells services may fall outside the grant.
- Verification: Confirm the eligibility criteria against the LICENSE file and with counsel.
If your organization is an educational or non-profit body with a clear non-commercial purpose, read the grant terms closely before assuming it covers clustered production use.
Each EMQX release under the Business Source License converts to Apache 2.0 four years after it is published. This is a per-release clock, not a single date for the whole product. A release that you run in production today will become Apache 2.0 four years after its publication date, while newer releases remain under the Business Source License until their own conversion dates. Planning teams should track the publication date of each version they deploy.
- Per-release clock: Each release has its own conversion date, four years after it is published.
- Current releases: Newer lines, such as 6.3.2 published on October 16, 2026, stay under the Business Source License until their own conversion.
- Version pinning: Staying on an older release does not change its terms, but security fixes and features follow the newer lines.
- Upgrade risk: A long-lived pinned version may gain no fixes, which is an operational trade-off to weigh.
- Records: Keep a record of the release and publication dates in your change management system.
Before you choose a version for a long-lived product line, check the publication date of that release and confirm with EMQX how security fixes are handled for older lines.
Apache Kafka is an Apache Software Foundation project released under the Apache License 2.0, identified as Apache-2.0. The project itself does not sell a paid edition, so the license applies to the software you download and run. Unlike a dual-licensed or source-available product, there is no separate commercial tier from the project that unlocks clustering, connectors or features. The license terms are permissive for production use, including hosted and embedded use, subject to the Apache-2.0 notice requirements.
- License: Apache-2.0 covers the Kafka project distribution.
- No paid edition: The project does not offer a commercial edition from Apache.
- Hosted and embedded use: Apache-2.0 does not restrict running Kafka for third parties in the way the EMQX single-node grant does.
- Releases: The supported releases are 4.3.1, 4.2.2 and 4.1.2, with earlier versions archived.
- Notices: Apache-2.0 requires retaining license and notice files in redistributions.
Before you depend on Kafka for a product offering, have counsel confirm the Apache-2.0 obligations for your distribution model and check the supported release list.
The Apache Kafka project provides open-source software, and commercial support comes from vendors and service providers that are separate from the project. This means that if you want a contractual support agreement, indemnity, or a managed service, you buy it from a company, not from the Apache project. Those commercial terms are set by each vendor and are not part of the Apache-2.0 license. Your total cost depends on who you contract with and what they cover.
- Who is paid: Vendors and service providers charge for support, managed services or enterprise distributions.
- One-time versus recurring: Implementation work is usually one-time, while support and subscriptions recur.
- Cost drivers: Cluster size, number of environments, support hours and the scope of managed operations drive price.
- Quote request: Ask each provider for the scope of support, response commitments, and what is excluded.
- Own operations: Running Kafka yourself keeps the license cost at zero but moves operating effort onto your team.
Before you sign a support contract, confirm the vendor's terms in writing, because the Apache-2.0 license does not promise any support level.
Why teams bridge EMQX into Kafka and where that breaks
The common pattern keeps each system doing what it does best: EMQX terminates device connections, manages MQTT sessions and QoS levels, and forwards selected messages to Kafka, which stores them durably and feeds stream processing and downstream consumers. EMQX lists data integration with more than 50 systems, including Kafka, in its README, so the bridge is a supported path, but the design decisions behind it are yours. Before building it, decide which device topics map to which Kafka topics, how many partitions each needs, and whether the device identifier or the topic path drives partitioning, because that choice determines what ordering guarantees you can later claim.
The bridge has to handle five problems. Duplicate delivery under QoS 1 is the first: MQTT QoS 1 guarantees at-least-once delivery to the broker side, so a retransmitted message can reach Kafka twice, and consumers or a deduplication key such as device ID plus a device-generated sequence number must absorb it. Ordering is the second: Kafka guarantees order only within a partition, and messages from one device that span reconnects or multiple bridge workers can arrive out of sequence, so confirm how EMQX rule actions and Kafka producer settings preserve order for your topics. Topic mapping, schema decisions and back-pressure complete the list. Confirm the schema registry or serialization format (JSON, Avro or Protobuf) with your consumers before the first device ships, and test how the bridge behaves when Kafka slows or a broker is unavailable, including whether EMQX buffers or drops messages in that window.
What drives running cost for each stack
This table sets out the cost drivers for running EMQX at the device edge and Apache Kafka for retention and stream processing, and shows who is paid for each item. Read it as a checklist for a quote: confirm which items are one-time and which recur, and ask for each to be priced against your own device count and retention target.
| Cost driver | EMQX (device connections) | Apache Kafka (durable retention) |
|---|---|---|
| Licensing for production | Single node is covered by the Business Source License production grant if not offered to third parties. A cluster of more than one node needs a license file from 5.9.0 onward, so confirm the license terms and any fee with the vendor. | Apache-2.0 with no paid edition from the project. Costs come from the infrastructure, staff and any commercial distribution or support you choose. |
| Infrastructure footprint | Sized by concurrent connections, message rate and rule engine load. Clusters need several nodes for redundancy, so ask for the node count your device fleet requires. | Sized by broker count, partitions, replication factor and disk. Kafka Connect runs as separate worker processes, which adds compute even before any connector runs. |
| Storage for retention | Retention is usually short, with data forwarded to downstream systems. Long history is normally held outside the broker, so storage cost depends on the target system you choose. | Retention drives disk cost on every broker and replica. Ask how long topics must hold data and how replication factor affects total storage. |
| Java runtime requirement | Not a Java-based dependency for operators to plan around in this comparison, so confirm the runtime and patching model in the vendor documentation for your release. | Brokers, Kafka Connect and tools require Java 17 since Kafka 4.0, so JVM patching and runtime upgrades become part of the recurring operations work. |
| Skills to operate | Operating MQTT listeners, authentication (username and password, JWT, PSK, X.509), and rule and bridge configuration. Plan for training on the rule engine and TLS certificate lifecycle. | Operating KRaft controllers and brokers, ACLs in the metadata log, SASL or SSL configuration, and Connect connector lifecycle through its REST API. These skills recur as staff change. |
| Support options | Ask the vendor which support tiers and response commitments apply to your license type, and whether they cover cluster licenses. Confirm in writing. | Support comes from a commercial distributor or a managed provider if you choose one. The Apache project itself provides community support, so ask who answers production incidents. |
| Upgrade effort | Plan upgrades per release line, including the license file for each cluster. Ask which releases carry the longest support window for your deployment. | Supported releases are 4.3.1, 4.2.2 and 4.1.2. Rolling upgrades are supported from the last three releases. ZooKeeper clusters must migrate to KRaft before 4.x, which is a one-time project if you still run ZooKeeper. |
| One-time versus recurring | One-time: architecture, rule design and initial cluster build. Recurring: license renewal where it applies, infrastructure, monitoring and upgrades. | One-time: cluster design, KRaft migration if needed and connector build-out. Recurring: broker and disk capacity, Java and Kafka upgrades, and connector maintenance. |
Moving an IoT pipeline between EMQX and Kafka
This sequence shows how to add Kafka behind an existing EMQX deployment or replace a Kafka-only ingestion path with an MQTT broker, with each step closing on a check that proves the data still arrives intact. It is written for teams that already know which system owns device sessions and which owns long-term retention.
Inventory topics, schemas and consumers first
Before changing anything, the platform team lists every MQTT topic pattern devices publish to, every payload schema in use, and every downstream consumer that reads from Kafka topics or from device-facing paths. The security engineer and the data owners sign off on this inventory. It is done when each device class maps to one owner, one schema version and one destination, and any consumer that depends on Kafka consumer offsets is flagged for separate handling, since offsets belong to the Kafka consumer group and do not move with the devices.
Confirm the EMQX license covers the cluster
Because EMQX 5.9.0 and later need a license file to run a cluster of more than one node, the team confirms with the vendor and against the license terms which deployment shape it runs, whether the platform is single-node or clustered, and whether the intended hosting model is permitted. The output is a written confirmation that the license covers the planned node count before any bridge or rule is built. Ask the vendor what changes if the cluster grows later.
Stand up Kafka with security and ACLs
The platform team deploys the Kafka cluster in KRaft mode, since Kafka 4.0 supports only KRaft, and enables SSL or SASL for clients, brokers and tools. They define ACLs in the StandardAuthorizer for the topics and consumer groups that will receive device data, because resources without ACLs are limited to super users unless allow.everyone.if.no.acl.found is set. The check is a test producer and consumer that succeed under the intended principal and fail under an unrelated one.
Create the bridge and rules in a test environment
In a non-production environment, the team builds the EMQX rule engine SQL that selects the device messages to forward and the Kafka data integration that writes them to topics. Platform engineering owns the rules, and the data team checks the message keys and partitioning so related device events land in the same partition. The step is complete when test devices publish, the expected records appear in Kafka, and malformed payloads are routed to a documented error path rather than silently dropped.
Rebuild device credentials and broker access
Device identities are reissued or re-registered against EMQX using the authentication methods the team has chosen, such as username and password, JWT, PSK or X.509 certificates over TLS or secure WebSocket. Certificates and secrets are generated and stored under the client's own key management process, and each device class is tested for connection, publish rights and subscribe rights. The output is a device registry that matches the inventory and a report of devices that failed to reconnect.
Run both paths in parallel and reconcile
The existing Kafka ingestion path and the new EMQX path run side by side for a period the team sets in its own change plan, and devices are moved in batches. A reconciliation job compares record counts, timestamps and schema validation results between the two paths for each device class. Dual running ends for a class only when the reconciliation shows no unexplained gaps, and each gap has a written cause and fix.
Cut over consumers and retire the old path
Once each device class reconciles, the team switches consumers to the Kafka topics fed by EMQX, starting with the least critical consumer. Consumer offsets for new topics start from the cutover point, and any backfill of historical data is handled as a separate, documented job. The old ingestion path is disabled only after rollback steps are tested, and the change record names the owner who accepted the final reconciliation.
Document the final state and keep the rollback plan
The team records the final topology, topic and ACL map, credential inventory, license scope and rollback procedure in the client's own documentation set. DeployOpen can prepare this evidence for an assessment, but independent auditors decide what it proves. The step closes when a second engineer can follow the document to rebuild the bridge and when the rollback procedure has been rehearsed.
What implementing each platform involves and where projects run long
Implementing EMQX for device data starts with the device authentication model. EMQX supports username and password, JWT, PSK and X.509 certificates over TLS/SSL and secure WebSocket connections, so the team must decide per device fleet which method applies and who issues and rotates the credentials. Rule and integration design comes next: the SQL-based rule engine decides which messages reach Kafka, and the bridge configuration decides topic mapping and payload shape. Cluster setup carries a licensing step. From EMQX 5.9.0, a cluster of more than one node requires a license file, so confirm the license terms against the Business Source License before the cluster is sized, and plan the license as a standing item rather than a one-off purchase.
Implementing Kafka means designing a KRaft cluster, since Kafka 4.0 supports only KRaft mode. Security configuration is a separate workstream: SSL or SASL listeners must be chosen (GSSAPI, PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 or OAUTHBEARER), ACLs must be written for every producer and consumer, and remember that with the StandardAuthorizer, resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set. Topic naming, partition counts and retention settings follow from the consumers that will read the data. Kafka Connect needs its own deployment decision, standalone or distributed, along with connector credentials and the REST API that manages them.
Projects usually overrun in three places. The first is device identity onboarding, where bulk enrollment of certificates or tokens across thousands of devices takes longer than the broker work itself. The second is schema agreement with data consumers: if payload formats and topic contracts are not fixed before the bridge is built, every change lands on both the rule engine and the Kafka consumers. The third is security hardening, where TLS on both the MQTT and Kafka sides, ACL coverage and secret handling are added late and retested. Confirm with the vendors and your own environment which of these items each quote includes, and ask for the scope of testing before work starts.
Questions teams ask before choosing EMQX or Kafka
Can EMQX alone replace Kafka for IoT data?
Usually not on its own, because the two systems solve different problems. EMQX handles device connections, MQTT sessions, QoS levels and routing at the edge of the network, while Kafka is built for durable retention, replay and stream processing across many consumers. A single EMQX deployment can store and forward some messages and feed systems through its rule engine, but if your teams need long retention, replay by many independent consumers or Kafka-based stream processing, you will still need a log. Confirm the retention, replay and throughput numbers you need with both vendors against your own workload before deciding that one system is enough.
When does an EMQX cluster need a license file?
From EMQX 5.9.0, deploying a cluster of more than one node requires loading a license file. The Business Source License 1.1 otherwise allows production use of a single node, provided the broker is not offered to third parties on a hosted or embedded basis. Educational and non-profit users also get unrestricted production use for non-commercial purposes. Each release converts to Apache 2.0 four years after publication. Before you size a multi-node design, ask EMQX how the license file is issued and renewed, and have your legal team review whether your product or service model falls under the hosted or embedded restriction.
How much effort does the EMQX to Kafka bridge take?
The effort depends on the number of topics, the message schema and the delivery guarantees you need. EMQX documents data integration with more than 50 systems, including Kafka, so the bridge is typically configured through its rule engine rather than written as custom code. The work that remains is mapping MQTT topics to Kafka topics, deciding on partition keys, handling payload formats, and testing what happens when Kafka is unavailable and messages must be buffered. Ask for a written list of those mapping and failure-handling tasks in any scope, because those, not the connector setup, usually drive the hours.
Can a team run Apache Kafka without outside help?
A team with Linux, networking and distributed systems experience can run Kafka in-house, and the project is Apache-2.0 licensed with no paid edition from the project itself. Kafka 4.0 supports only KRaft mode, so ZooKeeper-based clusters must migrate before upgrading to 4.x, and the Kafka upgrade notes recommend moving KRaft clusters older than 3.3.x to 3.9.x first. Supported releases today are 4.3.1, 4.2.2 and 4.1.2. Security is optional and must be configured through SSL or SASL and ACLs. If those skills or on-call coverage are missing, an implementation partner such as DeployOpen can plan, implement, harden, back up and document the platform in your own infrastructure under a fixed-scope agreement.
What skills and staff time does a Kafka plus EMQX platform need?
Plan for three skill areas: MQTT and device connectivity on the EMQX side, Kafka broker, topic and consumer operations, and security administration across both. Kafka needs Java 17 for brokers and Kafka Connect since 4.0, so your platform team must maintain that runtime. Security work includes TLS certificates, SASL mechanisms such as SCRAM-SHA-256 or OAUTHBEARER, and KRaft authorization through ACLs, where resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true. Recurring staff time covers upgrades, monitoring, capacity and on-call. Ask each vendor and any partner to describe the monthly operating tasks in writing.
How long does a migration from a direct MQTT pipeline to EMQX and Kafka usually take?
No supplied fact gives a migration duration, so treat any number you hear as unverified until it is tied to a written scope. The timeline depends on the number of device types and firmware versions, how many existing consumers must move, whether you can run old and new paths in parallel, and how much history must be replayed. Staged rollouts that keep the legacy path live until consumers are verified usually take longer than a cutover but carry less risk. Ask for milestones, acceptance tests and the dependencies on your device fleet and change windows before accepting a date.
Do the current Kafka and EMQX versions affect the plan?
Yes, because version choice sets the upgrade path and the license terms. EMQX 6.3.2 was published on October 16, 2026, and the Business Source License applies to the EMQX release you deploy. Kafka's supported releases are 4.3.1, 4.2.2 and 4.1.2, and rolling upgrades are supported from each release in the past year to the latest version. Pin tested versions for both systems, confirm the bridge connector works with the version you choose, and record the upgrade window for each in your change plan.
How DeployOpen helps choose, build and run the IoT data path
DeployOpen starts by agreeing in writing which device connections, delivery guarantees and retention needs sit with EMQX and which sit with Kafka. We then plan, implement and document the bridge and the surrounding controls inside your own infrastructure.
How we scope
- Map device types, connection counts, QoS needs and MQTT features your fleet actually requires.
- Define retention, replay and stream processing requirements that decide whether Kafka is needed.
- Confirm licensing for EMQX clusters, including the license file needed beyond one node.
- Agree deliverables, timelines and responsibilities in a fixed-scope written statement of work.
How we build
- Deploy EMQX and Kafka in your cloud accounts, data centers or air-gapped networks as scoped.
- Configure the EMQX rule engine and Kafka connection, topics, authentication and TLS settings.
- Test device authentication, message ordering, failover and throughput against the agreed scope.
- Harden listeners, access controls and Kafka ACLs, then record the configuration as code where possible.
How we hand over
- Document the architecture, data flows, topic naming, credentials ownership and failure runbooks.
- Provide operator training for your platform, security and IoT teams on daily checks and upgrades.
- Deliver backup and restore procedures for EMQX and Kafka data, tested before handover.
- Record upgrade paths, including the Kafka KRaft requirement and EMQX license terms, for your planning.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Plan version upgrades against the release and support windows your chosen versions publish.
- Re-test the device path after changes to firmware, topics, certificates or broker configuration.
- Confirm with your auditors which evidence your compliance assessment needs, since DeployOpen prepares it but does not certify it.
