Depends on the use case, but basically, there is a big set of problems you can solve with different technologies depending on your exact details, one will be better in one way, one will be better in some other way. The sensibility of the programmer is to pick the right one, in an effort to maximize the different aspects: data model fitness for the problem at hand, operational aspects, consistency guarantees, performances (number of nodes needed), scalability, simplicity (do I need support since it's a complex stuff?), and so forth.
http://memcached.org/ used to be. I haven't done system architecture in about 2 years but when we were looking at in memory databases, it came down to Redis or Memcache.
Memcached is just a stupid key-value store, and by stupid I mean it just stores and retrieves values. It's extremely primitive compared to Redis.
It's not even close to the same thing as Redis except superficially.
The key/value part of Redis is just the beginning. The values themselves can be of several different types that allow for a lot more flexibility in how you store and query data.
>In order to achieve its outstanding performance, Redis works with an in-memory dataset. Depending on your use case, you can persist it either by dumping the dataset to disk every once in a while, or by appending each command to a log.
Well, it's written to disk either way. You're right that if you do the "once in a while" setup, you can lose some data in a power failure.
At a previous job people started using Redis thinking it was a fast in-memory data store. It turned out we had accumulated tens of thousands of records.
I haven't measured, but I doubt it's much faster than Postgres. It does have other nice features. I like using the expiring records for caching.
