Redis is missing the D in ACID, meaning a successfully executed command is not guaranteed to persist to disk since Redis only flushes it's data to disk (if you do have persistence enabled) at configurable intervals.

So when you server dies you lose the changes since the last flush. I would not use as a primary storage for data you cannot afford to lose.

Have a look at this: http://redis.io/topics/persistence

Edit: you can configure redis to flush on every command that changes data...but you probably wouldn't want to use redis that way :)

This is acceptable for a wide range of apps. EtherPad, for example (which used MySQL) only flushed every second or two. If the database crashed, then yes, you'd lose the last couple keystrokes, but that was so extremely rare it didn't even register as a factor in the overall UX.

Edit: Also, you probably have bigger problems if your database goes down or your cluster falls off the map somehow.

Absolutely, but people should still be aware of the compromises and not confuse categories.

Very few apps can make do with only a key-value store and if you have to throw a relational db in the mix, why introduce more moving parts unless absolutely necessary? ACID, referential integrity, SQL. Sometimes it feels people are willing to ditch all this for very little gain.

Let's face it, how many apps out there can't really run a beefy relational DB with potentially an absurd amount of RAM?

I'd also add that (unless you have a very good reason not to) it's probably a good idea to always add a TTL (expiration date) to any key you store in Redis to enforce the "not primary storage for data you cannot afford to lose" way of thinking.

A good rule of thumb is to only use Redis as an ephemeral storage for data that you can reconstruct if you lose it, or that you can otherwise afford to lose.