[antirez]

I think that here the approach is very wise: every time you have a problem involving a big amount of data, Redis may be costly, since it stores data in memory. Sometimes this is unavoidable, for instance I may see Twitter switching from Redis to another in-memory store to cache timelines, but hardly to something using disk. So it is very legit to say, I'm running a number of hosts since my memory requirements are high, let's try a cheaper on disk solution.

However that said it is also true that memory starts to be seriously cheap, and the real limit may be to run stuff on EC2 or similar platforms.

So sometimes the cost of RAM is a virtual cost associated with the platform you are running your services in, compared to the actual cost of that amount of memory.

[tfb]

I'm not entirely sure what I'd search for so I figure I might as well ask here. When a key won't fit in redis, does redis remove the least active key(s) to make room? And is there a way to persist the removed keys to disk to possibly be retrieved at a later date? That way the most active keys remain in memory while the least active keys are still available.

[ricardobeat]

I haven't actually experienced this, someone correct me if I am wrong: you can choose from different policies (LRU, TTL, random) to expire/remove keys, otherwise if you disable maxmemory it will start using the OS virtual memory and slow down.

Redis had a virtual-memory option like you describe at some point, but it was scraped due to poor performance and other issues.

[tfb]

Ah LRU and virtual memory are the keywords I was looking for. I couldn't remember! Thanks!

[robotresearcher]

The cost of VM RAM is bounded below by the cost of the physical RAM used to provide it, unless it's subsidized by costs elsewhere.