Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Alarming, I'd imagine:

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.)


Actually, that is talking about the existing virtual-memory (VM) implementation, which swaps data in and out to disk, and doesn't work so great.

The change being talked about here is all about replacing that exact flakey VM with a more solid disk backed approach


I'm sorry, but that's what I meant. I'd be more alarmed than enticed to discover that the current implementation of datasets-larger-than-RAM for my chosen database was considered "flakey", and was going to be swapped out for a green-field approach in the next release.

For reference, this is the blog post that introduced the VM idea: http://antirez.com/post/redis-virtual-memory-story.html


> I'm sorry, but that's what I meant. I'd be more alarmed than enticed to discover that the current implementation of datasets-larger-than-RAM for my chosen database was considered "flakey", and was going to be swapped out for a green-field approach in the next release.

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.


If Redis was "my chosen database" then I should have done my homework better.

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.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: