Final Takeaways

Some final thoughts on Redis. One of the main alternatives to Redis is Memcached, which I explored before choosing to use Redis. Redis can essentially do everything that Memcached can do and more. With the recent clustering feature, Redis has become even more powerful and there seems to be very few reasons to choose Memcached over Redis if you haven't already committed to Memcached. With that said, there are a few caveats to Redis.

Redis is an in memory data store, which means it is susceptible to data loss. While Redis does have a snapshot ability to essentially persist the state of Redis to a snapshot and restore it, the snapshot doesn't run in real time. It also can't predict when a server might crash or experience a power failure, so your data is only as up to date as your most recent snapshot. Ultimately, this means that you can lose data if you are relying solely on Redis.

You should choose carefully how you use Redis and either be comfortable with the potential to lose some data or have other preventative measures in place. If you're using Redis as a cache for instance, then losing data isn't such a big deal. If you're using Redis as a queue for critical jobs, then you may want some fail safes in place to prevent losing any single job.

Another thing to keep in mind is that Redis is limited by the RAM of the server it is operating on. The entire data set is stored in memory. It is up to you to be smart about how you manage data and let it expire to keep your data set relevant and reasonably sized.

Like any great tool, as magic as it may seem, ultimately it isn't and you should think critically about how you are using it to minimize any potential downsides.