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
Redis™*
Score 9.0 out of 10
N/A
Redis is an open source in-memory data structure server and NoSQL database.
$388
per month
Pricing
RabbitMQ
Redis™*
Editions & Modules
No answers on this topic
Cloud
$388.00
per month
Offerings
Pricing Offerings
RabbitMQ
Redis™*
Free Trial
No
Yes
Free/Freemium Version
No
Yes
Premium Consulting/Integration Services
No
Yes
Entry-level Setup Fee
No setup fee
Optional
Additional Details
—
—
More Pricing Information
Community Pulse
RabbitMQ
Redis™*
Considered Both Products
RabbitMQ
Verified User
Engineer
Chose RabbitMQ
For basic use cases, SQS is way easy to deploy and maintain compared to RabbitMQ. RabbitMQ can cover a lot more use-cases but actually, we did not face specific scenarios that make it necessary to come back to RabbitMQ.
UI isn't that great compared to the other competitors. The management of our memcached cluster was becoming pretty complicated as the application grew in size. Redis is a much better option compared to memcached. Redis is bit unreliable compared to the alternative RabbitMQ …
RabbitMQ and Redis have some similarities, but are fundamentally different products. RabbitMQ is a dedicated message broker system, designed to give applications a common platform for communication. Redis is an in-memory data structure store with multiple data-storage applications, including message brokering. Redis is used mostly by mid-size companies, probably due to growing data structuring and access needs as the company scales up. RabbitMQ is used among businesses of all sizes, likely due to its free price tag and lightweight footprint.
Features
Redis and RabbitMQ both deal with large volumes of data requests, but they’re definitely not interchangeable.
As a general-use data store system, Redis can be used in many ways, including as a database, cache, or message broker. Most developers find it easy to get up and running with Redis, with simple setup and plenty of documentation. It’s fast and reliable, providing solid uptime. It can be configured to automatically back-up to remote storage, giving businesses data security in case of an outage. Redis is widely supported, with plenty of tools, libraries, and services built upon its open-source framework.
RabbitMQ is also open-source, but its capabilities are limited to message brokering. It supports clustering to provide redundancy and is capable of handling millions of messages per second. Despite its dedicated nature, it can still be configured in a variety of ways to optimize its performance for specific applications, including via community-developed plugins. It also natively supports both in-memory and persistent messages for applications that can afford to sacrifice access speed for data persistence.
Limitations
Obviously, RabbitMQ is limited to its role as a message broker. However, both it and Redis have their own drawbacks to consider before implementing either.
RabbitMQ uses a queue system to make sure messages go where they need to and in the right order. Queues can be set to expire under certain conditions, and some users have experienced intermittent data loss from unexpected expiration. RabbitMQ also doesn’t offer many options for observing the queues themselves, which can make it difficult to gauge the number of messages in a queue. Some users have found the documentation for RabbitMQ lacking in specific instances, and there’s no dedicated customer support unless you pay a subscription fee.
Redis is more flexible in its potential applications, but that flexibility can cause problems as well. Although it’s thoroughly documented, some users find the documentation bloated and difficult to navigate, making it hard to find the specific reference they need. Redis doesn’t come with a dedicated GUI or management tool, and there’s no built-in method for controlling user permissions. And since RAM is more expensive per gigabyte than ROM, Redis’s in-memory storage system can get pricey as your business’s data needs expand.
Pricing
Both Redis and RabbitMQ are open-source and free. However, RabbitMQ offers a subscription-based customer support plan, and many companies offer Redis- or RabbitMQ-based services. Pricing information for these services is available via quote from the vendors.
Features
RabbitMQ
Redis™*
NoSQL Databases
Comparison of NoSQL Databases features of Product A and Product B
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.
Redis has been a great investment for our organization as we needed a solution for high speed data caching. The ramp up and integration was quite easy. Redis handles automatic failover internally, so no crashes provides high availability. On the fly scaling scale to more/less cores and memory as and when needed.
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.
Easy for developers to understand. Unlike Riak, which I've used in the past, it's fast without having to worry about eventual consistency.
Reliable. With a proper multi-node configuration, it can handle failover instantly.
Configurable. We primarily still use Memcache for caching but one of the teams uses Redis for both long-term storage and temporary expiry keys without taking on another external dependency.
Fast. We process tens of thousands of RPS and it doesn't skip a beat.
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.
We had some difficulty scaling Redis without it becoming prohibitively expensive.
Redis has very simple search capabilities, which means its not suitable for all use cases.
Redis doesn't have good native support for storing data in object form and many libraries built over it return data as a string, meaning you need build your own serialization layer over it.
We will definitely continue using Redis because: 1. It is free and open source. 2. We already use it in so many applications, it will be hard for us to let go. 3. There isn't another competitive product that we know of that gives a better performance. 4. We never had any major issues with Redis, so no point turning our backs.
RabbitMQ is very usable if you are a programmer or DevOps engineer. You can setup and configure a messaging system without any programmatic knowledge either through an admin console plugin or through a command-line interface. It's very easy to spin up additional consumers when volume is heavy and it's very easy to manage those consumers either through automated scripting or through their admin console. Because it's language agnostic it integrates with any system supporting AMQP.
It is quite simple to set up for the purpose of managing user sessions in the backend. It can be easily integrated with other products or technologies, such as Spring in Java. If you need to actually display the data stored in Redis in your application this is a bit difficult to understand initially but is possible.
RabbitMQ is more software than service so there's no real customer service to speak of unless you go with a provider such as CloudAMQP. So I'll just speak on CloudAMQP. Their customer support is only okay: they only do it over email. They frequently gloss over our support tickets and half answer them without delving deeply or investigating our issues. Their response times are pretty reasonable though.
The support team has always been excellent in handling our mostly questions, rarely problems. They are responsive, find the solution and get us moving forward again. I have never had to escalate a case with them. They have always solved our problems in a very timely manner. I highly commend the support team.
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
We are big users of MySQL and PostgreSQL. We were looking at replacing our aging web page caching technology and found that we could do it in SQL, but there was a NoSQL movement happening at the time. We dabbled a bit in the NoSQL scene just to get an idea of what it was about and whether it was for us. We tried a bunch, but I can only seem to remember Mongo and Couch. Mongo had big issues early on that drove us to Redis and we couldn't quite figure out how to deploy couch.
Earlier we had a problem with missing work items with our own implementation but later using RabbitMQ is solved a problem. Now our job processing mechanism is highly reliable.
We also had a problem with scaling, processing 1k work items per second. RabbitMQ helped us to scale well with increasing work items.
Redis has helped us increase our throughput and server data to a growing amount of traffic while keeping our app fast. We couldn't have grown without the ability to easily cache data that Redis provides.
Redis has helped us decrease the load on our database. By being able to scale up and cache important data, we reduce the load on our database reducing costs and infra issues.
Running a Redis node on something like AWS can be costly, but it is often a requirement for scaling a company. If you need data quickly and your business is already a positive ROI, Redis is worth the investment.
