Redis Reviews

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.

I use Redis mostly to cache repeated data that is required. If I'm using a user wallet address, I don't need to call it all the time from the database. I do the cache using the solution.

The solution allows you to create a message of application publishing and messaging the application in other services. It helps a lot when I work with the microservice architecture.

I have been using Redis for four years.

I haven’t faced any stability issues with the solution.

I have never faced any issues with the solution’s scalability.

The solution is easy to set up and has very clear documentation.

To deploy Redis, you need knowledge about JavaScript, programming, and how data structures are stored. It takes around five to ten minutes to deploy the solution.

With Redis, I can create lists and key-value pairs. The solution also provides many features for storing data in cache. Storing data in memory using Redis is faster than using traditional databases like Postgres or MySQL.

If you are communicating with the services, you can use the solution's Pub/Sub capabilities to send messages, store data in cache, and share it with other microservices. The solution's data persistence model has greatly benefited our resilience, especially when storing any key-value pair.

You can install the solution on the local machine or cloud servers like AWS or Google Cloud. I would recommend Redis to other users.

Overall, I rate the solution a nine 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. 

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. 

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.