Hello bri3d, it's true that Redis is at the intersection of many use cases: for some it is appropriate, for some it is not. But about the memory VS disk debate,

Hello bri3d, it's true that Redis is at the intersection of many use cases: for some it is appropriate, for some it is not. But about the memory VS disk debate, we are making progresses in this area. The thing is: Redis can be used as a purely in-memory system, but not if you enable replication, since replication used to have an issue, it needed to persist on disk in order to synchronize the first time with the replica. At some point we made this issue a bit more manageable, by implementing partial resynchronizations. However still for the first SYNC to persist was needed, and even after reconnections if there was not enough "backlog". So when people said "I want to use Redis in a master-slave setup, but, with persistence turned off, and I still want my data back after restarts", I used to reply "turn on persistence instead, since anyway for replication you NEED to save on disk". However, now there is a new thing that is changing my mind. A few days ago I finished a beta of diskless replication, this will be merged into unstable in a matter of days. Suddenly Redis no longer needs disks to replicate with its slaves. Now to have a master-slave setup with zero disk involvement is a real thing, so I'm trying to understand how I provide features to make this use case simpler to support. One feature which is trivial to add and can solve many problems, is protected restarts. Basically, if configured to do so, a master can return back online after a restart in a protected mode, where commands are not accepted, but instead an error is reported. This mode can be escaped only using SLAVEOF to configure the instance as a master, or as a slave. This way, slaves can't replicate from a rebooted master, and their data set is not lost. Similarly, Redis Sentinel will see the master as failing (since it replies with errors to PIGNs), so will perform a failover and a slave will be elected. The old slave will be reconfigured as a slave, and this in turn will undo the protected mode. Given it's a few lines of code looks like a promising solution that users can have ASAP.