Our default back end is to run as an in memory DB, and most of the design and goals are related to this mode. But I think that most of the value of Redis is its data model, and I bet it will survive Redis itself, so the idea is, let's look to alternatives that make this data model working well with data sets bigger than RAM.
Our old solution was VM, but we found it is not ideal, does not work well with the Redis in-memory back end persistence ideas (that are instead working well without VM). What to do then? Keep trying with the wrong solution? :) I guess not, open source also means that if the cure for a disease is not good enough we put things into the trash and try again and again, as the sole goal should be the progress of the technology we are trying to put in the hand of users.
So we have a new model now, and will test how it works in practice. What we said is: for write heavy applications where performances matter, use Redis as an in-memory DB. It works well, it's well tested, and we can count many happy users.
But if the Redis data model solves your problems, and you have a read-heavy application with tons of data, we are going to provide an alternative that could work well.
https://groups.google.com/forum/#!topic/redis-db/ZTSm-1w-6AQ
To quote from the end of the post:
so, to sum this up -- after a while, you are stuck with an
in-memory database that you cannot backup, cannot replicate to
a standby machine, and that will eventually consume all memory
and crash (if it does not crash earlier).
conclusion: redis with vm enabled is pretty much unusable, and we
would really not recommend it to anybody else for production use
at the moment. (at least not as a database, it might work better
as a cache.)The change being talked about here is all about replacing that exact flakey VM with a more solid disk backed approach
For reference, this is the blog post that introduced the VM idea: http://antirez.com/post/redis-virtual-memory-story.html
As Redis is mainly an in-memory DB, currently larger datasets than RAM were not our first goal, and there was even the idea to drop support at all for this use case. I think that what matters for most users is that the default mode of operations is working great, and that for an alternative mode of operations developers are not dogmatic and don't fear to drop what is not optimal to replace it with something better. In many other contexts this would be regarded as bad marketing and not done at all, but I try to follow a scientific way to make progresses, and I tend to accept that I and the other developers are not perfect and need to make mistakes and improve the design again and again ;)
I like Redis data model and I think this is our biggest value, and we need to find different underlaying implementations for different use cases, and keep trying to provide more speed, better durability, better replication, and so forth, ad libitum.
Redis has always been billed as an in-RAM database, which hard-implies that your dataset must fit in RAM, and thus that Redis is unlikely to be your only database.
VM - i.e. even the possibility of having a dataset larger than RAM - is a recent addition, and one flagged as experimental. It had some issues which meant (for us and for the author of the post you linked to above) Redis was still not feasible for datasets larger than RAM. This new diskstore model, and the associated rethink, is very encouraging news, as it means that scenario might one day be possible after all.