IBM Cloud Databases for Redis Reviews

My main use cases for IBM Cloud Databases for Redis are caching and performance optimization. I use it to store frequently accessed data such as API responses and database query results, which helps reduce latency and improve overall application speed. I also use it for session management in the distributed system, where maintaining fast and reliable access to user session data is critical. In some cases, I have also used it for rate limiting and handling real-time data scenarios.

One of my projects where I use IBM Cloud Databases for Redis is an e-commerce backend system to improve product catalog performance. Whenever a user requests product details in the application, we first check IBM Cloud Databases for Redis for cached data using a product ID. If the data is available, it is returned instantly, reducing the database load and response time. If not, the system fetches the data from the primary database, returns it to the user, and then stores it in IBM Cloud Databases for Redis with TTL. This significantly reduces database queries during high-traffic periods, improves response time, and helps handle spikes in user requests more efficiently.

I have also used IBM Cloud Databases for Redis for several other important scenarios. One interesting use case was implementing rate limiting for APIs by storing request counts per user or IP address in IBM Cloud Databases for Redis with an expiry. We were able to efficiently control traffic and prevent data abuse and additional load on the main database. I also used it for handling background jobs and lightweight queries, where it helped sort live tasks with high output. Another useful pattern involves using it for temporary data storage such as OTPs or short-lived tokens, where fast read and write with automated expiration made it very effective. Overall, its speed, simplicity, and managed nature on IBM Cloud make it a reliable component in building a scalable and responsive backend system.

In terms of the best features of IBM Cloud Databases for Redis, one thing I really appreciate is that it combines the speed of Redis with enterprise-grade cloud features. The standout features for me include IBM handling infrastructure backup, patching, and monitoring. This allows developers to focus purely on application logic instead of operational overhead. Since Redis is an in-memory data store, it delivers millisecond-level response times, which are critical for caching and real-time usage. One feature that stands out is the ability to scale RAM and disk independently, which gives flexibility to optimize cost and performance based on the workload. It is also fully compatible with the standard Redis API and client, making migration of existing applications or integration of new ones very easy.

Using IBM Cloud Databases for Redis has a clear positive impact on my system performance and overall efficiency. One of the biggest improvements is reduced response time. By caching frequently accessed data, we bring down API response times from hundreds of milliseconds to just a few milliseconds in many cases. It also significantly reduces the load on our primary databases, specifically during peak traffic, helping improve system stability and prevent bottlenecks. From a scalability perspective, it allows us to handle sudden traffic spikes smoothly without major architectural changes, which is critical for user-facing applications. Operationally, since it is a managed service, it reduces the time spent on maintenance tasks such as setup and monitoring, allowing the team to focus more on building rather than managing infrastructure.

While my overall experience with IBM Cloud Databases for Redis has been positive, there are a few areas it could improve. One challenge is pricing transparency and cost predictability. While the flexibility in scaling is great, it can sometimes be difficult to estimate costs upfront, especially for dynamic workloads. Another area is limited low-level configuration control compared to self-managed Redis. Since it is a managed service, certain advanced tuning options or configurations are restricted, which can be limiting for very specific use cases. I have also noticed that scaling operations can take time, depending on the changes, which may not be ideal during sudden traffic spikes.

One area that could be further improved in IBM Cloud Databases for Redis is documentation and the onboarding experience. While the documentation is generally helpful, it can sometimes lack deep real-world examples or best practices for specific use cases including large scaling, caching strategies, eviction policies, or performance tuning. Having more practical guides would make it easier for developers to get started and optimize their setups. Another area is support responsiveness and depth. Basic support is good, but for more complex and performance-related issues, quicker access to more specialized experts would be beneficial. Additionally, improvements in monitoring and debugging tools, such as more detailed insights into cache hit or miss ratios, memory usage patterns, and latency breakdown, would help diagnose and optimize performance more effectively. Overall, enhancing documentation, advanced support, and available tools would make the platform even more robust and developer-friendly, especially for teams running mission-critical workloads.

I have been using IBM Cloud Databases for Redis for the last two years.

In my experience, IBM Cloud Databases for Redis is quite stable and reliable from an infrastructure standpoint. It maintains high availability and redundancy, offering a 99.99% uptime SLA and automatic failover, reflecting the level of reliability expected from a production-grade managed service. Occasionally, we notice short-lived connections interrupted during maintenance or scaling events, but these are expected in managed systems and usually brief if the application is designed to retry the connection. Overall, I would say the platform is highly stable and production-ready, and I have been able to rely on it for critical caching and real-time workloads without major issues.

The scalability of IBM Cloud Databases for Redis is one of its biggest strengths in my experience. The platform supports both manual scaling and auto-scaling, which makes it very flexible depending on how predictable your workload is.

The ability to scale RAM and disk independently has really helped me in optimizing both performance and cost when using IBM Cloud Databases for Redis. One of my projects initially provisioned a high amount of RAM, assuming peak traffic conditions. However, after monitoring use cases, we realized that while memory consumption was moderate, the data set size was growing due to cached product data and session storage. Instead of over-provisioning everything, we increased the disk capacity while keeping the RAM at its optimal level, which helped us manage costs efficiently without impacting performance. During a seasonal traffic spike, we scaled up RAM temporarily to handle the increased cache hit and reduced latency under heavy load. Once the traffic normalized, we scaled it back down. This kind of independent scaling allowed us to avoid unnecessary costs from over-provisioning while handling traffic spikes smoothly and maintaining consistent low latency performance.

My experience with customer support for IBM Cloud Databases for Redis has been generally positive, specifically for standard use cases. For basic queries and setup-related issues, the support is quite responsive and helpful. The documentation and guidance tutorials also make it easier to resolve common issues without needing to reach out frequently.

Before moving to IBM Cloud Databases for Redis, we used a self-managed Redis setup hosted on virtual machines. While that worked initially, we faced challenges with system scaling due to operational overhead managing deployment, backup, failover, and monitoring complexities. Reliability became a major concern. We decided to switch to reduce this operational burden and improve reliability. After moving to IBM's cloud-managed service, we saw immediate benefits such as automated backups, patching, and easier and faster scaling, which improved scalability in our production environment.

My experience with pricing, setup costs, and licensing for IBM Cloud Databases for Redis has been generally positive, though there are a few considerations regarding the pricing model. The pricing is primarily consumption-based, meaning you pay for the resources you use, such as RAM, storage, CPU, and backups on an hourly basis. This is helpful because it allows flexibility, but it can also make costs a bit harder to predict for dynamic workloads. There are no significant setup costs since it is managed as a service, so you do not need to invest in infrastructure, hardware, or initial configuration. You can quickly provision a cluster and start using it almost immediately. In fact, IBM often provides free credits for new users, which help in initial testing or proof of concept. Overall, it is easy to get started with very low or no setup costs and has a flexible pay-as-you-go model. There is no licensing overhead, but we need to be more careful about monitoring costs and optimization.

In terms of ROI, we definitely see clear returns on our investment after adopting IBM Cloud Databases for Redis, both in performance and operational efficiency. From a performance ROI perspective, caching drastically reduces latency and improves throughput. In general, Redis-based caching can significantly increase application throughput and reduce latency by large margins since data is served from memory instead of disk. In our case, this translates to faster response times; as I mentioned earlier, response times dropped from around 200 to 300 milliseconds down to 20 to 30 milliseconds, which helps in better user experience and reduces drop-off. From an infrastructure cost perspective, we were able to reduce database load by 40 to 60%, which delayed the need for scaling expensive database instances and optimized compute usage, as fewer heavy queries executed repeatedly. From an operational ROI perspective, we saved roughly 30 to 40% of engineering time that would otherwise go into managing infrastructure, failovers, and performance tuning. In terms of team efficiency, instead of hiring additional DevOps or database specialists, the existing team handled scaling and performance improvements effectively since it is a managed service.

We observed measurable improvements after implementing IBM Cloud Databases for Redis. From a performance perspective, API response times improved significantly. For cached endpoints, we saw a reduction from around 200 to 300 milliseconds down to 20 to 30 milliseconds, which made the application much more responsive for users. In terms of database load, we were able to reduce read queries on our primary database by roughly 40 to 60%, specifically for frequently accessed data including product details and session information. On the cost side, the ability to scale resources independently helped us manage infrastructure usage. By tuning RAM and disk based on our actual needs, we estimate around 20 to 30% in cost savings compared to a fixed and overall provisioned setup. In terms of operational efficiency, using a managed service saved us a significant amount of time on tasks including setup, failover handling, backup, and monitoring. We largely automated these processes, which reduced maintenance effort by approximately 30 to 40%, allowing our team to focus more on development. Overall, these improvements had a direct impact on both system performance and team productivity.

My experience with pricing, setup costs, and licensing for IBM Cloud Databases for Redis has been generally positive, though there are a few considerations regarding the pricing model. The pricing is primarily consumption-based, meaning you pay for the resources you use, such as RAM, storage, CPU, and backups on an hourly basis. This is helpful because it allows flexibility, but it can also make costs a bit harder to predict for dynamic workloads. There are no significant setup costs since it is managed as a service, so you do not need to invest in infrastructure, hardware, or initial configuration. You can quickly provision a cluster and start using it almost immediately. In fact, IBM often provides free credits for new users, which help in initial testing or proof of concept. Overall, it is easy to get started with very low or no setup costs and has a flexible pay-as-you-go model. There is no licensing overhead, but we need to be more careful about monitoring costs and optimization.

Before finalizing IBM Cloud Databases for Redis, we evaluated a few other options, including Amazon ElastiCache for Redis and Azure Cache for Redis. All of those were solid solutions, specifically in performance and Redis compatibility. However, I chose IBM Cloud because it offers a simple managed experience for our use cases, better alignment with our existing infrastructure on IBM Cloud, and strong security and compliance features. It also allows easy provisioning and integration with other IBM services. Overall, when we compared alternatives technically, the decision came down to ecosystem fit and ease of management, as well as operational convenience.

One additional aspect that stands out to me is its operational simplicity combined with reliability. Features including automated backup and point-in-time recovery give confidence when working with critical data, as they reduce the risk of data loss and simplify disaster recovery. I also appreciate the built-in high availability and failover mechanisms, which ensure that the system remains stable even during node failures without requiring manual intervention. Another important factor is the seamless integration with the IBM Cloud ecosystem, including monitoring and security services, which makes it easier to manage everything in one place. Overall, what stands out is its balance of performance, reliability, and ease of use, making it a dependable choice for production-grade applications.

My advice to anyone considering IBM Cloud Databases for Redis is to focus on clear use cases and proper planning from the start. Ensure you are using Redis for the right scenarios including caching, session management, rate limiting, and real-time data handling; Redis delivers the most value when used to reduce database load and improve response time. Pay attention to data modeling and TTL strategies, as proper key design and expiration policies can significantly impact performance, memory usage, and cost efficiency. Actively monitor cache hit and miss ratios, memory usage, and scaling patterns; this helps fine-tune performance and avoid unnecessary costs, especially since it is a usage-based pricing model. Also, take advantage of managed features including automated backups, high availability, and scaling, but be aware of limited low-level controls. Plan accordingly if you require advanced customization. I recommend starting with a small setup or proof of concept and then gradually scaling up based on real use cases. This helps you better understand cost behavior and performance before fully moving into production. I rate this product at an overall level of 8 out of 10.

I have been using IBM Cloud Databases for Redis for the past three years.

My main use cases for IBM Cloud Databases for Redis are caching to improve application performance and reduce load on our primary database. I use it to store frequently accessed data such as user sessions, API responses, and configuration data. This helps us significantly reduce latency and provide a faster user experience.

One specific example of how I use IBM Cloud Databases for Redis for caching is in higher traffic applications. When a user requests product details, instead of querying the main database every time, my workflow operates as follows: the application first checks IBM Cloud Databases for Redis to see if product data is already cached. If it is available, we return the data instantly with low latency. If it is not available, we fetch the data from the primary database and return it to the user, then store it in IBM Cloud Databases for Redis for future requests. I also use a set of TTL values so the cache automatically refreshes after a certain period, ensuring the data stays up to date.

Apart from caching, I also leverage IBM Cloud Databases for Redis in several additional ways. One key use case is session storage, where I keep user session data in IBM Cloud Databases for Redis to ensure quick access and seamless user experience across requests. I also use it for rate limiting and throttling, especially for APIs to prevent abuse and maintain system stability during traffic spikes. Another important use is temporary data storage for asynchronous workflows, such as storing intermediate states or background job processing.

The fully managed nature of IBM Cloud Databases for Redis has had a significant impact on my team's productivity and reliability. Previously, managing infrastructure meant handling patching, backups, failover setup, and monitoring, which took a lot of engineering time. With IBM's managed service, all of that is handled for us. This allowed my team to focus more on building features rather than maintaining the system, and it has also reduced the risk of manual errors during operations. Deployments are faster, and scaling during peak loads is much smoother. From a performance standpoint, the ultra-low latency has directly improved our application experience. For example, in one of our workflows, fetching user session or cache data from IBM Cloud Databases for Redis happens in milliseconds compared to significantly higher latency from the primary databases.

IBM Cloud Databases for Redis has had a very positive impact on my organization across performance, scalability, and operational efficiency. From a performance standpoint, it has significantly reduced application latency, which directly improves user experience and responsiveness. In terms of scalability, it has allowed us to handle high traffic very seamlessly. Operationally, the fully managed aspect has reduced the burden on my engineering team, which is no longer spending time on maintenance tasks such as patching, backup, and failover management. This has contributed to better system reliability and uptime, thanks to the built-in high availability and failover support. Overall, it has helped build a faster, more scalable, and more reliable system, which has improved team efficiency and reduced operational overhead.

I have seen several measurable improvements after adopting IBM Cloud Databases for Redis. From a performance perspective, I observed around 60 to 80% reduction in average API latency for the endpoints that rely on cache data. Requests that typically take 150 to 200 milliseconds from the primary database now take under 20 to 50 milliseconds. This is a huge improvement. I also saw a significant drop in database load of around 40 to 50% fewer read queries hitting my primary database since a large portion of traffic is now served directly from IBM Cloud Databases for Redis. In terms of reliability, I experienced fewer performance-related incidents during peak traffic as IBM Cloud Databases for Redis helped absorb the spike efficiently. This contributed to more stable uptime and a smoother user experience. Infrastructure maintenance effort has also been reduced by roughly 30 to 40%. Overall, the improvement translated into faster response time, better scalability, and improved engineering productivity.

IBM Cloud Databases for Redis offers several powerful features that make it very effective for real-time and high-performance applications. One of the best features is its fully managed nature. IBM handles backup, patching, scaling, and monitoring, so I can focus purely on development instead of infrastructure management. Another key feature is ultra-low latency at high throughput. Since IBM Cloud Databases for Redis is an in-memory store, this allows us to achieve many milliseconds of response time, which is critical for caching and real-time use cases.

My experience with IBM Cloud Databases for Redis has been very positive overall, but there are a few areas I think it could be improved. One area is pricing transparency and cost optimization. While the service is powerful, it can become expensive at scale. More granular pricing control or better cost visibility tools would help teams optimize usage more efficiently. Another improvement would be in monitoring and observability. While basic metrics are available, having more advanced insights, customizable dashboards, and deeper performance analytics would make troubleshooting and optimization easier. I also believe the developer experience with the documentation could be improved.

I have been working for the past three years in my current field.

IBM Cloud Databases for Redis has been generally very stable and reliable, especially for production workloads.

IBM Cloud Databases for Redis is one of my biggest strengths in terms of scalability. It supports elastic scaling, which means I can scale resources such as RAM and storage independently based on my workload requirements. This flexibility helps me optimize both performance and cost as demand changes.

My experience with customer support has generally been positive. One of the key highlights is that the support team is very responsive and knowledgeable.

Before moving to IBM Cloud for IBM Cloud Databases for Redis, I was using a self-hosted IBM Cloud Databases for Redis setup, which was open-source IBM Cloud Databases for Redis deployed on virtual machines. While it worked initially, I started facing challenges as my system scaled, particularly around maintenance, failover management, and backup, ensuring high availability. Managing these aspects required significant engineering efforts and constant monitoring. I decided to switch to IBM Cloud managed IBM Cloud Databases for Redis service primarily to reduce operational overhead and improve reliability. The managed offering provides built-in high availability, automated backup, scaling, and monitoring, which eliminates a lot of manual work.

I have definitely seen a positive ROI from using IBM Cloud Databases for Redis. From a performance standpoint, faster response time improved user experience, which impacts user engagement and retention, especially with high traffic applications. As I mentioned earlier, it has reduced API latency by almost 30 to 40%, and on the cost side, even though there is service cost, it has helped in reducing load on my primary database, which in turn has lowered the scaling costs for those systems. I have also optimized my overall infrastructure spending and observed a positive ROI in terms of engineering productivity.

Before finalizing IBM Cloud Databases for Redis, I evaluated a few other options. I looked at Amazon ElastiCache for IBM Cloud Databases for Redis and Azure Cache for IBM Cloud Databases for Redis as they are well-established managed IBM Cloud Databases for Redis offerings with strong performance and scalability. I also considered continuing with the self-hosted setup, but that would have meant ongoing operational overhead for maintenance, scaling, and failover management. I ultimately chose IBM Cloud because it offered seamless integration with my existing cloud environment along with strong managed capabilities, reliability, and ease of use.

My advice for anyone considering IBM Cloud Databases for Redis would be to first clearly define your use case and workload requirements. If your application needs low latency access, caching, or real-time processing, it is a great fit and can deliver significant performance improvements. I also recommend planning your data strategy carefully. Decide what could be cached, set appropriate TTL values, and avoid loading IBM Cloud Databases for Redis with unnecessary data. Proper caching design will make a big difference in efficiency. Additionally, make sure to implement best practices such as connection pooling, retry mechanisms, and monitoring so your system remains stable under load. I would rate this product an 8 out of 10.

IBM Cloud Databases for Redis is a caching solution for our e-commerce company. The solution can be implemented on websites to reduce page loading time and improve website performance, which is why we purchased this solution.

IBM Cloud Databases for Redis is an in-memory database store solution. It can be used as object caching and for session persistence. If any e-commerce giant implements system design solutions on their website to improve user experience, IBM Cloud Databases for Redis is one segment of that solution.

There are many better solutions available in the market at no cost. Their solution is forked from Waki project. They forked the Redis software and have done far better than Redis.

This solution is not integrated into our website. They asked us to take technical support from a third-party company, which we paid for in addition to paying IBM Cloud Databases for Redis. After several months, it became apparent that there was a technical fault and the solution was not implementable.

IBM Cloud Databases for Redis promised support, guarantees, and solutions, but they did not deliver on any of these promises. Their solution is not implementable on our website. We paid money for something which is freely available in the market, and the paid version is not worth the cost. They also refused to cancel the agreement.

This solution later became open source, yet we are paying for something that is freely available.

I have been using the solution for about nine months.

Our e-commerce company runs 24/7 with 10 to 15 million requests coming from approximately 10 million users.

We have raised support tickets, but they did not provide any assistance. I also raised a support ticket with the AWS team. They do not have a competent technical team and provide minimal support.

Negative

Instead of purchasing IBM Cloud Databases for Redis, you can buy ElastiCache from AWS, which is also built on top of Redis.

They are simply selling false hope to customers, and their solution is neither feasible nor integratable.

The solution is very expensive. The pricing is very high while the quality is very poor.

I would not recommend this product to other users because they do not provide support and give false promises. They do not have any cancellation provision. Better products are available in the market, such as AWS services, which at least provide some level of support.

The solution is very complex and involves multiple vendors. While they claim their product is compatible with everything, when we try to integrate different products with IBM Cloud Databases for Redis, it is not integratable. They claimed compatibility with any website, application, or machine, but in reality, it is not compatible with any of these things.

On a scale of 1-10, this product receives a rating of 1.