Apache Kafka is an open-source stream processing platform developed by the Apache Software Foundation written in Scala and Java. The Kafka event streaming platform is used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications.
N/A
RabbitMQ
Score 8.9 out of 10
N/A
RabbitMQ, an open source message broker, is part of Pivotal Software, a VMware company acquired in 2019, and supports message queue, multiple messaging protocols, and more.
RabbitMQ is available open source, however VMware also offers a range of commercial services for RabbitMQ; these are available as part of the Pivotal App Suite.
N/A
Pricing
Apache Kafka
RabbitMQ
Editions & Modules
No answers on this topic
No answers on this topic
Offerings
Pricing Offerings
Apache Kafka
RabbitMQ
Free Trial
No
No
Free/Freemium Version
No
No
Premium Consulting/Integration Services
No
No
Entry-level Setup Fee
No setup fee
No setup fee
Additional Details
—
—
More Pricing Information
Community Pulse
Apache Kafka
RabbitMQ
Considered Both Products
Apache Kafka
Verified User
Engineer
Chose Apache Kafka
I would only use RabbitMQ over Kafka when you need to have delay queues or tons of small topics/queues around. I don't know too much about Pulsar - currently evaluating it - but it's supposed to have the same or better throughput while allowing for tons of queues. Stay tuned - I …
Kafka is not a real messaging broker implementation as RabbitMQ or TIBCO EMS/JMS are. Although it can be used as messaging, we like the idea behind the Kafka (data isn't "passing by," instead it remains centra, so the client can revisit the data if necessary). This also …
Apache Kafka is built for scale. From high throughput and real-time data streaming, it has a strong advantage over RabbitMQ with its low latency. This put Apache Kafka at the forefront as the platform of choice for large datasets messaging and ensuring scalability when data …
We really needed to get away from using a SQL database to act as a queue for processing records, so a new solution was needed. Kafka is a leading software application initially designed for queuing messages which is essentially what we were looking for. It has a great user …
Confluent Cloud is still based on Apache Kafka but it has a subscription fee so, from a long term perspective, it is wiser to deploy your own Kafka instance that spans public and private cloud. Amazon Kinesis, Google Cloud Pub/Sub do not do well for a very number of messages …
It is very easy to use as it has a simple function to connect and use RabbitMQ. It is having Fast Learning curve, Any newbies can learn it in a week or month. It is having proper documentation, we are able to find all the details about its functionality and usage of it. The …
Honestly, though we're still trying out Kafka and Pulsar, I'd go with them for message broker and as traffic buffers. We are only still using RabbitMQ because it's hard to transition off after writing tons of code custom-built for RabbitMQ. Kafka is better because it's way more …
Apache Kafka and RabbitMQ are both message queue software designed to enable applications to communicate with each other asynchronously. Though Apache Kafka works as a streaming platform that performs messaging tasks, both it and RabbitMQ function as traditional message queue software.
Both RabbitMQ and Apache Kafka are more popular with mid-sized to large organizations. Larger enterprises use Apache Kafka is slightly more often, while mid-sized businesses prefer RabbitMQ.
Features
Though Apache Kafka and RabbitMQ are both robust message queue tools, they each offer a few standout features that set them apart from one another.
Apache Kafka performs well with large amounts of data, transferring messages quickly, even in high volumes. This high performance makes Apache Kafka a good choice for organizations with many messages in the queue, perhaps due to batch consumers that may not be connected to the message queue at all times. Apache Kafka is also very scalable, increasing performance for extreme workloads can be as simple as running it on additional nodes.
RabbitMQ offers many client libraries for languages like Python, PHP, JavaScript, and more. This multitude of client libraries makes it easy for most businesses to start using RabbitMQ without compatibility issues. RabbitMQ supports complex routing, which can be important messages that need to be delivered to consumers in less straightforward ways. RabbitMQ also provides a built-in user interface out of the box that is easy for users to manage, making RabbitMQ a relatively user-friendly message queue software.
Limitations
Despite their essential message queue features, Apache Kafka and RabbitMQ both have a few limitations that are worth considering.
Apache Kafka lacks the variety of client libraries that RabbitMQ supports. Though first and third-party developers are building more client libraries, most are not available at present. Similarly, there are third-party tools that add monitoring features to Apache Kafka, but they are not available out of the box, which can make it more difficult to use. Implementation for Apache Kafka can also be challenging and time-consuming, particularly for an organization that hasn’t purchased any vendor support.
RabbitMQ experiences slower performance as applications append more messages to the queue. For organizations with large amounts of data in their message queue, RabbitMQ can’t match Apache Kafka’s speed. Users may also have a difficult time accessing information within the message queue without pulling messages out of the queue.
Pricing
RabbitMQ and Kafka are both open-source software, meaning their source code is available online for free. Many vendors offer support for both software options, ranging from implementation to ongoing maintenance. Pricing for support is quoted based on the features the vendor offers as well as the needs of the organization.
Apache Kafka is well-suited for most data-streaming use cases. Amazon Kinesis and Azure EventHubs, unless you have a specific use case where using those cloud PaAS for your data lakes, once set up well, Apache Kafka will take care of everything else in the background. Azure EventHubs, is good for cross-cloud use cases, and Amazon Kinesis - I have no real-world experience. But I believe it is the same.
It is highly recommended that if you have microservices architecture and if you want to solve 2 phase commit issue, you should use RabbitMQ for communication between microservices. It is a quick and reliable mode of communication between microservices. It is also helpful if you want to implement a job and worker mechanism. You can push the jobs into RabbitMQ and that will be sent to the consumer. It is highly reliable so you won't miss any jobs and you can also implement a retry of jobs with the dead letter queue feature. It will be also helpful in time-consuming API. You can put time-consuming items into a queue so they will be processed later and your API will be quick.
Really easy to configure. I've used other message brokers such as RabbitMQ and compared to them, Kafka's configurations are very easy to understand and tweak.
Very scalable: easily configured to run on multiple nodes allowing for ease of parallelism (assuming your queues/topics don't have to be consumed in the exact same order the messages were delivered)
Not exactly a feature, but I trust Kafka will be around for at least another decade because active development has continued to be strong and there's a lot of financial backing from Confluent and LinkedIn, and probably many other companies who are using it (which, anecdotally, is many).
What RabbitMQ does well is what it's advertised to do. It is good at providing lots of high volume, high availability queue. We've seen it handle upwards of 10 million messages in its queues, spread out over 200 queues before its publish/consume rates dipped. So yeah, it can definitely handle a lot of messages and a lot of queues. Depending on the size of the machine RabbitMQ is running on, I'm sure it can handle more.
Decent number of plugins! Want a plugin that gives you an interface to view all the queues and see their publish/consume rates? Yes, there's one for that. Want a plugin to "shovel" messages from one queue to another in an emergency? Check. Want a plugin that does extra logging for all the messages received? Got you covered!
Lots of configuration possibilities. We've tuned over 100 settings over the past year to get the performance and reliability just right. This could be a downside though--it's pretty confusing and some settings were hard to understand.
Sometimes it becomes difficult to monitor our Kafka deployments. We've been able to overcome it largely using AWS MSK, a managed service for Apache Kafka, but a separate monitoring dashboard would have been great.
Simplify the process for local deployment of Kafka and provide a user interface to get visibility into the different topics and the messages being processed.
Learning curve around creation of broker and topics could be simplified
It breaks communication if we don't acknowledge early. In some cases our work items are time consuming that will take a time and in that scenario we are getting errors that RabbitMQ broke the channel. It will be good if RabbitMQ provides two acknowledgements, one is for that it has been received at client side and second ack is client is completed the processing part.
Apache Kafka is highly recommended to develop loosely coupled, real-time processing applications. Also, Apache Kafka provides property based configuration. Producer, Consumer and broker contain their own separate property file
RabbitMQ is very easy to configure for all supported languages (Python, Java, etc.). I have personally used it on Raspberry Pi devices via a Flask Python API as well as in Java applications. I was able to learn it quickly and now have full mastery of it. I highly recommend it for any IoT project.
Support for Apache Kafka (if willing to pay) is available from Confluent that includes the same time that created Kafka at Linkedin so they know this software in and out. Moreover, Apache Kafka is well known and best practices documents and deployment scenarios are easily available for download. For example, from eBay, Linkedin, Uber, and NYTimes.
I gave it a 10 but we do not have a support contract with any company for RabbitMQ so there is no official support in that regard. However, there is a community and questions asked on StackOverflow or any other major question and answer site will usually get a response.
I used other messaging/queue solutions that are a lot more basic than Confluent Kafka, as well as another solution that is no longer in the market called Xively, which was bought and "buried" by Google. In comparison, these solutions offer way fewer functionalities and respond to other needs.
RabbitMQ has a few advantages over Azure Service Bus 1) RMQ handles substantially larger files - ASB tops out at 100MB, we use RabbitMQfor files over 200MB 2) RabbitMQ can be easily setup on prem - Azure Service Bus is cloud only 3) RabbitMQ exchanges are easier to configure over ASB subscriptions ASB has a few advantages too 1) Cloud based - just a few mouse clicks and you're up and running
Positive: Get a quick and reliable pub/sub model implemented - data across components flows easily.
Positive: it's scalable so we can develop small and scale for real-world scenarios
Negative: it's easy to get into a confusing situation if you are not experienced yet or something strange has happened (rare, but it does). Troubleshooting such situations can take time and effort.
Positive: we don't need to keep way too many backend machines around to deal with bursts because RabbitMQ can absorb and buffer bursts long enough to let an understaffed set of backend services to catch up on processing. Hard to put a number to it but we probably save $5k a month having fewer machines around.
Negative: we've got many angry customers due to queues suddenly disappearing and dropping our messages when we try to publish to them afterward. Ideally, RabbitMQ should warn the user when queues expire due to inactivity but it doesn't, and due to our own bugs we've lost a lot of customer data as a result.
Positive: makes decoupling the web and API services from the deeper backend services easier by providing queues as an interface. This allowed us to split up our teams and have them develop independently of each other, speeding up software development.
