Btw everything is used to store data permantly, reliably or not for your specific needs/tastes, is a database.
Also you can use Redis in append mode if you wish, this will sync your data ASAP on disk. For now in order to do this you need to use netcat, but this will be supported with ad-hoc tools in the future. Still this will be the discuoraged way to do things.
And about reliability, it's worth to note that with Redis there is a delay between the memory copy and the persistent copy of the dataset, but this is not about reliability of the whole dataset, all your data that is not about the latest few minutes is stored on disk permanently without any kind of risk.
Also, you appear to claim that if a database for design limits the amount of data it can hold to the amount of free ram, it is a cache. This is not the case IMHO.
Then why is redis not advertised as an "in memory database"? It likes to be compared with MongoDB or TokyoTyrant but is clearly not playing in the same league.
Moreover it glosses over this issue in quite a self-righteous fashion almost everywhere. One example of many would be this gem from the "TwitterAlikeExample":
This means you can serve millions of users every day with just a single Linux box, and this one was monkey asses slow!
That's just false advertising if your "millions of users" actually use the service. Just storing the plain account data for 1 million users would push the database into the 1GB realm. Go figure what happens when these users actually begin to leave a footprint.
Btw everything is used to store data permantly, reliably or not for your specific needs/tastes, is a database.
I'm not normally nitpicking about terminology. It just left a bad taste in my mouth in this particular case because the redis homepage doesn't bother to mention this critical difference to most similar offerings. The current blurb is highly deceptive.
"That all your business data fits in the RAM you can afford"
I believe this is true in many, not say most, cases. If not, don't use an in-memory "database", "persistent cache", "prevalence layer", or whatever you want to call it.
Being able to guarantee that all your data will always fit in as much RAM as you can afford is a luxury that almost nobody has. There's still an order of magnitude between common disk and DIMM sizes.
Some may consider this a small terminology glitch but for me it's quite a fundamental issue.