HiveMQ

What is HiveMQ?

HiveMQ is an enterprise-grade MQTT broker and IoT messaging platform developed by HiveMQ GmbH, founded in Germany in 2012. It is written in Java and built specifically for large-scale, mission-critical deployments that require high availability, horizontal scalability, and fine-grained operational control.

HiveMQ supports both MQTT 3.1, 3.1.1, and MQTT 5.0 and is designed to handle millions of concurrent client connections in a single cluster. It is available in two editions: a free HiveMQ Community Edition for development and smaller deployments, and a commercial HiveMQ Enterprise Edition that adds clustering, enterprise extensions, and commercial support. A fully managed cloud service, HiveMQ Cloud, is also available for teams that prefer not to operate their own broker infrastructure.

In the RFID and industrial IoT space, HiveMQ is the broker of choice when deployments outgrow what a single Mosquitto instance can provide -- particularly in multi-site enterprise networks where readers number in the thousands and event throughput must survive broker node failures without data loss.

How it works

HiveMQ is built around a clustered, in-memory architecture. Unlike single-node brokers, a HiveMQ deployment is designed from the ground up to run as a distributed system:

• Clustered architecture: Multiple HiveMQ nodes form a cluster and share state automatically. Any client can connect to any node. If a node fails, clients reconnect to a surviving node and their sessions, subscriptions, and queued messages are already present across the cluster. There is no primary/replica distinction -- all nodes are peers.
• Linear horizontal scaling: Adding nodes to a HiveMQ cluster increases both connection capacity and message throughput proportionally. HiveMQ publishes benchmarks showing linear scaling to tens of millions of connections across a cluster of commodity servers.
• Extension system: HiveMQ exposes a Java-based Extension SDK that allows custom code to intercept and modify the broker's behavior at well-defined lifecycle points -- authentication, authorization, message transformation, publish interception, and client lifecycle events. Extensions run inside the broker process and have access to all broker APIs without requiring a separate sidecar service.
• Control Center web UI: HiveMQ Enterprise ships a browser-based management console that provides real-time cluster health metrics, connected client lists, topic subscription trees, and message tracing. Operations teams can inspect live traffic without deploying additional tooling.
• Kafka and database integrations: The HiveMQ Enterprise Extensions for Kafka, InfluxDB, MongoDB, and JDBC allow the broker to forward messages to downstream systems directly, without requiring a separate bridge service. RFID tag read events published over MQTT can be written to a Kafka topic or a time-series database with no intermediary code.
• Persistent sessions and message queuing: HiveMQ stores persistent session state and queued messages durably across cluster nodes, so a subscriber that goes offline briefly (a reader management service restarting, for example) does not miss events published during its absence.

HiveMQ in RFID and IoT

RFID deployments that span multiple sites, require guaranteed event delivery at high throughput, or integrate with enterprise data pipelines are the scenarios where HiveMQ's capabilities justify its operational cost over simpler brokers:

• Enterprise RFID event streaming: A distribution center with hundreds of dock-door portals and conveyor readers generates millions of tag read events per day. HiveMQ absorbs this throughput across a cluster, and the Kafka extension forwards events to a stream processing pipeline (Apache Flink, Kafka Streams) for real-time inventory updates without any application-layer bridge code.
• Multi-site reader networks: Retail chains and logistics operators run RFID readers at dozens or hundreds of locations. Each site's readers connect to a regional HiveMQ cluster. The cluster's shared subscription feature distributes incoming tag events across a pool of backend processors without duplicating every message to every consumer.
• High-throughput tag read pipelines: High-speed conveyor systems where a single portal reads thousands of tags per second require a broker that will not become a bottleneck. HiveMQ's in-memory routing and cluster fan-out are designed for exactly this class of sustained high-rate publish workload.
• Cloud-native deployments: The official HiveMQ Kubernetes Operator automates cluster provisioning, rolling upgrades, and configuration management on Kubernetes. RFID platform teams running on EKS, GKE, or AKS can deploy HiveMQ as a first-class Kubernetes workload with persistent storage claims and horizontal pod autoscaling.
• Custom authentication for reader fleets: The Extension SDK's authentication hook allows organizations to validate each reader's identity against an internal certificate authority or device registry at connect time, without modifying the readers themselves. Readers that fail authentication are refused connection before they can publish any events.

Key features

• Native clustering: Peer-to-peer cluster with automatic state replication. No external coordination service (ZooKeeper, etcd) required. Nodes discover each other via DNS or static configuration.
• Shared subscriptions (MQTT 5.0 and HiveMQ extension): Multiple subscribers sharing a subscription each receive a portion of the messages rather than all of them. Essential for load-balancing tag read streams across a pool of processing workers.
• Retained messages: The broker stores the last retained message per topic. RFID deployments use retained messages to publish the current state of a reader (online, offline, antenna configuration) so newly connecting subscribers receive the current status immediately without waiting for the next state change.
• Session persistence: Client sessions, subscription lists, and queued messages survive both client disconnection and broker node failures. Durable sessions ensure backend services do not lose events during rolling deployments or maintenance.
• Extension SDK: The Java-based SDK exposes hooks for authentication, authorization, publish interception, subscribe interception, and client lifecycle events. Custom extensions can validate credentials, rewrite topic names, filter by EPC prefix, or route messages to different downstream systems based on payload content.
• MQTT 5.0 full support: User properties, message expiry, reason codes, topic aliases, and request/response correlation are all supported. These features are particularly useful for attaching reader metadata (site ID, antenna port, RSSI) to tag read messages without embedding that data in the payload schema.
• Kubernetes Operator: Automates HiveMQ cluster lifecycle management on Kubernetes, including zero-downtime rolling upgrades, configuration reloads, and integration with Kubernetes-native storage and networking.

HiveMQ Cloud vs self-hosted

HiveMQ is available in two deployment models, each suited to different organizational contexts:

• HiveMQ Cloud (managed service): A fully managed MQTT broker service hosted on AWS and Azure. HiveMQ GmbH operates the infrastructure, handles upgrades, and provides SLA-backed availability. There is a free tier (up to 100 connections) and paid tiers for higher connection counts. HiveMQ Cloud is the fastest path to a production-ready clustered MQTT broker and is well suited for RFID platform teams that want to focus on application logic rather than broker operations. The tradeoff is that extensions (custom auth, Kafka integration) are not available on the managed service -- those require self-hosted Enterprise Edition.
• Self-hosted Enterprise Edition: Deployed on bare metal, virtual machines, or Kubernetes. Full access to all enterprise extensions, the Control Center, and the Extension SDK. Required for organizations that need data residency guarantees, integration with on-premises systems (Active Directory, internal CA, on-prem Kafka), or custom extension code. The Kubernetes Operator is the recommended deployment method for new self-hosted installations.
• Community Edition: Free, open-source, single-node broker. Lacks clustering, the Control Center, and enterprise extensions. Suitable for development, testing, and small-scale deployments where a single broker node is acceptable.

Advantages

• Enterprise clustering and HA: Peer-to-peer clustering with automatic failover means no single broker node failure causes an outage or message loss. This is the primary reason enterprises choose HiveMQ over standalone Mosquitto.
• Millions of concurrent connections: HiveMQ is designed and benchmarked for tens of millions of simultaneous MQTT client connections, far beyond what a single-node broker can support.
• Extension ecosystem: The Extension SDK and official enterprise extensions (Kafka, InfluxDB, MongoDB, JDBC, enterprise security) eliminate the need for custom bridge services in most integration scenarios.
• Web-based management: The Control Center provides real-time visibility into cluster health, client connections, subscription trees, and message traces without requiring additional monitoring infrastructure.
• Kubernetes Operator: First-class Kubernetes support with an official operator simplifies cluster lifecycle management for platform teams already running workloads on Kubernetes.
• Full MQTT 5.0 support: Complete implementation of the MQTT 5.0 specification, including features that directly benefit RFID deployments such as user properties for reader metadata and shared subscriptions for consumer load balancing.
• Commercial support: HiveMQ GmbH provides enterprise support contracts, which matters for production RFID infrastructure where broker downtime has direct business cost.

Limitations

• Commercial licensing cost: HiveMQ Enterprise Edition requires a commercial license. The cost is significant and is typically justified only for deployments at a scale or reliability requirement that a free broker cannot meet.
• Heavier than Mosquitto: HiveMQ requires substantially more memory and compute than Eclipse Mosquitto . A minimal HiveMQ node requires at least 2 GB of heap and a multi-core CPU. For edge deployments on resource-constrained hardware, Mosquitto remains the practical choice.
• Java runtime overhead: HiveMQ runs on the JVM. Java's memory footprint and garbage collection pauses add operational complexity compared to native broker implementations. Tuning JVM heap size and GC settings is necessary for stable high-throughput operation.
• Overkill for small deployments: A single-site RFID deployment with a handful of readers and modest throughput requirements does not benefit from HiveMQ's clustering and will pay its operational overhead for no gain. Mosquitto or EMQX are better fits at that scale.
• Extensions require Java development: The Extension SDK is Java-only. Organizations without Java engineering capability cannot easily write custom extensions and must rely on the official extensions that HiveMQ provides.
• HiveMQ Cloud lacks extension support: Custom extensions and direct Kafka/database integrations are not available on the managed cloud service. Organizations that need those capabilities must operate their own cluster.

HiveMQ vs Mosquitto vs AWS IoT Core

Common RFID deployments

• Enterprise multi-site reader networks: A national retailer runs UHF RFID portals at every store. Each store's readers connect to a regional HiveMQ cluster over TLS. The cluster's Kafka extension streams tag events to a central inventory platform. Cluster failover ensures that a node outage at a regional data center does not interrupt read collection at the stores served by that region.
• Warehouse event streaming: A fulfillment center operates hundreds of dock-door, conveyor, and handheld readers. All readers publish tag reads to a HiveMQ cluster. Shared subscriptions distribute events across a pool of inventory processing workers. The Control Center gives the operations team a live view of read rates and connected reader counts without requiring a separate monitoring stack.
• Retail chain RFID hubs: A fashion retailer uses HiveMQ as the central MQTT hub for its RFID rollout. Store-level readers publish to a shared HiveMQ Cloud cluster. A custom extension validates each store's reader against a device registry before allowing any messages to be routed. Topic-based routing separates replenishment events, loss-prevention alerts, and inventory cycle-count streams into distinct subscriber groups without any application-layer demultiplexing.
• Logistics and cold chain: A temperature-sensitive pharmaceutical distributor uses RFID tags with integrated sensors. Readers publish tag EPC and sensor readings to HiveMQ. The InfluxDB extension writes time-series sensor data directly to an on-premises InfluxDB instance for compliance reporting, while the Kafka extension simultaneously forwards events to a real-time alerting pipeline.

Related