Redis Reviews

I use Redis as a cache to store user sessions with login details and also some current status of the devices.

The performance of Redis is very fast. Its deployment is pretty easy when using it on ElasticCache, and I did not need to worry about scalability on AWS. It's pretty scalable and stable.

For the PubSub feature, we had to create our own tools to monitor the events.

I have been using Redis for about six years.

The ElasticCache is pretty stable.

I did not need to worry about it on AWS, so it's pretty scalable.

I have never contacted the Redis support team.

I would probably advise learning how to use command-line tools.

I'd rate the solution eight out of ten.

I use Redis as a tool in building projects, specifically for in-memory caching. My backend API uses Redis to cache information retrieved from the database.

Redis acts as an in-memory search tool that improves the speed of operations. By making operations faster, Redis allows for quicker data retrieval and enhances the performance of applications.

Redis could be improved by introducing a GUI to display key-value pair database information, as it is currently a CLI tool with no visual representation. 

Additionally, better documentation is needed to set up a secure Redis server with user authentication, as there are gaps and issues in this area.

I have been using Redis for two to three projects recently, with a total experience of about five to six years.

Redis is quite mature and stable, and I haven't encountered any stability issues.

Redis does not require scaling. It can be a central in-memory store for all scalable units of an application, and it is not necessary to have a duplicate copy of Redis.

The setup is quite easy; I would rate it as eight out of ten. However, there might be some difficulties related to secure servers.

Redis is a free tool available for on-premises installations. There's no cost associated with it as I haven't used any cloud services.

Redis is a nice choice for building applications that require high turnaround times for user requests. It reduces turnaround time by building a cache solution based on Redis. 

I rate it as eight out of ten.

I use the solution for saving user sessions and user data for different applications.

The online interface is very fast and easy to use.

There is a lack of documentation on the scalability of the solution. 

The product should create awareness about its scalability.

I have been using the solution for five years.

The solution is very stable.

The product is very scalable.

The initial setup is easy.

The deployment could take one to two weeks.

People using the solution should be aware of all the features of the solution. Overall, I rate the solution a ten out of ten.

It was a classic caching use case. In my previous company, we were running MongoDB on the cloud, and we were running Redis for caching. We were just starting, so the data size was pretty small there.

We were caching the data, and it was helpful in terms of speed. It uses the key-value method for storing the data, and everything lives in memory, so it helps with the speed. Solutions such as Redis, or Memcached, are helpful for fast access.

The in-memory data makes it fast.

I would prefer it if there was more information available about Redis. That would make it easier for new beginners. Currently, there is a lack of resources. I believe as the Redis ecosystem grows, over time, there will be more adoption, and its community will grow. There will be more resources available for support and questions.

In terms of features, they are doing a good job and coming up with many new features, such as Redis Search. They have also introduced a new cloud service. However, I haven't used it much, and I'm not that familiar with the Redis ecosystem, so I don't have input on the features they need to build or improve.

I'd rate it an eight out of ten because it did what I needed, and it did a good job. However, currently, not every product in the Redis ecosystem has a great community or great support.

The main use case for Redis is caching. Caching is the primary purpose of using Redis for my organization, as I use it to cache frequently accessed data to improve application performance and reduce database load, functioning as a caching service for database optimization. For example, when a user requests their personalized dashboard, the application first checks Redis for the cached dashboard. If it is available, the response is returned immediately. If not, the application retrieves the data from the database, stores it in Redis with a short expiration time of five to ten minutes, and then returns it to the user. This significantly reduces database queries and improves response times.

I also use Redis for session management and short-lived application state. For example, during an AI chat session, Redis stores conversation context, rate-limiting counters, or temporary workflow state, which can be accessed quickly without repeatedly querying the primary database.

Redis has many good features that I find useful. The general caching use case is the most important, along with high performance, rich data structures, persistence options, easy integration, and good scalability. What I appreciate most is its speed and ease of use. In practice, Redis dramatically reduces database load by serving frequently accessed data from memory, and features like automatic key expiration, known as TTL, along with persistence options, make it reliable for production applications while remaining simple to work with.

Speed makes the biggest difference in reducing response times in my projects. In one project, the application displays a user dashboard that requires several database queries to gather profile information, preferences, and recent activity. Instead of executing those queries on every request, I cache the assembled dashboard data in Redis. As a result, repeat requests are served directly from memory, making the dashboard load almost instantly while significantly reducing the load on the database. Regarding the TTL feature, it is especially useful because it keeps cached data fresh automatically. For example, I cache product listings and search results with a TTL of around five to ten minutes. If a user requests the same data within that period, Redis returns it immediately. Once the TTL expires, Redis automatically removes the cache entry, and the next request regenerates the data from the database. This gives me a good balance between performance and data freshness without needing custom cache cleanup logic, which would need to be done manually and might feel much more tedious and difficult. Redis handles it very effectively.

Using Redis has positively impacted my organization, especially regarding performance because most data is fetched very quickly without having to execute numerous database queries in the first place. Redis has had a positive impact by improving application performance, reducing database load, and making the system more scalable. By caching frequently accessed data, I am able to serve requests much faster, which improves the overall user experience. After introducing Redis for caching dashboard and search data, users experience noticeably faster page loads on repeat requests. The database handles fewer read operations, which improves overall system responsiveness and provides more headroom during peak usage. Redis has helped me avoid unnecessary repeated database queries for pages that users have visited previously.

I have faced a few challenges and limitations with Redis. Although it is extremely powerful, there are challenges and areas for improvement depending on the use case. The first challenge is memory limitations, as Redis is primarily in-memory, making memory usage a key constraint. If the data grows too large or eviction policies are not tuned properly, important cache data can be removed unexpectedly. The second challenge is scaling complexity; scaling Redis horizontally, such as in cluster mode, introduces operational complexity. Additionally, I would mention the persistence trade-offs; Redis supports persistence like RDB, but it is not as robust as traditional databases for long-term storage, which creates a trade-off between performance and durability. In most systems, Redis is not used as the primary data store.

I have been using Redis for more than one year as a caching service.

Redis is very stable in my experience because I have not encountered any issues. It performs its function perfectly. Redis has been very stable from an infrastructure perspective, especially when used in managed services or properly configured clusters. However, its state is not treated as a traditional durable database, so stability depends on how I design persistence and eviction strategies. Overall, Redis is very stable, but its state is intentionally changing. As long as I use it for caching, sessions, or transient data and not as a system of record, it behaves reliably and predictably in production.

Redis is easy to scale and also easy to integrate. Redis scales very effectively for read-heavy and caching workloads, especially when properly designed. However, scalability depends heavily on whether I am using single-node, replication, or cluster mode, as it behaves differently in those contexts. According to my experience, it is highly scalable for caching and real-time workloads.

I have not had the chance to interact with customer support because there have not been any problems requiring it. I mostly rely on Redis documentation and community support rather than direct vendor support, especially when using the open-source version or managed cloud services, because its documentation is well-documented.

Before Redis, my team tested a couple of different solutions. The main driver for switching to Redis was scalability and performance. Local caching helped somewhat, but it did not work effectively in distributed systems. Redis gave me a centralized, fast, and reliable caching layer that significantly improved system performance and consistency. Initially, my team typically relied on direct database queries and sometimes in-memory caching at the application level, using simple hash maps or local caches such as Caffeine or Guava in Java applications. The higher database load during peak traffic is why I shifted to Redis in the first place.

Regarding my experience with pricing, setup cost, and licensing for Redis, pricing and setup cost are handled by a particular team, but I have some knowledge. Redis is open source at its core, so there is no traditional licensing cost for the basic Redis engine itself. There is no licensing cost because the open-source version is free to use. When it comes to setup cost, it is relatively low, especially when using managed services. Since I self-host it, costs come from infrastructure. Additional efforts for high availability setup, monitoring, backup configuration, and higher DevOps overhead would be management costs. Pricing mainly depends on memory size, throughput, and availability configuration.

I have not seen a direct ROI concerning fewer employees needed because caching does not mean that I can reduce the number of employees. I did not track a direct monetary ROI in exact figures, but I observed a clear operational and performance-based return that indirectly translated into cost savings and efficiency gains. By caching frequently accessed data in Redis, I significantly reduced the number of database queries, resulting in savings concerning infrastructure costs. This is an indirect ROI. Redis improved system scalability, allowing me to handle higher traffic without proportional infrastructure growth, which creates scalability ROI. Although I did not measure ROI in exact dollar terms, the combined effect of reduced database load, improved performance, and lower operational overhead clearly translated into cost efficiency and better scalability. If I had to scale without Redis, infrastructure costs and engineering effort would have been significantly higher.

I considered a couple of options before choosing Redis. I looked at a few alternative approaches depending on the use case, mainly in-memory caching. For in-memory caching inside the application, I used Caffeine or Guava as local caches. I initially considered local in-memory caching in the application. It was not sufficient due to cache inconsistency, data loss on restart, and difficulty in horizontal scaling. This is the main reason why I shifted to Redis.

If somebody is looking to use Redis, it is much easier and more scalable for making most database queries faster, especially for repeated pages while fetching data. It helps tremendously in handling multiple queries and fetching in a cluster system or in complex systems. My suggestion is that if somebody is looking for a platform to cache or render repeated queries efficiently, Redis is the proper tool.

Redis is a great tool. It is a good caching tool and a supporting layer, not a tool that I can use as a direct database. Although I could, there are better options for that. Redis is made for a particular reason, specifically for caching purposes. If I am using it for that particular use case, then I will benefit the most. I give this review a rating of eight out of ten.

We use Redis for caching and to improve the speed of the database. 

The product offers fast access to my database. 

I have been working with the product since 2022. 

Since implementing the product, we have experienced stability in our applications.

The solution is scalable. 

The initial setup took some time as our technical team needed to familiarize themselves with Redis. Once they gained expertise, the deployment process became straightforward and was completed within a month and a half. A seven-member team helped with the deployment. 

Redis is an open-source product. 

I rate the product an eight out of ten. 

In the past, I used Redis as a cache, and currently, I'm using it as a messaging system.

Redis is pretty fast compared to others, making it a reliable choice. It's much more reliable and helps with our message broker functionalities.

Redis is a single thread, which is one of the key features I like. Redis is also pretty fast, and many of our use cases are satisfied with its single-threaded nature. This feature helps us manage concurrency effectively.

I don't think there's any room for improvement as it's been good for large-scale use and large datasets.

I have been using Redis for almost three years now.

I haven't faced any issues from a performance, outage, or availability point of view. It's good.

It's very easy to scale up and scale down. I'd say it's highly scalable.

I didn't get a chance to interact with their support team.

Positive

Use Redis wisely because it is a single-threaded tool. There was an issue we faced in the past where a query was not optimized, which impacted performance significantly.

I've used Redis mainly to improve application performance through caching. I've also used it as a small project broker and an external lock mechanism. I used it in previous companies. 

What I like best about Redis is its fast and easy use. It has interesting algorithms like HyperLogLog and provides useful features. It's also good for implementing scalable rate limiting.

I have been using the solution for eight years. 

I haven't faced any stability issues. 

I rate the tool's scalability an eight out of ten. 

Redis is an open-source solution. 

I rate the overall solution a ten out of ten.