Redis Cloud - Annual

What do you like best about the product?

I like Redis Software’s raw speed and how effortlessly it helps me solve concurrency headaches. Its lightweight, fast in-memory operations, including atomic INCR and EXPIRE commands, let me keep rate-limit counters accurate across nodes without race conditions or heavy database queries. The sub-millisecond speed and atomic counter and expiration updates make it straightforward to build reliable rate limiters, scale our API infrastructure, and reduce backend friction. Using Redis as a shared in-memory database keeps the counters in one place, and I also get caching benefits. I found setup very easy alongside Kong: its built-in Redis plugins meant I didn’t have to write custom middleware, and getting the Redis instance running and configured took little time.

What do you dislike about the product?

The biggest pain point for me with Redis Software in production is managing memory and eviction policies under heavy write loads. Since everything lives in RAM, I can hit memory limits faster than expected if my cache strategy isn’t tightly dialed in, and poorly configured eviction policies or TTLs can wipe out important rate-limiting counters or active session data. Persistence and state recovery also take some decision-making: I have to weigh the performance overhead of RDB snapshots against the data safety of AOF logs, and if persistence isn’t configured right, a crash can mean losing a few seconds of counter data and briefly skewing rate limits. Getting the setup production-ready took care with memory limits, eviction policies, and persistence settings.

What problems is the product solving and how is that benefiting you?

I use Redis Software as an in-memory database for rate limiting across cluster nodes. It keeps all the counters in one place, giving me 100% accurate counters instead of inaccurate locally stored ones, and provides caching benefits too.

What do you like best about the product?

Redis has been a strong addition to our stack at CargoX, mainly used for caching and session management alongside our Express.js backend. The interface and tooling around it are simple and don't require much overhead to manage day-to-day. It integrates cleanly with our existing Node.js and Express setup, requiring minimal configuration to get caching layers working effectively. Performance has been excellent, with noticeably faster response times for frequently accessed data and reduced load on our primary database. Being open-source with a strong free tier makes the ROI very favorable, especially since we haven't needed enterprise features to get significant value. Documentation and community resources are extensive, so onboarding new developers into using Redis within our stack has been quick without needing formal support. There's no built-in AI or intelligence layer, but for a caching and data store tool, that hasn't been a limitation for our use case.

What do you dislike about the product?

The command-line interface, while powerful, isn't the most beginner-friendly, so newer team members needed some ramp-up time before getting comfortable with Redis-specific commands and data structures. Integrating persistence configurations properly took some trial and error to avoid data loss risks in edge cases, since the default settings prioritize speed over durability. Performance is excellent for in-memory operations, but memory usage can grow quickly if key expiration and eviction policies aren't managed carefully, which requires ongoing attention as data volume scales. Pricing for Redis Enterprise or managed cloud offerings can get expensive if you outgrow the free, self-hosted setup, and support for the open-source version relies entirely on community resources rather than dedicated channels. There's also no AI-driven optimization for cache eviction or memory management, so tuning performance still depends on manual configuration and experience rather than any intelligent automation.

What problems is the product solving and how is that benefiting you?

Redis has significantly reduced load on our primary database by handling caching and session management for frequently accessed data across our Express.js backend. This has improved response times for our platform without requiring expensive infrastructure upgrades, since Redis's in-memory performance handles high-frequency reads efficiently. Being open-source and free to self-host has kept costs low while still delivering enterprise-level performance benefits, and the straightforward integration with our existing Node.js stack meant we didn't need to restructure our architecture to take advantage of it.

What do you like best about the product?

What I like most about Redis is its exceptional performance and simplicity. It's incredibly fast for caching, session storage, queues, and temporary data management.

What do you dislike about the product?

Memory management and debugging issues are hard to manage.

What problems is the product solving and how is that benefiting you?

Redis helps us solve performance and scalability challenges in our teleassistance platform. We use it for caching, asynchronous message processing, and temporary data storage to ensure that alarms, notifications, and background tasks are handled quickly and reliably.

Redis is used primarily as a caching layer to provide a high-performance caching solution that improves application response times and reduces load on backend services and databases. We use it mainly to store frequently accessed data and temporary session information and short-lived application state where low-latency access is important. It also helps with scenarios such as rate limiting, distributed caching across multiple application instances, and improving scalability for APIs that experience frequent reads.

One example of how I use Redis in my applications is using it as a caching layer for frequently accessed application data instead of querying the database every time an API request comes in. We cache commonly requested data in Redis with an appropriate expiration period. For example, in one of our APIs, frequently accessed user or configuration data is stored in Redis after the first request, so subsequent requests can retrieve the data directly from Redis, which significantly reduces database load and improves API response times, especially during periods of high traffic. Redis has also been useful for distributed scenarios where multiple application instances need to share temporary state, ensuring consistent behavior when workloads scale horizontally.

Beyond caching, Redis has become useful as a supporting component for improving application scalability and reliability. It helps us reduce unnecessary database operations, improve response times, and provide a consistent, low-latency data access layer for frequently used information. Another benefit is its flexibility for handling temporary data, such as session-related information, rate limiting, and short-lived application state, where using a traditional database would add unnecessary overhead. Overall, Redis helps us design more efficient applications by improving performance while allowing our backend services to scale more effectively.

Caching is the best feature that Redis offers. The most valuable features include high-speed in-memory data access, flexible data structures, caching capabilities, data expiration and time-to-live management, high availability and scalability, and atomic operations. These are the biggest use cases that I find in a low-latency tool like Redis.

The features of high-speed in-memory data access and flexible data structures are very impactful in my work. We have been using them throughout to help cache frequently accessed data, which reduces the number of database calls and improves API response times, especially for high-traffic scenarios. Redis has also simplified scaling because multiple application instances can share the same cached data instead of each instance maintaining its own state. This makes deployments more reliable and helps the team focus on business features rather than performance optimization issues. Overall, Redis has helped us build faster, more scalable applications.

Making management easier, especially for teams operating large Redis clusters, would be helpful. More advanced built-in observability, performance insights, and automated recommendations would help teams identify bottlenecks and optimize usage more easily. Improved tooling around configuration management like scaling and cost optimization would also be valuable, particularly for cloud deployments where teams need better visibility into resource usage. Additionally, making security features and enterprise governance capabilities easier to configure out of the box would help organizations adopt Redis more confidently for larger and more critical workloads.

One additional area where Redis could continue to improve is simplifying operational management for teams running larger-scale deployments. Features around automated tuning, capacity planning, cost optimization, and proactive recommendations would help teams get more value with less manual effort. Additionally, expanding integrations and providing more guided best practices for common architectures would make it easier for teams to adopt Redis effectively. Overall, Redis is already a strong platform, and these improvements would mainly enhance usability, automation, and enterprise-scale management.

I have been using Redis for the past couple of years.

Redis is very stable, and we have not really encountered any issues with its stability because we have not experienced any major downtime or reliability issues that have impacted our applications. Redis has consistently provided fast and predictable performance, particularly for caching and high-frequency data access scenarios. Its mature ecosystem, strong community support, and features such as replication, persistence, and clustering provide confidence when using it in production environments.

Redis's scalability was another reason why we chose it. It has scaled well for our needs and has been able to support growing application workloads effectively. The in-memory architecture provides consistently low-latency access even as data access patterns and request volume increase. As our requirements grow, areas like capacity planning, monitoring, and automated scaling become increasingly important, but overall, Redis provides a strong foundation for building scalable applications.

We did not encounter anything with their customer support because we have not fallen into situations where we had to contact them. By simply referring to their documentation, we have been able to fix our bugs and general issues. In that instance, their documentation is so good that we do not really have to reach out to their customer support.

Before using Redis, we relied more on application-level caching and database approaches for managing frequently accessed data. As our applications and workloads grew, those approaches became less efficient and harder to scale. The main reason we moved to Redis is that it provides a dedicated, high-performance caching layer with low-latency access, built-in expiration management, and support for distributed scenarios. It simplified our architecture by providing a reliable solution for caching, temporary data storage, and shared application status across multiple instances. The main reason for switching was improved performance, reduced database load, better scalability, and easier management of cached data.

Our experience with Redis's pricing, setup cost, and licensing has been positive overall. The setup process was straightforward, and integrating Redis into our existing application architecture did not require significant additional infrastructure changes. The licensing options provide flexibility depending on the deployment model and scale requirements. The main value comes from the performance improvements, reduced database load, and increased scalability that Redis provides. From a cost perspective, the investment is justified by the operational benefits, including improved application responsiveness and reduced efforts spent managing performance issues.

By introducing Redis as a caching layer for frequently accessed data, we reduce repeated database queries and improve response time for high-read APIs. This allowed our system to handle higher traffic more efficiently without requiring equivalent increases in database capacity. We have seen a positive return on investment from using Redis, mainly through improved application performance, reduced database load, and lower operational overhead. Although we have not measured a direct reduction in headcount or specific dollar saving, the productivity and scalability benefits have been valuable.

Our experience with Redis's pricing, setup cost, and licensing has been positive overall. The setup process was straightforward, and integrating Redis into our existing application architecture did not require significant additional infrastructure changes. The licensing options provide flexibility depending on the deployment model and scale requirements. The main value comes from the performance improvements, reduced database load, and increased scalability that Redis provides. From a cost perspective, the investment is justified by the operational benefits, including improved application responsiveness and reduced efforts spent managing performance issues.

Our team evaluated multiple options before choosing Redis, including Memcached, normal database caching, and cloud-native caching solutions such as AWS ElastiCache. The main factors we considered were performance, scalability, reliability, ease of integration, supported data structure, and operational simplicity. Redis stood out because it provides more than just simple caching features, such as multiple data structures, time-to-live management, atomic operations, persistence options, and support for distributed workloads, which made it a more flexible solution for our application needs. Overall, Redis provided the right balance of performance, flexibility, and ecosystem support compared to the other options we evaluated, such as Memcached and AWS ElastiCache.

There are a couple of things to consider when using Redis. It is a supporting layer, not a main database. Identifying specific use cases where Redis can provide the most value, such as caching, session management, rate limiting, real-time data processing, or reducing database load, is crucial. Redis is very powerful, but it should be used with a clear caching and data management strategy rather than as a replacement for every data store. For production workloads, I recommend setting up proper monitoring, security controls, high availability, and capacity planning from the beginning.

Redis is a great caching tool, and anyone can try it or at least see whether it fits their organization. It fits our organization, so it might definitely fit for somebody else as well with the features that have been provided. I suggest trying it out to see whether it is the right solution for your needs. If it fits you, then you are good to go. I would rate this product nine out of ten.

Hybrid Cloud

Amazon Web Services (AWS)