Alternatives to Mosquitto logo

Alternatives to Mosquitto

ActiveMQ, Mosca, EMQX, VerneMQ, and RabbitMQ are the most popular alternatives and competitors to Mosquitto.
139
306
+ 1
14

What is Mosquitto and what are its top alternatives?

It is lightweight and is suitable for use on all devices from low power single board computers to full servers.. The MQTT protocol provides a lightweight method of carrying out messaging using a publish/subscribe model. This makes it suitable for Internet of Things messaging such as with low power sensors or mobile devices such as phones, embedded computers or microcontrollers.
Mosquitto is a tool in the Message Queue category of a tech stack.
Mosquitto is an open source tool with GitHub stars and GitHub forks. Here’s a link to Mosquitto's open source repository on GitHub

Top Alternatives to Mosquitto

  • ActiveMQ
    ActiveMQ

    Apache ActiveMQ is fast, supports many Cross Language Clients and Protocols, comes with easy to use Enterprise Integration Patterns and many advanced features while fully supporting JMS 1.1 and J2EE 1.4. Apache ActiveMQ is released under the Apache 2.0 License. ...

  • Mosca
    Mosca

    A Node.js MQTT broker, which can be used as a Standalone Service or embedded in another Node.js application. ...

  • EMQX
    EMQX

    EMQX is a cloud-native, MQTT-based, IoT messaging platform designed for high reliability and massive scale. Licensed under the Apache Version 2.0, EMQX is 100% compliant with MQTT 5.0 and 3.x standard protocol specifications. ...

  • VerneMQ
    VerneMQ

    VerneMQ is a distributed MQTT message broker, implemented in Erlang/OTP. It's open source, and Apache 2 licensed. VerneMQ implements the MQTT 3.1, 3.1.1 and 5.0 specifications. ...

  • RabbitMQ
    RabbitMQ

    RabbitMQ gives your applications a common platform to send and receive messages, and your messages a safe place to live until received. ...

  • Kafka
    Kafka

    Kafka is a distributed, partitioned, replicated commit log service. It provides the functionality of a messaging system, but with a unique design. ...

  • MySQL
    MySQL

    The MySQL software delivers a very fast, multi-threaded, multi-user, and robust SQL (Structured Query Language) database server. MySQL Server is intended for mission-critical, heavy-load production systems as well as for embedding into mass-deployed software. ...

  • PostgreSQL
    PostgreSQL

    PostgreSQL is an advanced object-relational database management system that supports an extended subset of the SQL standard, including transactions, foreign keys, subqueries, triggers, user-defined types and functions. ...

Mosquitto alternatives & related posts

ActiveMQ logo

ActiveMQ

611
77
A message broker written in Java together with a full JMS client
611
77
PROS OF ACTIVEMQ
  • 18
    Easy to use
  • 14
    Open source
  • 13
    Efficient
  • 10
    JMS compliant
  • 6
    High Availability
  • 5
    Scalable
  • 3
    Distributed Network of brokers
  • 3
    Persistence
  • 3
    Support XA (distributed transactions)
  • 1
    Docker delievery
  • 1
    Highly configurable
  • 0
    RabbitMQ
CONS OF ACTIVEMQ
  • 1
    ONLY Vertically Scalable
  • 1
    Support
  • 1
    Low resilience to exceptions and interruptions
  • 1
    Difficult to scale

related ActiveMQ posts

I want to choose Message Queue with the following features - Highly Available, Distributed, Scalable, Monitoring. I have RabbitMQ, ActiveMQ, Kafka and Apache RocketMQ in mind. But I am confused which one to choose.

See more
Naushad Warsi
software developer at klingelnberg · | 1 upvote · 787.3K views
Shared insights
on
ActiveMQActiveMQRabbitMQRabbitMQ

I use ActiveMQ because RabbitMQ have stopped giving the support for AMQP 1.0 or above version and the earlier version of AMQP doesn't give the functionality to support OAuth.

If OAuth is not required and we can go with AMQP 0.9 then i still recommend rabbitMq.

See more
Mosca logo

Mosca

16
0
A Node.js MQTT broker
16
0
PROS OF MOSCA
    Be the first to leave a pro
    CONS OF MOSCA
      Be the first to leave a con

      related Mosca posts

      EMQX logo

      EMQX

      32
      6
      The most scalable open-source MQTT broker for IoT, IIoT, and connected vehicles
      32
      6
      PROS OF EMQX
      • 3
        QoS 2
      • 2
        Clusters
      • 1
        Plugins
      CONS OF EMQX
        Be the first to leave a con

        related EMQX posts

        VerneMQ logo

        VerneMQ

        31
        6
        VerneMQ is a distributed IoT/MQTT message broker.
        31
        6
        PROS OF VERNEMQ
        • 1
          Fully open source clustering
        • 1
          Proxy Protocol support
        • 1
          Open Source Plugin System
        • 1
          Open Source Message and Metadata Persistence
        • 1
          MQTT v5 implementation
        • 1
          Open source shared subscriptions
        CONS OF VERNEMQ
          Be the first to leave a con

          related VerneMQ posts

          RabbitMQ logo

          RabbitMQ

          21.3K
          557
          Open source multiprotocol messaging broker
          21.3K
          557
          PROS OF RABBITMQ
          • 235
            It's fast and it works with good metrics/monitoring
          • 80
            Ease of configuration
          • 60
            I like the admin interface
          • 52
            Easy to set-up and start with
          • 22
            Durable
          • 19
            Standard protocols
          • 19
            Intuitive work through python
          • 11
            Written primarily in Erlang
          • 9
            Simply superb
          • 7
            Completeness of messaging patterns
          • 4
            Reliable
          • 4
            Scales to 1 million messages per second
          • 3
            Better than most traditional queue based message broker
          • 3
            Distributed
          • 3
            Supports MQTT
          • 3
            Supports AMQP
          • 2
            Clear documentation with different scripting language
          • 2
            Better routing system
          • 2
            Inubit Integration
          • 2
            Great ui
          • 2
            High performance
          • 2
            Reliability
          • 2
            Open-source
          • 2
            Runs on Open Telecom Platform
          • 2
            Clusterable
          • 2
            Delayed messages
          • 1
            Supports Streams
          • 1
            Supports STOMP
          • 1
            Supports JMS
          CONS OF RABBITMQ
          • 9
            Too complicated cluster/HA config and management
          • 6
            Needs Erlang runtime. Need ops good with Erlang runtime
          • 5
            Configuration must be done first, not by your code
          • 4
            Slow

          related RabbitMQ posts

          James Cunningham
          Operations Engineer at Sentry · | 18 upvotes · 1.8M views
          Shared insights
          on
          CeleryCeleryRabbitMQRabbitMQ
          at

          As Sentry runs throughout the day, there are about 50 different offline tasks that we execute—anything from “process this event, pretty please” to “send all of these cool people some emails.” There are some that we execute once a day and some that execute thousands per second.

          Managing this variety requires a reliably high-throughput message-passing technology. We use Celery's RabbitMQ implementation, and we stumbled upon a great feature called Federation that allows us to partition our task queue across any number of RabbitMQ servers and gives us the confidence that, if any single server gets backlogged, others will pitch in and distribute some of the backlogged tasks to their consumers.

          #MessageQueue

          See more

          Around the time of their Series A, Pinterest’s stack included Python and Django, with Tornado and Node.js as web servers. Memcached / Membase and Redis handled caching, with RabbitMQ handling queueing. Nginx, HAproxy and Varnish managed static-delivery and load-balancing, with persistent data storage handled by MySQL.

          See more
          Kafka logo

          Kafka

          23.5K
          607
          Distributed, fault tolerant, high throughput pub-sub messaging system
          23.5K
          607
          PROS OF KAFKA
          • 126
            High-throughput
          • 119
            Distributed
          • 92
            Scalable
          • 86
            High-Performance
          • 66
            Durable
          • 38
            Publish-Subscribe
          • 19
            Simple-to-use
          • 18
            Open source
          • 12
            Written in Scala and java. Runs on JVM
          • 9
            Message broker + Streaming system
          • 4
            KSQL
          • 4
            Avro schema integration
          • 4
            Robust
          • 3
            Suport Multiple clients
          • 2
            Extremely good parallelism constructs
          • 2
            Partioned, replayable log
          • 1
            Simple publisher / multi-subscriber model
          • 1
            Fun
          • 1
            Flexible
          CONS OF KAFKA
          • 32
            Non-Java clients are second-class citizens
          • 29
            Needs Zookeeper
          • 9
            Operational difficulties
          • 5
            Terrible Packaging

          related Kafka posts

          Nick Rockwell
          SVP, Engineering at Fastly · | 46 upvotes · 4.1M views

          When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?

          So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.

          React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.

          Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.

          See more
          Ashish Singh
          Tech Lead, Big Data Platform at Pinterest · | 38 upvotes · 3.3M views

          To provide employees with the critical need of interactive querying, we’ve worked with Presto, an open-source distributed SQL query engine, over the years. Operating Presto at Pinterest’s scale has involved resolving quite a few challenges like, supporting deeply nested and huge thrift schemas, slow/ bad worker detection and remediation, auto-scaling cluster, graceful cluster shutdown and impersonation support for ldap authenticator.

          Our infrastructure is built on top of Amazon EC2 and we leverage Amazon S3 for storing our data. This separates compute and storage layers, and allows multiple compute clusters to share the S3 data.

          We have hundreds of petabytes of data and tens of thousands of Apache Hive tables. Our Presto clusters are comprised of a fleet of 450 r4.8xl EC2 instances. Presto clusters together have over 100 TBs of memory and 14K vcpu cores. Within Pinterest, we have close to more than 1,000 monthly active users (out of total 1,600+ Pinterest employees) using Presto, who run about 400K queries on these clusters per month.

          Each query submitted to Presto cluster is logged to a Kafka topic via Singer. Singer is a logging agent built at Pinterest and we talked about it in a previous post. Each query is logged when it is submitted and when it finishes. When a Presto cluster crashes, we will have query submitted events without corresponding query finished events. These events enable us to capture the effect of cluster crashes over time.

          Each Presto cluster at Pinterest has workers on a mix of dedicated AWS EC2 instances and Kubernetes pods. Kubernetes platform provides us with the capability to add and remove workers from a Presto cluster very quickly. The best-case latency on bringing up a new worker on Kubernetes is less than a minute. However, when the Kubernetes cluster itself is out of resources and needs to scale up, it can take up to ten minutes. Some other advantages of deploying on Kubernetes platform is that our Presto deployment becomes agnostic of cloud vendor, instance types, OS, etc.

          #BigData #AWS #DataScience #DataEngineering

          See more
          MySQL logo

          MySQL

          125.4K
          3.8K
          The world's most popular open source database
          125.4K
          3.8K
          PROS OF MYSQL
          • 800
            Sql
          • 679
            Free
          • 562
            Easy
          • 528
            Widely used
          • 490
            Open source
          • 180
            High availability
          • 160
            Cross-platform support
          • 104
            Great community
          • 79
            Secure
          • 75
            Full-text indexing and searching
          • 26
            Fast, open, available
          • 16
            Reliable
          • 16
            SSL support
          • 15
            Robust
          • 9
            Enterprise Version
          • 7
            Easy to set up on all platforms
          • 3
            NoSQL access to JSON data type
          • 1
            Relational database
          • 1
            Easy, light, scalable
          • 1
            Sequel Pro (best SQL GUI)
          • 1
            Replica Support
          CONS OF MYSQL
          • 16
            Owned by a company with their own agenda
          • 3
            Can't roll back schema changes

          related MySQL posts

          Nick Rockwell
          SVP, Engineering at Fastly · | 46 upvotes · 4.1M views

          When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?

          So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.

          React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.

          Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.

          See more
          Tim Abbott

          We've been using PostgreSQL since the very early days of Zulip, but we actually didn't use it from the beginning. Zulip started out as a MySQL project back in 2012, because we'd heard it was a good choice for a startup with a wide community. However, we found that even though we were using the Django ORM for most of our database access, we spent a lot of time fighting with MySQL. Issues ranged from bad collation defaults, to bad query plans which required a lot of manual query tweaks.

          We ended up getting so frustrated that we tried out PostgresQL, and the results were fantastic. We didn't have to do any real customization (just some tuning settings for how big a server we had), and all of our most important queries were faster out of the box. As a result, we were able to delete a bunch of custom queries escaping the ORM that we'd written to make the MySQL query planner happy (because postgres just did the right thing automatically).

          And then after that, we've just gotten a ton of value out of postgres. We use its excellent built-in full-text search, which has helped us avoid needing to bring in a tool like Elasticsearch, and we've really enjoyed features like its partial indexes, which saved us a lot of work adding unnecessary extra tables to get good performance for things like our "unread messages" and "starred messages" indexes.

          I can't recommend it highly enough.

          See more
          PostgreSQL logo

          PostgreSQL

          98.3K
          3.5K
          A powerful, open source object-relational database system
          98.3K
          3.5K
          PROS OF POSTGRESQL
          • 764
            Relational database
          • 510
            High availability
          • 439
            Enterprise class database
          • 383
            Sql
          • 304
            Sql + nosql
          • 173
            Great community
          • 147
            Easy to setup
          • 131
            Heroku
          • 130
            Secure by default
          • 113
            Postgis
          • 50
            Supports Key-Value
          • 48
            Great JSON support
          • 34
            Cross platform
          • 33
            Extensible
          • 28
            Replication
          • 26
            Triggers
          • 23
            Multiversion concurrency control
          • 23
            Rollback
          • 21
            Open source
          • 18
            Heroku Add-on
          • 17
            Stable, Simple and Good Performance
          • 15
            Powerful
          • 13
            Lets be serious, what other SQL DB would you go for?
          • 11
            Good documentation
          • 9
            Scalable
          • 8
            Free
          • 8
            Reliable
          • 8
            Intelligent optimizer
          • 7
            Transactional DDL
          • 7
            Modern
          • 6
            One stop solution for all things sql no matter the os
          • 5
            Relational database with MVCC
          • 5
            Faster Development
          • 4
            Full-Text Search
          • 4
            Developer friendly
          • 3
            Excellent source code
          • 3
            Free version
          • 3
            Great DB for Transactional system or Application
          • 3
            Relational datanbase
          • 3
            search
          • 3
            Open-source
          • 2
            Text
          • 2
            Full-text
          • 1
            Can handle up to petabytes worth of size
          • 1
            Composability
          • 1
            Multiple procedural languages supported
          • 0
            Native
          CONS OF POSTGRESQL
          • 10
            Table/index bloatings

          related PostgreSQL posts

          Simon Reymann
          Senior Fullstack Developer at QUANTUSflow Software GmbH · | 30 upvotes · 11.6M views

          Our whole DevOps stack consists of the following tools:

          • GitHub (incl. GitHub Pages/Markdown for Documentation, GettingStarted and HowTo's) for collaborative review and code management tool
          • Respectively Git as revision control system
          • SourceTree as Git GUI
          • Visual Studio Code as IDE
          • CircleCI for continuous integration (automatize development process)
          • Prettier / TSLint / ESLint as code linter
          • SonarQube as quality gate
          • Docker as container management (incl. Docker Compose for multi-container application management)
          • VirtualBox for operating system simulation tests
          • Kubernetes as cluster management for docker containers
          • Heroku for deploying in test environments
          • nginx as web server (preferably used as facade server in production environment)
          • SSLMate (using OpenSSL) for certificate management
          • Amazon EC2 (incl. Amazon S3) for deploying in stage (production-like) and production environments
          • PostgreSQL as preferred database system
          • Redis as preferred in-memory database/store (great for caching)

          The main reason we have chosen Kubernetes over Docker Swarm is related to the following artifacts:

          • Key features: Easy and flexible installation, Clear dashboard, Great scaling operations, Monitoring is an integral part, Great load balancing concepts, Monitors the condition and ensures compensation in the event of failure.
          • Applications: An application can be deployed using a combination of pods, deployments, and services (or micro-services).
          • Functionality: Kubernetes as a complex installation and setup process, but it not as limited as Docker Swarm.
          • Monitoring: It supports multiple versions of logging and monitoring when the services are deployed within the cluster (Elasticsearch/Kibana (ELK), Heapster/Grafana, Sysdig cloud integration).
          • Scalability: All-in-one framework for distributed systems.
          • Other Benefits: Kubernetes is backed by the Cloud Native Computing Foundation (CNCF), huge community among container orchestration tools, it is an open source and modular tool that works with any OS.
          See more
          Jeyabalaji Subramanian

          Recently we were looking at a few robust and cost-effective ways of replicating the data that resides in our production MongoDB to a PostgreSQL database for data warehousing and business intelligence.

          We set ourselves the following criteria for the optimal tool that would do this job: - The data replication must be near real-time, yet it should NOT impact the production database - The data replication must be horizontally scalable (based on the load), asynchronous & crash-resilient

          Based on the above criteria, we selected the following tools to perform the end to end data replication:

          We chose MongoDB Stitch for picking up the changes in the source database. It is the serverless platform from MongoDB. One of the services offered by MongoDB Stitch is Stitch Triggers. Using stitch triggers, you can execute a serverless function (in Node.js) in real time in response to changes in the database. When there are a lot of database changes, Stitch automatically "feeds forward" these changes through an asynchronous queue.

          We chose Amazon SQS as the pipe / message backbone for communicating the changes from MongoDB to our own replication service. Interestingly enough, MongoDB stitch offers integration with AWS services.

          In the Node.js function, we wrote minimal functionality to communicate the database changes (insert / update / delete / replace) to Amazon SQS.

          Next we wrote a minimal micro-service in Python to listen to the message events on SQS, pickup the data payload & mirror the DB changes on to the target Data warehouse. We implemented source data to target data translation by modelling target table structures through SQLAlchemy . We deployed this micro-service as AWS Lambda with Zappa. With Zappa, deploying your services as event-driven & horizontally scalable Lambda service is dumb-easy.

          In the end, we got to implement a highly scalable near realtime Change Data Replication service that "works" and deployed to production in a matter of few days!

          See more