Exactly, but the use cases for it cannot be easily put into obviously delimited things. There are use cases where Redis is a good fit as a primary database, and use cases where it should not be used even if data is ephemeral, to make an example. The right applications depend on the exact problem, and even problems that are not a fit can be re-stated so that they become good enough for Redis, and similarly, problems that in theory are a great fit can be mis-implemented easily. As I said IMHO it's a matter of understanding how Redis works exactly... in order to make great choices both in applying it or not, and how to apply it.

Here is my understanding.

Redis pushes the limit of what can be accomplished using a single-threaded in memory data store. If your processing can be done by such a thing, Redis is probably the most efficient option available. (With, of course, persistence, replication, and so on for managing your data.)

But if you throw blocking operations or too much data at it, Redis is going to demonstrate the inherent limitations that come with being a single-threaded in memory data store.

Just curious - what's an example where Redis is a good fit as a primary database?

> The right applications depend on the exact problem, and even problems that are not a fit can be re-stated so that they become good enough for Redis, and similarly, problems that in theory are a great fit can be mis-implemented easily

How about adding something about this in the documentation, if you haven't already?

  - Do use Redis for <X>
  - Do NOT use Redis for <Y>

Original author here. I agree with this. And i tried to deliver this sentence between the lines within this article.