Hello alberth, I would not say Redis has an history of being unstable, actually it is regarded as not failing and not crashing often. However at the same time,

Hello alberth, I would not say Redis has an history of being unstable, actually it is regarded as not failing and not crashing often. However at the same time, some people believe that it is operationally challenging, which is a different problem. That Redis operations are harder than the ones of other DBs is in part true because the fact of having the data in memory, with different mechanisms to backup the data on disk, means that in case of an operation error (not necessarily a bug, just also an admin error), the outcomes can be worse. However in the filed of operations Redis improved year after year. However this does not answer your question about critical bugs. Basically most of the critical bugs you'll see in the Redis 4.0 changelog is about the new version of replication that was put in Redis in Redis 4.0 itself. The new protocol, called PSYNC2, was harder to implement and has many corner cases because it is able to restore the replication link with the master after it was broken. To do so requires to take the state of the replication intact, and given that slaves can do that (partial resynchronization) after an RDB restart, we found many issues in this respect: after an RDB restart there were cases where the state was not fully restored. Most of the time it was very hard to trigger such bugs, and in most cases those issues were found analytically and never reported. Yet I feel like I should mark every of such bug as CRITICAL in the release, regardless of the fact nobody was affected for a log time.