For my part: on only a few occasions (mostly fuzzer farm stuff) have I ever used Redis and been happy with the decision. I usually regret using it. I always regret using it as an alternative to SQL.
Mongo has taken a lot of knocks in part because its write ack behavior was (initially) documented in a way that not everyone felt was sufficient, but also because it is marketed as a universal solution for RDBMS woes.
Redis has never been touted as a replacement for a primary data store, but more of a "toolbox" in some cases, or "middleware" in others. To apply the same criticisms to Redis and Mongo implies those users did not research their platform decisions at all.
What was your use case, and what was your experience with it?
How many string keys? Millions? Billions? What happens if you lose an update?
Redis great for lots of rapid reads and moderate write speed for data that fits on a single server or can be manually sharded well (if it's straight k=>v, as you describe, that basically means your json fits in RAM; if you're using larger objects like sets/zsets/etc, it becomes a slightly different discussion), as long as your application can lose a few seconds without killing you (BGSAVE isn't instantaneous, of course).
http://redis.io/topics/twitter-clone
I want to use it in a small project so I can learn the design patterns associated with key-value stores. I'm sure there are good and bad things about using Redis vs Postgres.
But it has to hold my data, so... does it hold my data or not? I'm talking about single box stuff here, of course.
(Of course, I'll just use it and find out myself).
Is all data in a database that important? Maybe alternative databses would generate new webapp patterns, like dynamic languages do.
Mongodb seems like a solution that was optimized for a certain performance sweet spot that, post-SSD and huge RAM, hardly anybody ever really encounters and 99% of the times it's used you would be better off with Postgres.
Redis on the other hand hits a (probably permanent) sweet spot of ultra-high performance one level of abstraction lower than your usual database; which is a use case everyone trying to saturate metal and squeeze out the last bit of performance on a minimal budget has.
As an alternative to an in-memory cache or (occasionally) a DB de-normalization, on the other hand, it works amazingly well for me.
I see the persistence is basically just a backup that helps your system get back up to speed quickly after a crash or systems' restart. It's not something that should ever be treated as reliable.
I wonder how many people who use it under this or similar use cases have an issue with it.