Alternatives to MQTT logo

Alternatives to MQTT

RabbitMQ, REST, XMPP, Google Cloud Messaging, and Kafka are the most popular alternatives and competitors to MQTT.
599
570
+ 1
7

What is MQTT and what are its top alternatives?

MQTT (Message Queuing Telemetry Transport) is a lightweight messaging protocol commonly used for IoT applications. It is known for its simplicity, low bandwidth usage, and efficient message delivery. However, MQTT lacks built-in security features, and the protocol does not support message queuing or persistence by default, making it less suitable for scenarios requiring guaranteed message delivery or high security requirements.

  1. AMQP (Advanced Message Queuing Protocol): AMQP is a messaging protocol designed for enterprise use cases, providing features like message queuing, persistence, and advanced security mechanisms. It offers more robust message delivery guarantees and supports complex messaging patterns. However, AMQP is more complex to implement and may require more resources compared to MQTT.
  2. CoAP (Constrained Application Protocol): CoAP is a specialized messaging protocol for constrained IoT devices operating in low-power, low-bandwidth environments. It is designed to be lightweight, efficient, and suitable for resource-constrained devices. CoAP supports RESTful interactions and provides features like reliable delivery and multicast communication. However, CoAP may have limited support in some environments compared to MQTT.
  3. STOMP (Simple Text Oriented Messaging Protocol): STOMP is a text-based messaging protocol that offers simplicity and ease of integration for messaging applications. It provides basic features for message delivery and subscription, making it suitable for simple messaging requirements. STOMP is supported by various messaging brokers and libraries, but it may lack some advanced features compared to MQTT.
  4. XMPP (Extensible Messaging and Presence Protocol): XMPP is an open messaging protocol designed for real-time communication, presence information, and messaging exchange. It supports features like authentication, encryption, and message routing, making it suitable for instant messaging and collaboration applications. XMPP is extensible and widely adopted in the domain of chat applications, but it may have higher overhead compared to MQTT.
  5. DDS (Data Distribution Service): DDS is a messaging standard for real-time and high-performance data distribution in distributed systems. It offers features like data-centric communication, Quality of Service policies, and scalable publish-subscribe messaging. DDS is suitable for applications requiring low latency, high throughput, and deterministic messaging behavior. However, DDS may have higher complexity and resource requirements compared to MQTT.
  6. Kafka: Apache Kafka is a distributed streaming platform that provides features for building real-time data pipelines and event-driven applications. It offers high throughput, fault tolerance, and scalable message processing capabilities. Kafka is widely used for data stream processing and event sourcing, making it suitable for scenarios requiring high volume data ingestion and processing. However, Kafka may have higher operational complexity and infrastructure requirements compared to MQTT.
  7. RabbitMQ: RabbitMQ is a popular open-source message broker that implements multiple messaging protocols, including AMQP, MQTT, and STOMP. It provides features like message queuing, routing, and clustering, making it suitable for building distributed messaging systems. RabbitMQ offers high flexibility and extensibility, but it may have higher resource overhead compared to MQTT.
  8. NATS: NATS is a lightweight and high-performance messaging system designed for cloud-native applications and microservices. It offers features like publish-subscribe messaging, request-reply communication, and streaming capabilities. NATS is known for its simplicity, speed, and scalability, making it suitable for modern cloud-native architectures. However, NATS may lack some advanced features and integrations compared to MQTT.
  9. WebSocket: WebSocket is a communication protocol that provides full-duplex communication channels over a single TCP connection. It allows for real-time, bi-directional data transfer between clients and servers, making it suitable for web-based messaging applications. WebSocket provides low latency, efficient data transfer, and cross-platform compatibility, but it may require additional considerations for security and reliability compared to MQTT.
  10. IoTivity: IoTivity is an open-source framework that provides a standard way to connect IoT devices and enable communication between them. It offers features for device discovery, data exchange, and secure communication, making it suitable for building interoperable IoT solutions. IoTivity is supported by the Open Connectivity Foundation and aims to create a unified IoT ecosystem. However, IoTivity may require more configuration and setup compared to MQTT for certain IoT use cases.

Top Alternatives to MQTT

  • RabbitMQ
    RabbitMQ

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

  • REST
    REST

    An architectural style for developing web services. A distributed system framework that uses Web protocols and technologies. ...

  • XMPP
    XMPP

    It is a set of open technologies for instant messaging, presence, multi-party chat, voice and video calls, collaboration, lightweight middleware, content syndication, and generalized routing of XML data. ...

  • Google Cloud Messaging
    Google Cloud Messaging

    Google Cloud Messaging (GCM) is a free service that enables developers to send messages between servers and client apps. This includes downstream messages from servers to client apps, and upstream messages from client apps to servers. ...

  • Kafka
    Kafka

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

  • ZeroMQ
    ZeroMQ

    The 0MQ lightweight messaging kernel is a library which extends the standard socket interfaces with features traditionally provided by specialised messaging middleware products. 0MQ sockets provide an abstraction of asynchronous message queues, multiple messaging patterns, message filtering (subscriptions), seamless access to multiple transport protocols and more. ...

  • gRPC
    gRPC

    gRPC is a modern open source high performance RPC framework that can run in any environment. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking... ...

  • JavaScript
    JavaScript

    JavaScript is most known as the scripting language for Web pages, but used in many non-browser environments as well such as node.js or Apache CouchDB. It is a prototype-based, multi-paradigm scripting language that is dynamic,and supports object-oriented, imperative, and functional programming styles. ...

MQTT alternatives & related posts

RabbitMQ logo

RabbitMQ

21K
18.5K
527
Open source multiprotocol messaging broker
21K
18.5K
+ 1
527
PROS OF RABBITMQ
  • 234
    It's fast and it works with good metrics/monitoring
  • 79
    Ease of configuration
  • 59
    I like the admin interface
  • 50
    Easy to set-up and start with
  • 21
    Durable
  • 18
    Intuitive work through python
  • 18
    Standard protocols
  • 10
    Written primarily in Erlang
  • 8
    Simply superb
  • 6
    Completeness of messaging patterns
  • 3
    Scales to 1 million messages per second
  • 3
    Reliable
  • 2
    Distributed
  • 2
    Supports MQTT
  • 2
    Better than most traditional queue based message broker
  • 2
    Supports AMQP
  • 1
    Clusterable
  • 1
    Clear documentation with different scripting language
  • 1
    Great ui
  • 1
    Inubit Integration
  • 1
    Better routing system
  • 1
    High performance
  • 1
    Runs on Open Telecom Platform
  • 1
    Delayed messages
  • 1
    Reliability
  • 1
    Open-source
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.7M 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
REST logo

REST

20
192
0
A software architectural style
20
192
+ 1
0
PROS OF REST
  • 4
    Popularity
CONS OF REST
    Be the first to leave a con

    related REST posts

    XMPP logo

    XMPP

    67
    136
    0
    An open XML technology for real-time communication
    67
    136
    + 1
    0
    PROS OF XMPP
      Be the first to leave a pro
      CONS OF XMPP
        Be the first to leave a con

        related XMPP posts

        Google Cloud Messaging logo

        Google Cloud Messaging

        91
        246
        22
        Simple and reliable messaging to reach over a billion devices.
        91
        246
        + 1
        22
        PROS OF GOOGLE CLOUD MESSAGING
        • 9
          Free
        • 6
          Scalable
        • 4
          Easy setup
        • 2
          Easy iOS setup
        • 1
          IOS Support
        CONS OF GOOGLE CLOUD MESSAGING
        • 1
          Reliability

        related Google Cloud Messaging posts

        Kafka logo

        Kafka

        23.2K
        21.8K
        607
        Distributed, fault tolerant, high throughput pub-sub messaging system
        23.2K
        21.8K
        + 1
        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 · 3.5M 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 · 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
        ZeroMQ logo

        ZeroMQ

        260
        583
        71
        Fast, lightweight messaging library that allows you to design complex communication system without much effort
        260
        583
        + 1
        71
        PROS OF ZEROMQ
        • 23
          Fast
        • 20
          Lightweight
        • 11
          Transport agnostic
        • 7
          No broker required
        • 4
          Low level APIs are in C
        • 4
          Low latency
        • 1
          Open source
        • 1
          Publish-Subscribe
        CONS OF ZEROMQ
        • 5
          No message durability
        • 3
          Not a very reliable system - message delivery wise
        • 1
          M x N problem with M producers and N consumers

        related ZeroMQ posts

        Shared insights
        on
        MongoDBMongoDBZeroMQZeroMQSpring BootSpring Boot

        In our Spring Boot application, which encompasses various projects, we employ ZeroMQ (ZMQ) for communication via a req/resp pattern. Recently, I observed that data is persisted in the MongoDB database before being transmitted to other applications. I've identified a method to monitor changes to the database, and I'm contemplating whether to utilize this monitoring approach to detect changes and execute the necessary instructions.

        Which approach is more advisable in this scenario: leveraging the database monitoring mechanism or sticking with the current ZMQ req/resp communication?

        Essentially, I'm seeking guidance on whether to rely on database monitoring for change detection and subsequent actions or to continue with the existing ZMQ communication pattern.

        See more
        Meili Triantafyllidi
        Software engineer at Digital Science · | 6 upvotes · 446.3K views
        Shared insights
        on
        Amazon SQSAmazon SQSRabbitMQRabbitMQZeroMQZeroMQ

        Hi, we are in a ZMQ set up in a push/pull pattern, and we currently start to have more traffic and cases that the service is unavailable or stuck. We want to: * Not loose messages in services outages * Safely restart service without losing messages (ZeroMQ seems to need to close the socket in the receiver before restart manually)

        Do you have experience with this setup with ZeroMQ? Would you suggest RabbitMQ or Amazon SQS (we are in AWS setup) instead? Something else?

        Thank you for your time

        See more
        gRPC logo

        gRPC

        2.2K
        1.3K
        63
        A high performance, open-source universal RPC framework
        2.2K
        1.3K
        + 1
        63
        PROS OF GRPC
        • 24
          Higth performance
        • 15
          The future of API
        • 13
          Easy setup
        • 5
          Contract-based
        • 4
          Polyglot
        • 2
          Garbage
        CONS OF GRPC
          Be the first to leave a con

          related gRPC posts

          Noah Zoschke
          Engineering Manager at Segment · | 30 upvotes · 271.6K views

          We just launched the Segment Config API (try it out for yourself here) — a set of public REST APIs that enable you to manage your Segment configuration. Behind the scenes the Config API is built with Go , GRPC and Envoy.

          At Segment, we build new services in Go by default. The language is simple so new team members quickly ramp up on a codebase. The tool chain is fast so developers get immediate feedback when they break code, tests or integrations with other systems. The runtime is fast so it performs great at scale.

          For the newest round of APIs we adopted the GRPC service #framework.

          The Protocol Buffer service definition language makes it easy to design type-safe and consistent APIs, thanks to ecosystem tools like the Google API Design Guide for API standards, uber/prototool for formatting and linting .protos and lyft/protoc-gen-validate for defining field validations, and grpc-gateway for defining REST mapping.

          With a well designed .proto, its easy to generate a Go server interface and a TypeScript client, providing type-safe RPC between languages.

          For the API gateway and RPC we adopted the Envoy service proxy.

          The internet-facing segmentapis.com endpoint is an Envoy front proxy that rate-limits and authenticates every request. It then transcodes a #REST / #JSON request to an upstream GRPC request. The upstream GRPC servers are running an Envoy sidecar configured for Datadog stats.

          The result is API #security , #reliability and consistent #observability through Envoy configuration, not code.

          We experimented with Swagger service definitions, but the spec is sprawling and the generated clients and server stubs leave a lot to be desired. GRPC and .proto and the Go implementation feels better designed and implemented. Thanks to the GRPC tooling and ecosystem you can generate Swagger from .protos, but it’s effectively impossible to go the other way.

          See more
          Dylan Krupp
          Shared insights
          on
          gRPCgRPCGraphQLGraphQL

          I used GraphQL extensively at a previous employer a few years ago and really appreciated the data-driven schema etc alongside the many other benefits it provided. At that time, it seemed like it was set to replace RESTful APIs and many companies were adopting it.

          However, as of late, it seems like interest has been waning for GraphQL as opposed to increasing as I had assumed it would. Am I missing something here? What is the current perspective regarding this technology?

          Currently, I'm working with gRPC and was curious as to the state of everything now.

          See more
          JavaScript logo

          JavaScript

          352.4K
          268.3K
          8.1K
          Lightweight, interpreted, object-oriented language with first-class functions
          352.4K
          268.3K
          + 1
          8.1K
          PROS OF JAVASCRIPT
          • 1.7K
            Can be used on frontend/backend
          • 1.5K
            It's everywhere
          • 1.2K
            Lots of great frameworks
          • 897
            Fast
          • 745
            Light weight
          • 425
            Flexible
          • 392
            You can't get a device today that doesn't run js
          • 286
            Non-blocking i/o
          • 237
            Ubiquitousness
          • 191
            Expressive
          • 55
            Extended functionality to web pages
          • 49
            Relatively easy language
          • 46
            Executed on the client side
          • 30
            Relatively fast to the end user
          • 25
            Pure Javascript
          • 21
            Functional programming
          • 15
            Async
          • 13
            Full-stack
          • 12
            Setup is easy
          • 12
            Future Language of The Web
          • 12
            Its everywhere
          • 11
            Because I love functions
          • 11
            JavaScript is the New PHP
          • 10
            Like it or not, JS is part of the web standard
          • 9
            Expansive community
          • 9
            Everyone use it
          • 9
            Can be used in backend, frontend and DB
          • 9
            Easy
          • 8
            Most Popular Language in the World
          • 8
            Powerful
          • 8
            Can be used both as frontend and backend as well
          • 8
            For the good parts
          • 8
            No need to use PHP
          • 8
            Easy to hire developers
          • 7
            Agile, packages simple to use
          • 7
            Love-hate relationship
          • 7
            Photoshop has 3 JS runtimes built in
          • 7
            Evolution of C
          • 7
            It's fun
          • 7
            Hard not to use
          • 7
            Versitile
          • 7
            Its fun and fast
          • 7
            Nice
          • 7
            Popularized Class-Less Architecture & Lambdas
          • 7
            Supports lambdas and closures
          • 6
            It let's me use Babel & Typescript
          • 6
            Can be used on frontend/backend/Mobile/create PRO Ui
          • 6
            1.6K Can be used on frontend/backend
          • 6
            Client side JS uses the visitors CPU to save Server Res
          • 6
            Easy to make something
          • 5
            Clojurescript
          • 5
            Promise relationship
          • 5
            Stockholm Syndrome
          • 5
            Function expressions are useful for callbacks
          • 5
            Scope manipulation
          • 5
            Everywhere
          • 5
            Client processing
          • 5
            What to add
          • 4
            Because it is so simple and lightweight
          • 4
            Only Programming language on browser
          • 1
            Test
          • 1
            Hard to learn
          • 1
            Test2
          • 1
            Not the best
          • 1
            Easy to understand
          • 1
            Subskill #4
          • 1
            Easy to learn
          • 0
            Hard 彤
          CONS OF JAVASCRIPT
          • 22
            A constant moving target, too much churn
          • 20
            Horribly inconsistent
          • 15
            Javascript is the New PHP
          • 9
            No ability to monitor memory utilitization
          • 8
            Shows Zero output in case of ANY error
          • 7
            Thinks strange results are better than errors
          • 6
            Can be ugly
          • 3
            No GitHub
          • 2
            Slow

          related JavaScript posts

          Zach Holman

          Oof. I have truly hated JavaScript for a long time. Like, for over twenty years now. Like, since the Clinton administration. It's always been a nightmare to deal with all of the aspects of that silly language.

          But wowza, things have changed. Tooling is just way, way better. I'm primarily web-oriented, and using React and Apollo together the past few years really opened my eyes to building rich apps. And I deeply apologize for using the phrase rich apps; I don't think I've ever said such Enterprisey words before.

          But yeah, things are different now. I still love Rails, and still use it for a lot of apps I build. But it's that silly rich apps phrase that's the problem. Users have way more comprehensive expectations than they did even five years ago, and the JS community does a good job at building tools and tech that tackle the problems of making heavy, complicated UI and frontend work.

          Obviously there's a lot of things happening here, so just saying "JavaScript isn't terrible" might encompass a huge amount of libraries and frameworks. But if you're like me, yeah, give things another shot- I'm somehow not hating on JavaScript anymore and... gulp... I kinda love it.

          See more
          Conor Myhrvold
          Tech Brand Mgr, Office of CTO at Uber · | 44 upvotes · 10.9M views

          How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:

          Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.

          Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:

          https://eng.uber.com/distributed-tracing/

          (GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)

          Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark

          See more