Plan Redis modules for Azure Managed Redis

  • Applies to: ✅ Azure Managed Redis

Redis modules affect several decisions that you make when you provision an Azure Managed Redis instance. A module can constrain your tier, clustering policy, eviction policy, active geo-replication design, and client library choice.

Use this article to identify those dependencies before deployment. For module capabilities, command guidance, and enablement instructions, see Use Redis modules with Azure Managed Redis.

Compare configuration requirements

Use the following matrix to identify the configuration constraints introduced by each module. The scope of Redis modules table remains the authoritative source for module availability.

Module Supported tiers Required clustering policy Required eviction policy Active geo-replication Planning consequence
RediSearch Memory Optimized, Balanced, and Compute Optimized Enterprise NoEviction Supported Plan enough memory headroom to continue accepting writes without automatic eviction.
RedisJSON All tiers, including Flash Optimized No module-specific requirement No module-specific requirement Supported on non-Flash tiers RedisJSON is the only module available on Flash Optimized.
RedisBloom Memory Optimized, Balanced, and Compute Optimized No module-specific requirement No module-specific requirement Not supported Use a separate, non-geo-replicated instance if the data requires this module.
RedisTimeSeries Memory Optimized, Balanced, and Compute Optimized No module-specific requirement No module-specific requirement Not supported Use a separate, non-geo-replicated instance if the data requires this module.

Resolve design conflicts

Resolve these constraints before you provision the instance:

  • Module selection is fixed at creation. You can't manually load a module into an existing instance or select a module version. If you need another module later, provision a new instance and migrate the data.
  • All requirements apply when you combine modules. For example, combining RediSearch with RedisJSON still requires the Enterprise clustering policy and NoEviction.
  • Flash Optimized supports only RedisJSON. If the same workload also requires search, probabilistic data structures, or time series capabilities, choose a non-Flash tier or split the data across instances.
  • Active geo-replication supports only RediSearch and RedisJSON. Every instance in the geo-replication group must use the same modules, clustering policy, eviction policy, SKU, and capacity. Flash Optimized doesn't support active geo-replication.
  • Client support varies by module. Confirm that your client library provides the module commands you need or supports issuing them through a generic command interface.

If these constraints require separate instances, define which data belongs in each instance and how the application coordinates operations across them. Don't assume that commands or transactions are atomic across instances.

Provisioning decision checklist

Before you create the instance, confirm:

  • The selected tier supports every required module.
  • The clustering and eviction policies satisfy the strictest module requirements.
  • The capacity plan includes enough headroom for NoEviction, if you enable RediSearch.
  • The module set is compatible with your active geo-replication design.
  • Every planned geo-replication group member has an identical configuration.
  • The client library supports the module commands that the application uses.
  • The selected module set covers expected future needs, because you can't add modules to the instance later.

Related content

  • Last updated on