Official Magento guidance is to use separate Redis instances for cache and session storage. What is the reasoning behind this?

I've seen some old references mentioning that it is for ease of cache clearing (which can be fixed by using separate Redis databases) or to prevent sessions from being dumped if the cache fills up (which can be avoided by provisioning sufficient capacity). Are there reasons beyond these?

Does this still apply if using Amazon ElastiCache as the Redis-compatible provider?

  • you already answered your question...
    – MagenX
    Commented Oct 12, 2017 at 7:55
  • @MagenX So that's to say there are no reasons beyond the ones I cited? Those reasons are actually trivially avoidable, as I explain. Commented Oct 12, 2017 at 14:47

2 Answers 2


We set up separate instances of Redis so we can save to disk for sessions (to preserve sessions if crash), but not save to file for the Magento cache which can more easily rebuild after crash/reboot.

That and for taking advantage of multiple cores and Redis being single threaded...


Redis instances shares the memory between all of their databases: if you set 1gb as maxmemory, it will be the sum of all of its databases. While cache can handle any memory limit, sessions don't. There should always be space left in memory for them, as their values needs constant updates. A missing session key results in a logout, while a missing cache key result in a regeneration. Also, if any lru applies (when it happens it is triggered by cache operations), there will be a heavy performance reduction... this will happen even if you separate the instances - it will be just worse.

Also backup policies are a nice feature you can add to separate instances, as Rob Mangiafico stated.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.