VerneMQ — A scalable alternative to Mosquitto for MQTT Messages

As real-time communication continues to grow in importance—especially for IoT ecosystems, mobile applications, and connected devices—selecting the right MQTT broker becomes crucial. Many developers begin with Mosquitto, a lightweight and widely used open-source MQTT broker. However, as systems scale, Mosquitto often reveals performance and architectural limitations.

In our Medium feature on real-time push notification experiments, we shared how Mosquitto supported our early-stage architecture. But once we crossed 15,000+ daily active publishers, we began facing significant bottlenecks. This led us to search for a more scalable and robust MQTT broker.

After extensive evaluation and industry conversations, we migrated to VerneMQ, an open-source distributed MQTT broker built in Erlang. This article outlines why we made the switch, what challenges we solved, and key configuration tips for teams planning to scale MQTT-based communication.

Why Mosquitto Failed to Scale for Our Use Case

While Mosquitto is an excellent starting point, our growth exposed several architectural and performance-related limitations.

1. No Native Horizontal Scaling

Mosquitto doesn’t support true clustering or horizontal scaling out of the box. While some community workarounds exist, they are generally unreliable for production-grade deployments at scale.

2. Single-Threaded Performance Limit

Mosquitto operates as a single-threaded application. As a result, it cannot fully leverage multi-core CPUs, ultimately capping the number of concurrent publishers it can handle efficiently.

3. High Downtime During Restarts

During testing and real-world deployments, Mosquitto took 6–7 minutes to restart, leading to unacceptable downtime and message drops.

These limitations pushed us to explore alternatives such as HiveMQ and other enterprise MQTT broker solutions.‍

Why We Chose VerneMQ Over Other Alternatives

During The Fifth Elephant conference, we discovered VerneMQ—which immediately stood out due to its distributed architecture, enterprise-grade performance, and open-source licensing.

Below are the key reasons VerneMQ emerged as our preferred choice.

1. Clustering Support for Horizontal Scaling

VerneMQ supports clustering natively, enabling horizontal scaling across multiple nodes.

Key benefits include:

• Subscribers can connect to any node.
• Messages published to one node are accessible across the cluster.
• Supports high concurrency across publishers and subscribers.

2. Strong Community, Documentation & Easy Deployment

VerneMQ offers:

• Active GitHub community
• Detailed documentation
• Pre-built Docker images
• Easy integration with monitoring stacks (Prometheus, Node Exporter, Grafana)

It also boasts high-profile users such as Microsoft and Volkswagen, adding credibility.

3. Multithreaded Architecture via Erlang

Thanks to Erlang’s lightweight processes and concurrency model, VerneMQ efficiently utilizes system resources. This allows it to handle large-scale message throughput with significantly lower latency compared to Mosquitto.

4. Immediate Improvement in Message Delivery

After shifting to VerneMQ, our drop message rate reduced from 14% to 5%, even with a volume of 10 million messages per day.

Clustering further improved throughput and balanced workload distribution.

Key Configuration Tips for VerneMQ Optimization

1. Adjusting the max_online_messages Parameter

By default, VerneMQ drops messages in bulk when the queue exceeds 1,000 messages.

We increased this value to 40,000 to support our use case.

You can also set:

max_online_messages = -1  

This removes all limits but requires more RAM—so tune cautiously.

2. Managing Persistent Client Connections

In a cluster, subscribers tend to latch onto the first available node and stay connected unless forced to switch, causing uneven load distribution.

To balance the load across nodes, we configured Persistent Client Expiration, which encourages subscriber redistribution.

3. Configuring Shared Subscriptions

For use cases where multiple subscriber instances must consume messages in a load-balanced fashion, enable:

shared_subscription_policy

This ensures each message is delivered to one subscriber among a group—ideal for microservices consuming MQTT messages.

Conclusion

Migrating from Mosquitto to VerneMQ significantly enhanced our message reliability, throughput, and scalability. VerneMQ’s native clustering, robust Erlang-based architecture, and community support make it one of the most powerful open-source alternatives to Mosquitto.

If your MQTT infrastructure is growing and you need reliable high-volume, low-latency message delivery, VerneMQ is worth strong consideration.