# Clarifications about Redis and Memcached

DevFeed: [Clarifications about Redis and Memcached](<https://devfeed.tech/articles/clarifications-about-redis-and-memcached-20685.md>)

Original publisher: [Read original article](<http://antirez.com/news/94>)

Published: 2015-09-26T16:16:14Z

Content type: opinion

Language: en

Sources: [Antirez](<https://devfeed.tech/sources/antirez.md>)

Topics: [Redis](<https://devfeed.tech/topics/redis.md>), [Caching](<https://devfeed.tech/topics/caching.md>), [Database](<https://devfeed.tech/topics/database.md>)

Tags: [caching](<https://devfeed.tech/tags/caching.md>), [database](<https://devfeed.tech/tags/database.md>), [opinion](<https://devfeed.tech/tags/opinion.md>), [redis](<https://devfeed.tech/tags/redis.md>)

## AI overview

This opinion article responds to a claim that Memcached is preferable to Redis for caching. It argues that Redis is also designed for caching, can disable disk I/O for an in-memory setup, and offers optional persistence, while acknowledging Memcached's multithreading advantages.

## Source excerpt

If you know me, you know I'm not the kind of guy that considers competing products a bad thing. I actually love the users to have choices, so I rarely do anything like comparing Redis with other technologies. However it is also true that in order to pick the right solution users must be correctly informed. This post was triggered by reading a blog post published by Mike Perham, that you may know as the author of a popular library called Sidekiq, that happens to use Redis as backend. So I would not consider Mike a person which is "against" Redis at all. Yet in his blog post that you can find at the URL http://www.mikeperham.com/2015/09/24/storing-data-with-redis/ he states that, for caching, "you should probably use Memcached instead [of Redis]". So Mike simply really believes Redis is not good for caching, and he arguments his thesis in this way: 1) Memcached is designed for caching. 2) It performs no disk I/O at all. 3) It is multi threaded and can handle 100,000s of requests by scaling multi core. I'll address the above statements, and later will provide further informations which are not captured by the above sentences and which are in my opinion more relevant to most caching users and use cases. Memcached is designed for caching: I'll skip this since it is not an argument. I can say "Redis is designed for caching". So in this regard they are exactly the same, let's move to the next thing. It performs no disk I/O at all: In Redis you can just disable disk I/O at all if you want, providing you with a purely in-memory experience. Except, if you really need it, you can persist the database only when you are going to reboot, for example with "SHUTDOWN SAVE". The bottom line here is that Redis persistence is an added value even when you don't use it at all. It is multi threaded: This is true, and in my goals there is to make Redis I/O threaded (like in memcached, where the data access itself is not threaded, basically). However Redis, especially using pipelining, can