Redis Reviews

I have used Redis for around four years. I have completed several projects using Redis. At Paytm, I used it for caching and performance optimization, and then I used it at MakeMyTrip for a multi-layer caching architecture.

At MakeMyTrip, I am using Redis for a multi-layer caching architecture. In one of my recent projects, I used Redis as a distributed L2 cache for storing frequently accessed data and reducing downstream service calls, which significantly improves latency and system throughput. In a hotel cancellation policy system, I aggregate data from several microservices including inventory, partner system, and internal policy service. These calls are expensive and add latency. I cache the final computed policy response in Redis with a TTL of around five minutes.

For the five-minute TTL for the cache, the decision was based on balancing data freshness and performance. The cancellation policy does not change very frequently, but when it does, it must reflect responsively and quickly. I analyzed the update frequency versus the request volume, and five minutes provided a good trade-off. Most reads can be served from cache while keeping the data sufficiently fresh. I complemented the TTL with event-driven invalidation for critical updates. In cases where policy changes, I do not have to wait for the TTL to expire.

Apart from caching, I have completed several other use cases of Redis at MakeMyTrip. One was rate limiting, where I use Redis to control traffic at a per-user or per-partner level to protect downstream services. I leverage Redis fast atomic operations to maintain counters and enforce limits without adding latency. I also use Redis for temporary state management, especially in scenarios where I need to store short-lived intermediate data between multi-step flows. I use Redis as an in-memory solution and it is very fast. Another aspect I focus on is cache design and observability to ensure proper key structuring, monitor cache hit-miss ratios, and tune TTL based on traffic patterns. This helps me continuously optimize performance and avoid issues such as stale data or cache stampede.

A few features of Redis that I use on a day-to-day basis and feel are among the best are extremely low latency and high throughput. Since Redis is in-memory, it makes it ideal for cases such as caching and rate limiting where response time is critical. TTL expiry support is very useful in Redis as it allows me to automatically evict stale data without manual cleanup, which is something I use heavily in my caching strategy. Another point I can mention is that the rich data structures such as strings, hashes, and even sorted sets are very powerful. I have used strings for caching responses and counters, whereas I have used hashes for storing structured objects. One more feature I can tell you about is atomic operations. Redis guarantees atomicity for operations such as incrementing a counter, which is very useful for rate limiting and avoiding race conditions in distributed systems. Finally, I want to emphasize that Redis is easy to scale and integrate, whether through clustering or using a distributed cache across microservices.

Redis has impacted my organization positively by providing default support that is very useful. For metrics, in one of my core systems, introducing Redis as a distributed cache helped me achieve around an 80% cache hit rate, which reduced repeated downstream services. Real API latency also improved from around two seconds to approximately 450 milliseconds for P99. It also helped reduce the load on dependent services and databases, which improved overall system reliability.

There are some points where I feel Redis can be improved. One issue is cache invalidation. Keeping cache data consistent with the source of truth can be tricky, especially in distributed systems. I address this using a combination of TTL-based expiry and event-driven invalidation, but it still requires careful design. Another point I want to add is memory management. Since Redis is in-memory, storing large and improperly structured data can quickly increase memory usage and costs. I had to optimize key design, data size, and eviction policies such as LRU to manage it effectively.

I have been working in my current field for around four and a half years.

In my experience, Redis is highly stable.

Redis scalability in my environment is quite good. It is highly scalable. I scale Redis horizontally using clustering and sharding, where data is distributed across multiple nodes to handle higher traffic and larger data sets. This helps avoid bottlenecks and ensures consistent performance even as load increases. I use replica nodes to handle read traffic and improve availability. For high throughput scenarios, this allows me to offload reads from the primary node and maintain low latency.

Regarding customer support, I have not directly engaged with Redis customer support very often, mainly because I use it as a managed service and most operational issues are handled internally by my infrastructure team. From an application perspective, Redis has proven to be quite stable and predictable. Most issues I encounter, such as cache misses or memory pressure, I handle through monitoring, tuning, and design improvements. The documentation and community support for Redis are very strong, making troubleshooting quicker. For deeper infrastructure-level issues, my platform team typically coordinates with cloud provider support.

Before Redis, I primarily relied on direct database queries and some in-memory caching solutions such as Guava. The main issue was that this approach increased latency and added higher loads on downstream services and databases, especially for frequently accessed or aggregated data. In some cases, repeated calls to multiple microservices made APIs slow and less reliable during peak traffic. Switching to Redis solved these issues effectively.

The return on investment with Redis is clearly evident. For example, from a system perspective, Redis helped me achieve around an 80% cache hit rate, which reduces repeated downstream calls, as I mentioned earlier. It improved API latency from two seconds to 450 milliseconds for P99. From a productivity standpoint, it significantly reduced manual troubleshooting and performance firefighting. Many latency and load issues were absorbed by the caching layer, and in some workflows, automation and caching together reduced manual intervention by about 60 to 80%. This allowed my team to focus on building features instead of handling operational issues.

I have not been directly involved in the pricing aspect, but I have seen that the costs are primarily driven by memory consumption and cluster size, since Redis operates in-memory. Because of that, I am quite careful about optimizing data size and choosing appropriate TTLs to avoid unnecessary cache bloat. I was not directly involved in pricing decisions, but I did contribute to cost efficiency through better cache design and memory optimization.

I had a few options to consider before choosing Redis, but one option was to rely more on database-level optimizations such as indexing or query tuning, which did not solve the problems related to repeated reads and high latency. In-memory caches such as Guava worked well locally but do not scale across multiple instances since they are not sharded. As for distributed caching, I also considered Memcached. However, Redis stood out because of its richer data structures, built-in TTL support, atomic operations, and better flexibility for use cases such as rate limiting and structured caching.

My advice for others looking into using Redis is to design caching carefully. Focus on good key data structures, appropriate TTLs, and a clear invalidation strategy because cache consistency is often the biggest challenge I face in Redis. Be mindful of memory use since Redis is in-memory, and optimize data size and eviction policies accordingly.

I have shared most of my experience with Redis previously. Overall, I want to say that Redis truly adds value, especially for low latency and high throughput use cases. Redis is extremely powerful, but to realize its full potential, it requires careful design around data and traffic patterns. I would rate this review an 8.

One specific example from my backend services is using Redis to cache frequently accessed data like product details. Instead of querying the database every time, the application first checks Redis. If data is present, it returns instantly, which significantly reduces the database load and improves response time.

Apart from cache, I have also used Redis for session storage and rate limiting. It helps in managing user sessions efficiently and controlling traffic spikes, which improves overall system reliability.

Redis has played a key role in improving system scalability and performance. By offloading frequent reads from the database and enabling fast in-memory cache access, it reduced latency, improved throughput, and helped maintain stability during peak loads.

One practical challenge I experienced is managing memory efficiently. Since Redis is in-memory, we need to carefully configure eviction policies and monitor usage. Debugging cache-related issues such as stale data or cache invalidation can sometimes be tricky. Additionally, tuning memory usage and eviction policies needs to be planned very carefully.

Before Redis, we relied on the normal database, but before we considered Redis, we looked at a few alternatives such as Memcached. Redis stood out because of its richer data structures and additional features such as persistence and pub/sub features.

My advice would be to first clearly define your use cases, specifically for caching or real-time scenarios, and also pay attention to memory management. Choose the right eviction policies and implement proper monitoring from the beginning. Plan for memory optimization, set appropriate TTLs, and implement strong monitoring and alerting for stability at any scale.

Redis is a powerful and reliable tool for improving application performance. Its speed and flexibility make it a great choice for modern backend systems. It significantly improves performance and scalability with proper planning. It works very effectively for high-traffic applications. I would rate this product an 8 out of 10.

My main use case for Redis is caching frequently accessed data to improve performance and reduce database load. For example, I cache API responses and user-related data so that repeated requests can be served quickly without hitting the database every time. I use TTL to automatically expire stale data and ensure caching freshness. In some cases, I also use Redis for session management and handling short-lived data efficiently.

I have used Redis for session management in a back-end system, where the main idea was to store user session data in Redis instead of keeping it in memory on a single server, which helps me scale across multiple instances. When a user logs in, we generate a session ID or token and store session-related data like user ID and metadata in Redis, and this session is associated with a TTL. It automatically expires after a certain period of time or after a certain time of inactivity. On each request, the session ID is validated by fetching data from Redis, which is very fast due to its in-memory nature, ensuring low latency and allowing us to handle the highest traffic efficiently. This approach helps us achieve horizontal scalability and avoids issues concerning session stickiness. Additionally, we ensure security by expiring inactive sessions or occasionally refreshing TTL for active users.

Apart from caching and session management, I worked on interesting challenges using Redis, particularly around caching consistency and handling stale data. Initially, we faced issues where cached data would become outdated after database updates, and to solve this, we implemented a cache-aside strategy where we explicitly invalidated or updated the cache whenever the underlying data changed. Another scenario was handling cache misses during high traffic to avoid multiple requests hitting the database simultaneously, where we introduced techniques such as setting approaches, TTLs, and in some cases, using locking to ensure only one request rebuilds the cache. We also tuned invocation policies and memory usage to ensure Redis remains performant under load. These experiences helped me understand how to use Redis not just as a cache, but as a critical component in system performance and scalability. For maintaining the high traffic system, we also explored using Redis for rate limiting and short-lived counters, which further reduced our load on our core system.

The best features Redis offers are the ones that stand out most based on real-world usage. First is its in-memory preference, as Redis is extremely fast, making it ideal for caching and session management where low latency is critical. Second, it supports multiple data structures such as strings, hashes, lists, and sets, which are very powerful. I have used hashes for storing session data and structured objects efficiently. Another key feature is TTL, which allows automatic expiration of keys; this is very useful for managing sessions and ensuring stable cache, as stale cache data gets cleaned up without manual intervention. I also find Redis very useful for distributed systems because it acts as a centralized store that multiple services can access consistently. Overall, its simplicity, speed, and flexibility make it a very effective tool for performance and scalability improvement.

Using data structures such as hashes in Redis made the implementation much cleaner and more efficient. For session management, instead of storing the entire session as a serialized object, we used a Redis hash where each field represents a session attribute such as user ID, login time, and roles. This allowed us to update specific fields without rewriting the whole object, which improved performance and flexibility. Hashes are also memory efficient compared to storing multiple keys, helping us optimize memory usage when handling a large number of sessions. A specific scenario where TTL helped was with session expiration; instead of building a separate cleanup object to remove inactive sessions, we simply set a TTL on each session key, allowing Redis to automatically remove the expired sessions. This reduces operational overhead and avoids stale session buildup. Without TTL, we would have needed a background scheduler or a cron job to help clean up expired sessions, which adds complexity and potential failure points. Redis handled it natively and very efficiently.

Using Redis has had a specific positive impact on our system performance and scalability. The biggest improvement is in response time; by caching frequently accessed data, we reduce the API latency from database level milliseconds to sub-millisecond responses in many cases. It also helps significantly reduce the database load, especially during peak traffic, improving overall system stability and preventing bottlenecks. From a scalability perspective, Redis enables us to handle higher traffic without needing to scale the database proportionally, making the system more cost-efficient.

Overall, Redis is a powerful and reliable tool, but there are a few areas for improvement. One limitation is that Redis is memory-based, so scaling can become expensive compared to disk-based systems. While it offers persistence options, it is not always ideal for large datasets where cost efficiency is critical. Another area is cache consistency; Redis itself does not enforce consistency with the primary database, so developers need to carefully design cache invalidation strategies. More built-in mechanisms or patterns to simplify this would be helpful.

Additional areas where Redis could improve include monitoring, security, and ease of use in large-scale ecosystems. From a monitoring perspective, while Redis provides basic metrics, deep visibility into issues such as memory fragmentation, hot keys, or latency spikes often requires external tools; more built-in, user-friendly options would make diagnosing production issues quicker. Regarding security, Redis has improved over time, but historically, it required careful configurations; features such as authentication and encryption exist but are not always enabled by default, posing a risk if not properly set up. A strong, secure by default configuration would be beneficial. In terms of ease of use, while Redis is straightforward for basic use cases, managing clusters and persistence strategies can become complex at scale, so better abstractions or tooling for distributed setups and operations would make it more developer-friendly.

I have been using Redis for the last three years, and it is a part of my back-end development work where I mainly use it as a caching layer to improve my application's performance and reduce database load.

My main advice for those looking into using Redis is to focus on the use case; Redis excels where low latency is critical, such as caching, session management, or real-time features, rather than using it as a primary database for everything. Pay close attention to the caching design, especially cache invalidation and TTL strategies; poorly designed caches can lead to stale data or inconsistency. Plan for scalability and failure scenarios early; decide how you will handle Redis downtime. If possible, consider using a managed service such as those from Amazon Web Services to reduce operational overhead and focus more on application logic.

I find Redis particularly valuable because of how versatile it is. Many people think it is only a key-value pair cache, but its support for atomic operations and different data structures makes it useful for solving various real-world problems. For example, features such as atomic increment operations are extremely useful for building things such as rate limiting or counters without worrying about race conditions. Another underrated aspect is how simple yet powerful TTL and expiration handling are, eliminating the need for complex cleanup logic, which can otherwise introduce bugs or operational overhead. I also think more people should leverage Redis for lightweight distributed coordination, such as using Redis for distributed locks or request duplication, which can simplify system design when multiple services are involved.

Using Redis has definitely helped us improve cost efficiency. One of the main impacts was reducing the load on primary databases since a large portion of read requests is served from Redis, so we did not need to scale the database so aggressively, which saved costs on computing and storage. We also observed fewer database connections and queries, leading to lower CPU usage and lower input-output usage, which reduced the need for high-end database instances. For example, during peak traffic, instead of increasing database capacity, Redis absorbed most of the repeated requests, helping us delay or even avoid additional infrastructure provisioning, which directly reduces costs. Of course, Redis itself adds some cost since it requires memory, but the overall savings from reduced database load and improved efficiency outweigh the cost in our case.

Overall, my experience with Redis has been very positive, and it has played a key role in improving performance, scalability, and system responsiveness in our back-end system. What stands out to me is its simplicity combined with powerful capabilities; it is easy to get started with but also flexible enough to handle more advanced uses such as caching, session management, and real-time processing. The key is to use it thoughtfully, specifically regarding caching design and understanding its potential. When used correctly, it delivers significant value, and it is definitely a tool I would continue to use in future systems. I would rate my overall experience with Redis as a nine out of ten.

Redis is used for a part of a booking engine for travel, specifically for the front part to get some sessions and information about the sessions. If a customer or user is using the sites in different parts, we use Redis to get this information in cache.

The best features of Redis, from my personal perspective, are the performance, which is very quick, and it's very simple to implement.

Since I started using Redis, I feel that the product is saving me some performance tuning time. It's very easy, I have few parameters to tune, and it seems to have performance without a lot of working on the performance, compared to Cassandra, where you have to configure the memory and many other settings.

The integration capability of Redis is excellent.

Redis is very affordable because it's free.

The disadvantage of Redis is that it's a little bit hard to have too many clusters or too many nodes and create the clusters. The sync between the nodes is easier to implement with Couchbase, for example, and this is the only problem, the only disadvantage for me.

I started using Redis this year.

The stability of Redis rates nine out of ten, with one being not stable and ten being very stable.

The scalability of Redis rates eight out of ten, with one being not scalable and ten being very scalable.

Technical support rates at three out of ten.

Neutral

We started using Redis this year when we switched from Couchbase at the beginning of the year.

I have decommissioned Couchbase, which was not my database but my customer's database. They decommissioned it this year and chose Redis for the cache data parts, so I'm not using Couchbase anymore.

We use community support and we don't have a provider for the support, but to be honest, we don't need support. From the time we implemented, I hope it will continue this way.

I see about 40% savings since using Redis.

In my projects, we use documents basically, so all the NoSQL databases can be mapped with an API to have a kind of independence from Redis and any tool. If tomorrow we want to move from Redis to something better, we are independent from that.

If Redis has questions or comments related to my review, it's possible for them to reach me via email to clarify something.

I am interested in being a reference for Redis.

On a scale of 1-10, I rate Redis a 10.

My primary use case for Redis is to enhance the performance of our web applications by using it as a caching layer. By caching frequently accessed data, we reduce the load on our primary databases, resulting in faster data retrieval and a more responsive user experience.

We also use Redis for session storage, managing user sessions in a stateless manner, which ensures quick access to session data, supporting high-traffic scenarios without compromising performance. Additionally, Redis handles real-time analytics and leaderboard features, providing fast and efficient data processing capabilities.

For real-time notifications and updates, we utilize Redis' Pub/Sub messaging feature. This facilitates real-time communication and synchronization between our services. Our Redis setup includes replication for high availability, persistence for data durability, and clustering for scalability.

This integration of Redis in our environment has significantly boosted the performance, scalability, and reliability of our applications, making it an essential component of our infrastructure.

Redis has significantly improved our organization in multiple ways. Here are some key benefits we've experienced:

Performance Enhancement:

Redis, an in-memory data structure store, has dramatically boosted the speed and responsiveness of our applications. By caching frequently accessed data, Redis reduces the load on our databases and accelerates data retrieval times, ensuring a smoother and faster user experience.

Scalability:

Our organization has leveraged Redis for its robust scalability features. It supports clustering and partitioning, allowing us to scale our data store horizontally and handle high volumes of traffic with ease. This scalability has been crucial in maintaining performance during peak usage periods.

Versatile Data Structures:

Redis supports various data structures like strings, lists, sets, sorted sets, and hashes. This versatility has enabled us to implement complex features efficiently, such as real-time analytics, leaderboards, session management, and caching.

Eventual Consistency:

With Redis, we have been able to ensure eventual consistency in our distributed applications. Its support for publish/subscribe (Pub/Sub) messaging patterns allows us to build real-time notification systems and other event-driven applications.

High Availability and Persistence:

Redis offers features like replication, persistence, and automatic failover. These features have increased the reliability and availability of our services, minimizing downtime and ensuring data durability even in the event of failures.

Simplified Development:

Using Redis has simplified our development processes. Its rich feature set and easy-to-use commands have allowed our developers to implement caching, session storage, and other functionalities quickly, reducing development time and effort.

Overall, Redis has played a crucial role in improving the performance, scalability, and reliability of our applications, making it a valuable addition to our technology stack.

Redis's in-memory storage allows for extremely fast read and write operations, significantly enhancing performance for real-time applications. This speed is particularly beneficial for use cases that require quick access to data, such as gaming leaderboards, real-time analytics, and session management.

The variety of data structures like strings, lists, sets, hashes, and sorted sets offer flexibility in how we manage and access data. These diverse data types enable more efficient storage and retrieval mechanisms, tailored to specific application needs, which can simplify code and enhance functionality.

Redis also provides robust persistence options through RDB snapshots and AOF logs. These features ensure data durability and enable recovery from unexpected failures, offering a level of reliability that is crucial for maintaining data integrity in critical applications.

Additionally, Redis supports master-slave replication, allowing the creation of redundant data copies for high availability and read scalability. This feature is essential for applications that require constant uptime and the ability to handle large volumes of read operations without performance degradation.

Redis's publish/subscribe feature enables real-time messaging and notifications, which is crucial for building event-driven applications. This capability allows us to implement efficient communication mechanisms between different parts of our system, enhancing responsiveness and interactivity.

Redis clustering allows partitioning data across multiple nodes, providing horizontal scalability and fault tolerance. This feature ensures that Redis can handle growing data loads and maintain performance by distributing the workload across several servers, making it a reliable and scalable solution for modern applications.

These features collectively make Redis an incredibly powerful tool for improving performance, scalability, and reliability in our applications.

Redis has room for improvement in a few areas. Enhanced tools for managing and monitoring clusters would be beneficial, as would built-in security mechanisms like advanced encryption and granular access controls. Simplifying setup and configuration could make Redis more accessible to new users. Introducing more enterprise-grade features, such as better multi-tenancy support and improved backup and restore capabilities, would also be advantageous.

For the next release, it would be great to see enhanced cluster management tools, native multi-region supports for better data redundancy, integrated analytics for deeper insights, AI and ML integration features, and improved developer experience through enhanced SDKs and tools.

I have been using Redis for five years.

Redis is well-regarded for its stability, making it a reliable choice for various applications. It's designed to handle heavy loads with minimal downtime, thanks to its robust architecture. The use of Redis replication allows for high availability, ensuring that data remains accessible even if some nodes fail. Additionally, Redis Sentinel provides automatic failover capabilities, further enhancing its stability.

Its persistence mechanisms, like RDB snapshots and AOF logs, help maintain data integrity and recover from unexpected failures. Regular updates and a strong community support network contribute to its ongoing stability and improvements.

Overall, Redis's stability makes it a solid foundation for applications requiring high availability and reliability.

Redis is highly scalable, thanks to its support for clustering and data partitioning. You can start small and scale out horizontally by adding more nodes to your cluster, which allows you to handle increasing loads and larger datasets efficiently.

Its ability to replicate data across multiple instances ensures high availability and reliability. Additionally, features like data persistence and the ability to handle large volumes of read and write operations make Redis a robust choice for applications requiring high performance and scalability.

Overall, Redis excels in providing a scalable solution that can grow with your needs.

I have never had to contact the support team for any reason.

Positive

Yes, before adopting Redis, we used a traditional relational database system for caching and session management. We decided to switch to Redis for several reasons:

1. Performance: Our previous solution struggled with high latency during peak traffic times, impacting user experience. Redis, being an in-memory data structure store, offered significantly faster data retrieval times, which enhanced our application performance.
2. Scalability: As our user base grew, scaling our traditional database solution became increasingly complex and costly. Redis provided robust scalability features, including clustering and partitioning, which allowed us to handle larger volumes of traffic more efficiently.
3. Versatility: Redis supports a variety of data structures such as strings, lists, sets, and hashes. This versatility enabled us to implement complex features like real-time analytics and leaderboards more effectively than with our previous solution.
4. Event-Driven Capabilities: Redis's support for publish/subscribe messaging patterns allowed us to build real-time notification systems and other event-driven applications, which were more challenging to implement with our previous setup.
5. Simplicity: Redis simplified our development processes. Its easy-to-use commands and rich feature set reduced the time and effort required to implement caching, session storage, and other functionalities.

Overall, Redis addressed the performance, scalability, and versatility issues we faced with our previous solution, making it a better fit for our needs.

The initial setup of Redis was relatively straightforward, especially for basic configurations. Here are a few points that highlight the process:

1. Installation: Installing Redis was simple, with clear documentation and guides available for various operating systems. Whether deploying on a local machine or a cloud instance, the steps were easy to follow.
2. Configuration: For basic use cases, the default configuration settings were sufficient. However, for more complex setups involving clustering or high availability, the configuration required more attention and understanding of Redis parameters.
3. Integration: Integrating Redis with our existing applications was smooth, thanks to the availability of client libraries for different programming languages. This made it easier to incorporate Redis into our tech stack.
4. Learning Curve: While the basic commands and operations were easy to grasp, understanding advanced features and optimizing performance required more in-depth knowledge. Fortunately, Redis's comprehensive documentation and community support helped bridge this gap.

Overall, the initial setup was manageable and straightforward for basic use, with some complexity arising in advanced configurations.

Measuring the return on investment (ROI) of Redis can vary based on the specific use case, but here are some general observations:

1. Improved Performance: The speed and efficiency of Redis can lead to significant performance improvements. This results in faster response times and a better user experience, which can translate into higher user retention and satisfaction.
2. Cost Savings: By reducing the load on your primary databases and improving application performance, Redis can help lower infrastructure costs. This is especially true if you're using a managed service that scales with demand.
3. Developer Productivity: The simplicity and versatility of Redis can increase developer productivity. Faster implementation of features and reduced time spent on performance optimization can lead to quicker time-to-market for new products or features.
4. Scalability: Redis’s ability to scale efficiently ensures that your application can handle increased traffic without significant additional investment. This scalability helps maintain performance and reliability as your user base grows.
5. Reliability: The stability and high availability of Redis can reduce downtime and data loss, leading to more consistent service and higher customer trust.

While the specific ROI will depend on your unique circumstances, these benefits often result in significant value for organizations that implement Redis effectively.

Setup Cost: Redis itself is free and open-source, but infrastructure costs apply. Managed services may incur additional expenses.

Pricing: Self-managed Redis is cost-effective but requires technical expertise. Managed services offer predictable costs and auto-scaling features, starting from around $5/month.

Licensing: Redis is open-source under the Redis Source Available License. Enterprise features require a commercial license.

Evaluate your needs and monitor usage to manage costs effectively.

Yes, before choosing Redis, we evaluated several other options. We considered continuing with our existing relational database system, but it had performance and scalability issues. We also looked into Memcached, which is another in-memory caching solution. However, Redis offered more advanced data structures and features that were beneficial for our use case. Additionally, we explored other NoSQL databases like MongoDB and Couchbase, but they didn’t meet our performance needs for real-time data processing and caching as effectively as Redis did. Redis stood out due to its speed, versatility, and robust feature set, making it the best fit for our requirements.

Do you have any additional comments or advice regarding this solution?

Yes, a few additional points that might help you:

1. Stay Updated: Redis evolves regularly with new features and improvements. Keeping up with the latest updates can help you leverage the best practices and latest enhancements.
2. Use Redis Sentinel for High Availability: To ensure high availability and automatic failover, consider using Redis Sentinel. It provides monitoring, notification, and automatic failover capabilities.
3. Regular Backups: Implement regular backup strategies to prevent data loss. While Redis persistence options (RDB and AOF) are robust, having an additional backup mechanism can be a safety net.
4. Optimize Memory Usage: Redis being an in-memory store, it’s essential to monitor and optimize memory usage. Use features like data eviction policies to manage memory efficiently.
5. Consider Redis Enterprise for Critical Applications: If you require advanced features like multi-region replication, more robust clustering, and enterprise support, Redis Enterprise might be worth the investment.
6. Leverage Community Resources: The Redis community is vibrant and full of resources. Participating in forums, following Redis developments, and utilizing community tools can be very beneficial.

Redis Cache is better than other competitors and I would recommend it to other people.

I'd rate the solution nine out of ten.

I used Redis for a one-time implementation while working on a college project. I implemented it locally on a machine and used it for a vector search.

Since it was a university project, it helped in providing a stable and efficient solution for my project needs. This enabled me to complete the project successfully and pass an exam.

Redis is stable, provides consistent results, and is fast. It is particularly efficient for cloud-based storage and operations.

Redis could improve its efficiency in handling locally stored data, not just Amazon Cloud or Google Cloud. It would be helpful if Redis could provide a one-stop solution for all data varieties, which would improve the integrity between different databases.

I used Redis for about a day for the implementation.

Redis is definitely a stable product. It provided accurate and consistent results without any issues.

Redis is a highly scalable product, especially since it effectively handles cloud-based storage, which is the most scalable option.

I did not communicate with the technical support team, so I cannot provide a rating for customer service.

Positive

I also used Firest for my project and found it to be more suitable for my specific use case.

The initial setup was very easy. The only requirement was to change the syntax from Redis to Firest and vice versa.

I completed the implementation all by myself without needing any additional help.

I used the free, open-source version of Redis, so I did not incur any costs. For personal use, a lower price is always better.

I evaluated and used Firest and several other databases for my project, including Crontabee and Cosmodb.

Redis is beneficial for specific usage and domains. If Redis can handle various data types efficiently, it would become a comprehensive solution for any use case, potentially topping other databases. Its consistent results and free, open-source nature make it a solid choice.

I'd rate the solution eight out of ten.

In my current workplace, we use Redis for various purposes, including managing query caches, queues, and as a registry for different system components. These components register themselves when live, enabling efficient usage tracking. 

Previously, at another company, we used Redis to cache machine learning models, facilitating model delivery across platforms without frequent disk retrieval.

In my current workplace, we use Redis for various purposes, including managing query caches, queues, and as a registry for different system components. These components register themselves when live, enabling efficient usage tracking. 

Previously, at another company, we used Redis to cache machine learning models, facilitating model delivery across platforms without frequent disk retrieval.

Redis provides an easy setup and operation process, allowing users to quickly connect and use it without hassle. We primarily use Redis as a caching system due to its multiple data types and PubSub features, offering efficient data handling. Redis's PubSub capabilities benefit our communication by facilitating thread intercommunication. It allows multiple threads to exchange messages efficiently.

Redis presents a single point of failure and lacks fault tolerance. It would be beneficial if high availability features were available in the noncommercial version, similar to those offered by the commercial managed solutions from Redis Labs.

I have been working with Redis for over ten years.

If Redis is set up correctly, it requires no maintenance and can function smoothly for long periods without intervention. Memory calculations should be precise to avoid issues.

With approximately 500 microservices and environments scaling up to 1,000 customers, Redis accommodates a range of scales. Proper memory allocation allows for seamless operation.

We have not utilized customer support for Redis.

Positive

In comparison to other caching solutions like Memcached and Aerospike, Redis is easier to deploy and manage. Aerospike, while highly efficient, is more complex to set up.

The initial setup of Redis is very straightforward and user-friendly. Deploying Redis takes about thirty seconds, making it quick and efficient.

Implementation can be done in-house using AWS ElasticCache or Docker to run Redis on Kubernetes, depending on cost and environmental factors.

We use Kafka for inter-process communication, but Redis is used for thread intercommunication due to its PubSub capabilities.

I recommend Redis as it provides an easy-to-use caching solution with beneficial PubSub features. 

It's excellent for startups or new projects with many components needing coordination. However, for more advanced messaging or larger data volumes, Redis might not be the best fit. 

I rate Redis a nine out of ten.

We use the solution as a caching layer.

The ability to fetch and save data quickly is valuable. We can fetch data within milliseconds. The tool provides data structure capabilities. It also provides geolocation search and JSON search capabilities. The performance is very good. Redis can save each internal transaction to the file system. It helps us handle persistence in our storage.

The product's main purpose is caching, even though the vendor says we can also use it as a persistent database. If we use a lot of data, it will eventually cost us a lot. The tool is single-threaded. It doesn't support many data models. We only have key-value, hash, and JSON.

I have been using the solution for more than ten years.

The tool is stable.

The tool is easy to scale. We can add additional storage, and it will scale easily. We have millions of end users. We are an enterprise-level organization.

The product provides excellent support.

Positive

The deployment is easy. The deployment takes a couple of hours. One engineer can deploy the tool. We can fully manage the tool as SaaS with low maintenance. If we want to deploy it in our own environment, we must be more aware of changes and monitoring. Since I'm using the caching layer, we must choose the correct mode to save and fetch the data optimally. It is complicated to understand which feature or model we must use.

Eventually, we need to manage caching. If we manage on our own, it will take a lot of developer resources, infrastructure, and environmental resources. So, it is better to use Redis. The ROI is better.

We pay a yearly fee, but we pay according to the usage.

I also work with PostgreSQL, MySQL, Elasticsearch, Cassandra, and Splunk. Redis provides efficient caching and performance. The other solutions have persistent storage functionality. If I want persistence, I would use the other tools. If I need high performance, I would use Redis.

We must understand our system needs and pick the correct data structure in Redis to support it most efficiently. Overall, I rate the tool an eight out of ten.

We use it primarily for real-time applications. In our web application, we added a feature where hundreds of people could play a quiz in real time. 

Instead of using traditional databases like SQL, we implemented Redis to make everything happen in real time – all those quick calculations, data hashing for easy retrieval, and so on. 

It was a live quiz feature, so Redis helped a lot. I also use Redis for caching and similar general use cases.

It improved the performance. For example, data structures like hashmaps in Redis make it a very fast database – much faster than traditional SQL databases. It can perform at significantly higher speeds. Latencies are very low. Our primary focus wasn't on saving money but on improving performance for that specific feature.

So, performance has been the key improvement. Every calculation happened in real time. It improved the performance 10X. 

In our company, we have limited resources, so we can't manage the database ourselves. We use services from Azure for that.  So, Redis integrates well with those services.

We use Azure Cache for Redis.

It performs much better than traditional databases. Our calculations happen in real-time, which was crucial for that quiz feature.

The price could be better. 

I have been using it for more than two years. 

It has been a reliable product for us.

It's been working very well for us. Since our scale isn't huge, it's able to handle our needs without issues.

I've also worked with PostgreSQL, Cassandra, MySQL, and Elasticsearch.

It's tough to find a direct competitor because Redis, Cassandra, PostgreSQL, and Elasticsearch all serve different purposes. Cassandra excels when you structure tables according to your requirements upfront. It offers fast reads. However, the Cassandra Query Language (CQL) isn't as flexible as SQL – there are no joins, for example. It is a very restricted query language. So, we need to carefully design your database tables with future data needs in mind.

Redis is better tested and is used by large companies. I haven't found a direct alternative to what Redis offers. Plus, there are a lot of support and learning resources available, which help you use Redis efficiently.

It's actually quite expensive compared to SQL since Redis uses a system's main RAM, which is costly. And memory can be limited.

We opt for a dedicated server.

Overall, I would rate the solution an eight out of ten. It's been very stable so far and performs well within our system.

I would recommend it, but I would also highlight the cost factor as something to consider.