Redis Cache and Storage Modes

About Redis modes on Compose

Compose Redis has two modes; "Storage" mode is the default. It operates as a high-performance in-memory store optimized for performance and data safety and expanding through autoscaling as needed. As more data arrives in the database, so its use of RAM goes up.

The "Cache" mode is the alternative. Here the auto-scaling is disabled and the Redis database does not expand. That means it gets to rely on Redis to evict items from memory depending on what eviction policy is selected. That policy is set in a configuration setting called maxmemory-policy.

While simply switching the autoscaling behavior was effective, we wanted to get the best performance in Storage and Cache modes. With the latest updates to Redis, when 'storage' mode is selected we set the maxmemory-policy to noeviction to ensure that there is no data loss and the deployment always expands. When the cache mode is selected, we set maxmemory-policy to allkeys-lru to ensure that all key/value pairs are subject to eviction on a Least Recently Used basis.

We don't stop you changing these settings on your deployment; they are available in the Settings page of the Compose console for your Redis deployments. We do recommend, though,that you consider your options carefully before adjusting maxmemory-policy

As this the mode is an important component of how your Redis deployment works, we have also put a panel indicator on the Overview page to show which mode your deployment is operating in and we allow you to select between "storage" and "cache" when creating a new Redis deployment. You can still change mode on the Settings page on the "Redis as a Cache" panel.

🚧

Backups and Cache Mode

We also disable backups on databases in "Cache" mode because backing up can consume 100% of available memory, effectively eliminating "Cache" mode's performance advantages on a busy database.

Note that the Save setting is available in the "Cache" mode Settings view and can be enabled to bring backups back, but this will be detrimental to most use cases performance.

The database will still be persisted on "SIGTERM" events, typically generated when planned maintenance or configuration changes occur such as changes in Redis version. This is to allow the database to come back online with the cache data from before the change loaded and ready after those events and avoid excessive cache misses. This instance of persistence is not a backup as it is not retained.

We intend to continue working on these modes to make it simpler and more effective to run with our pre-selected defaults.

Still Need Help?

If this article didn't solve things, summon a human and get some help!