I was oversimplifying of course, Redis Cluster definitely deserves a place in the comparison. We are actually very satisfied with using Redis in production but had to work around the PubSub limitations using keyspace notifications, which is why I'm biased regarding that point.

In any case, it's difficult in terms of presentation, since a "normal" master-slave-replicated Redis is a totally different system from Redis Cluster as the distribution models of Redis Cluster also affects the functional properties to a large extend, e.g. regarding atomic Multi/Lua blocks and all types of multi-key operations.

The failover solutions for relational database systems are a good point, they too should be included.

Regarding use cases, I totally agree: every system should be discussed in the light of the use cases it tries to solve. I personally think that Redis Cluster with a choice for trading consistency against latency would open up a whole new range of use cases that are currently not a good fit for Redis Cluster. For example, we have a Redis-Coordinator project (not open source, yet) which behaves similar to a scalable Zookeeper (BTW also neither CA nor CP [1]). However, it has weaker guarantees, due to lack of tuning knobs in Redis and Redis Cluster regarding consistency.

[1] https://martin.kleppmann.com/2015/05/11/please-stop-calling-...