{
  "schema_version": 2,
  "id": "operate/rc/databases/configuration/clustering",
  "title": "Clustering Redis Databases",
  "url": "https://redis.io/docs/latest/operate/rc/databases/configuration/clustering/",
  "summary": "Redis Cloud uses clustering to manage very large databases (25 GB and larger) or high-throughput databases (25,000 ops/sec and higher). Here, you'll learn how to manage clustering and how to use hashing policies to control how data is managed.",
  "aliases": [
    "/operate/rc/concepts/clustering"
  ],
  "tags": [
    "docs",
    "operate",
    "rc"
  ],
  "last_updated": "2026-09-25T15:00:09+01:00",
  "page_type": "content",
  "content_hash": "45a0e9dcc4aee87f88459db160f166ccb66988b717f288324191a3c07b32b9b9",
  "sections": [
    {
      "id": "overview",
      "title": "Overview",
      "role": "overview",
      "text": "For very large databases, Redis Cloud distributes database data to different cloud instances.  For example:\n\n- When data grows beyond the RAM resources of a single server.\n\n    Multiple shards should be used when data grows to 25 GB (50 GB for Auto Tiering) to create multiple shards.\n\n- The operations performed against the database are CPU intensive enough to degrade performance.\n\n    Multiple shards should be used when throughput grows to 25,000 ops/sec. Clustering distributes operational load, whether to instances on the same server or across multiple servers.\n\nThis distribution is called _clustering_ because it manages the way data is distributed throughout the cluster of nodes that support the database."
    },
    {
      "id": "how-data-is-distributed",
      "title": "How data is distributed",
      "role": "content",
      "text": "A Redis Cloud cluster is a set of managed Redis processes and cloud instances,\nwith each process managing a subset of the database keyspace.\nClustering uses multiple cores and resources of multiple instances to overcome scaling challenges.\n\nIn a Redis Cloud cluster, the keyspace is partitioned into hash\nslots. At any given time a hash slot resides on and is managed by a single\nRedis server. \n\nAn instance that belongs to a cluster can manage multiple hash\nslots. This division of the key space, known as _sharding_, is achieved by\nhashing the key names, or parts of these (key hash tags), in order to\nobtain the hash slot in which a key should reside. Redis Cloud supports several [hashing policies](#manage-the-hashing-policy).\n\nEven when using multiple Redis processes, the use of a Redis\nEnterprise Cloud cluster is nearly transparent to the application that\nuses it. The cluster is accessible via a single endpoint that\nautomatically routes all operations to the relevant shards, without the\ncomplexity of a cluster-aware Redis client. This allows applications to\nbenefit from using the cluster without performing any code changes, even\nif they were not designed to use it beforehand.\n\nWhen creating or editing a Redis database on Redis Cloud, the\nsystem automatically calculates the number of shards needed based on\nthe database memory limit and required throughput."
    },
    {
      "id": "multikey-operations",
      "title": "Multi-key operations",
      "role": "content",
      "text": "Operations on multiple keys in a sharded Redis Cloud cluster\nare supported, with the following limitations:\n\n1. **Multi-key commands:** Redis offers several commands that accept\n    multiple keys as arguments. In a sharded setup, you can run multi-key commands\n    only if all the affected keys reside in the same slot (thus on the same shard).\n    This restriction applies to all mulit-key commands, including BITOP, BLPOP, BRPOP, BRPOPLPUSH, MSETNX,\n    RPOPLPUSH, SDIFF, SDIFFSTORE, SINTER, SINTERSTORE, SMOVE, SORT,\n    SUNION, XREAD, XREADGROUP, ZINTER, ZINTERSTORE, ZUNION, ZUNIONSTORE, ZDIFF, ZDIFFSTORE\n1. **Geo commands:** In GEORADIUS/GEORADIUSBYMEMBER/GEOSEARCHSTORE commands, the\n    STORE and STOREDIST options can only be used when all affected keys\n    reside in the same slot.\n1. **Transactions:** All operations within a WATCH/MULTI/EXEC block\n    should be performed on keys that are in the same slot.\n1. **Lua scripts:** All keys that are used by the script must reside in\n    the same slot and need to be provided as arguments to the\n    EVAL/EVALSHA commands (as per the Redis specification).\n1. **Renaming/Copy keys:** The use of the RENAME/RENAMENX/COPY commands is\n    allowed only when both the key's original name and its new name are\n    mapped to the same hash slot.\n1. **Variadic commands**: The use of (MGET, MSET, HMGET, HMSET, etc..)\n    and pipelining are supported with Redis Cloud cluster\n    as if it were a non-cluster DB.\n\n    [Active-Active databases](https://redis.io/docs/latest/operate/rc/databases/active-active) have stricter rules: multi-key write commands (DEL, MSET, UNLINK) can only run on keys in the same slot. Only MGET, EXISTS, and TOUCH are allowed across slots. See [Multi-key operations on Active-Active databases](https://redis.io/docs/latest/develop/using-commands/multi-key-operations#active-active-databases) for details."
    },
    {
      "id": "manage-the-hashing-policy",
      "title": "Hashing policies and hash tags",
      "role": "content",
      "text": "The hashing policy determines how data is distributed across multiple Redis processes of a database. It uses a hashing function to map keys to hash slots in these processes, ensuring an even distribution of data for optimal performance and scalability.\n\nThe hashing function uses the entire key name to calculate the hash slot, unless the key name contains a **hash tag**, represented by a `{...}` pattern.\n\nIf the key contains a `{...}` pattern, only the substring between `{` and `}` is hashed in order to obtain the hash slot.\n\nYou can use the `{...}` pattern to direct related keys to the same hash slot, so that multi-key operations are supported on them. On the other hand, not using a hashtag in the key's name results in a (statistically) even distribution of keys across the keyspace's shards, which improves resource utilization. If your application does not perform multi-key operations, you don't need to construct key names with hashtags.\n\nRedis Cloud offers 3 hashing policies, which differ in how hash tags are processed. These hashing policies are not always available.\n\nRedis Cloud defaults to the [Redis hashing policy](#redis-hashing-policy) **when creating a new database**. You can select a different hashing policy during database creation, but you cannot change the hashing policy to or from the Redis hashing policy after the database is created."
    },
    {
      "id": "redis-hashing-policy",
      "title": "Redis hashing policy",
      "role": "content",
      "text": "The Redis hashing policy is identical to the [hashing policy used by Redis Open Source](https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec#hash-tags). This policy is recommended for most users and you should select it if any of the following conditions apply:\n- This is your first Redis Cloud account, and you are starting fresh.\n- You are migrating data from Redis Open Source or other Redis-managed platforms.\n- Your application does not use hashtags in database key names.\n- Your application uses binary data as key names.\n\nThe Redis hashing policy allows for [Smooth Scaling](#smooth-scaling) where available."
    },
    {
      "id": "standard-hashing-policy",
      "title": "Standard hashing policy",
      "role": "content",
      "text": "The Standard hashing policy is mostly consistent with the Redis hashing policy, and will generate the same hash-slot calculation in the following cases:\n1. Keys with a single hashtag: a key's hashtag is any substring between '{' and '}' in the key's name. That means that when a key's name includes the pattern '{...}', the hashtag is used as input for the hashing function. For example, the following key names have the same hashtag and are mapped to the same slot: foo{bar}, {bar}baz & foo{bar}baz.\n1. Keys without a hashtag: when a key doesn't contain the '{...}' pattern, the entire key's name is used for hashing\n\nIn some cases, the Standard hashing policy behaves differently from the Redis hashing policy:\n1. Using empty hashtags (\"{}\"): the Standard hashing policy does not ignore empty hashtags, so two keys that start with empty hashtags will be hashed to the same hashslot (while the Redis hashing policy would ignore them). \n    For example: given 2 keys {}foo and {}bar, hashing would be:\n    - Standard hashing policy: to the same hash slot\n    - Redis hashing policy: to different hash slots\n2. Using multiple curly brackets: when a key’s name contains multiple curly brackets, the Standard hashing calculation might be different than the Redis hashing policy. \n    For example: given 2 keys {foo}bar} and {foo}qux}:\n    - Standard hashing policy: substrings \"foo}bar\" and \"foo}qux\" will be used for the 1st and 2nd key respectively, hashed each key to a different hash-slot.\n    - Redis hashing policy: the substring \"foo\" will be used for both keys, hashing them to the same slot.\n\n> [!NOTE]\n> To allow seamless transition between hashing policies, the following techniques are not recommended:\n> - Using empty hashtags to hash different keys to the same hashslot\n> - Using multiple curly brackets within a key’s name"
    },
    {
      "id": "custom-hashing-policy",
      "title": "Custom hashing policy",
      "role": "content",
      "text": "> [!NOTE]\n> The custom hashing policy is not available for accounts created after March 31, 2025.\n>\n> For all other accounts, this policy is not recommended and will be deprecated in the future. Select this option only if you are already using a custom hashing policy with your existing Redis Cloud databases.\n\nA Redis Cloud  cluster can be configured to use a custom hashing\npolicy. A custom hashing policy is required when different keys need to\nbe kept together on the same shard to allow multi-key operations. Redis\nCloud's custom hashing policy is provided via a set of Perl\nCompatible Regular Expressions (PCRE) rules that describe the dataset's\nkey name patterns.\n\nTo configure a custom hashing policy, enter regular expression (RegEx)\nrules that identify the substring in the key's name - hashtag - on\nwhich hashing will be done. The hashing tag is denoted in the RegEx by\nthe use of the \\`tag\\` named subpattern. Different keys that have the\nsame hashtag will be stored and managed in the same slot.\n\nOnce you enable the custom hashing policy, the Redis Cloud's\ndefault RegEx rules that implement the standard hashing policy are:\n\n| RegEx Rule | Description |\n|-----------|-----------------|\n| .\\*{(?\\<tag\\>.\\*)}.\\* | Hashing is done on the substring between the curly braces. |\n| (?\\<tag\\>.\\*) | The entire key's name is used for hashing. |\n\nYou can modify existing rules, add new ones, delete rules, or change\ntheir order to suit your application's requirements.\n\n> [!WARNING]\n> If the Custom hashing policy is available, you can change the hashing policy between Standard and Custom after you create your database. However, hashing policy changes delete existing data \n> (using [`FLUSHDB`](https://redis.io/docs/latest/commands/flushdb)) before they're applied. \n>\n> These changes include:\n>\n> 1. Changing the hashing policy, either from standard to custom or vice versa.\n> 1. Changing the order of custom hashing policy rules.\n> 1. Adding rules before existing ones in the custom hashing policy.\n> 1. Deleting rules from the custom hashing policy.\n> 1. Disabling clustering for the database."
    },
    {
      "id": "custom-hashing-policy-notes-and-limitations",
      "title": "Custom hashing policy notes and limitations",
      "role": "content",
      "text": "1. You can define up to 32 RegEx rules, each up to 256 characters.\n1. RegEx rules are evaluated by their order.\n1. The first rule matched is used; strive to place common key name\n    patterns at the beginning of the rule list.\n1. Key names that do not match any of the RegEx rules trigger an\n    error.\n1. The '.\\*(?\\<tag\\>)' RegEx rule forces keys into a single slot as the\n    hash key is always empty. When used, this should be the last\n    catch-all rule.\n1. The following flag is enabled in our regular expression parser:\n   - **PCRE_ANCHORED:** the pattern is constrained to match only at\n        the start of the string which is being searched."
    },
    {
      "id": "oss-cluster-api",
      "title": "OSS Cluster API",
      "role": "content",
      "text": "OSS Cluster API reduces access times and latency with near-linear scalability.\nThe OSS Cluster API provides a simple mechanism for Redis clients to know the cluster topology.\n\nClients must first connect to the master node to get the cluster topology,\nand then they connect directly to the Redis proxy on each node that hosts a master shard.\n\n> [!NOTE]\n> You must use a client that supports the cluster API to connect to a database\n> that has the cluster API enabled.\n\n\nThe OSS Cluster API is only supported on Redis Cloud Pro databases. You can enable it in the **Performance** section of the configuration screen.\n\nAfter you select OSS Cluster API, you can select **Use external endpoint** if you want to use the external endpoint for the database. Selecting **Use external endpoint** will block the private endpoint for this database.\n\nThe OSS Cluster API is supported when a database uses the [standard hashing policy](#standard-hashing-policy) or the [Redis hashing policy](#redis-hashing-policy).\n\nReview [OSS Cluster API architecture](https://redis.io/docs/latest/operate/rs/clusters/optimize/oss-cluster-api) to determine if you should enable this feature for your database."
    },
    {
      "id": "smooth-scaling",
      "title": "Smooth scaling",
      "role": "content",
      "text": "Smooth scaling is an improved resharding method for Redis Cloud Pro databases. Compared to traditional resharding, it is significantly faster and reduces latency spikes and disconnects during scaling.\n\n> [!NOTE]\n> Smooth scaling is available for databases that meet the following prerequisites. Other databases continue to use traditional scaling."
    },
    {
      "id": "prerequisites",
      "title": "Prerequisites",
      "role": "content",
      "text": "Smooth scaling is used automatically when a database meets all of the following conditions:\n\n| Requirement | Detail |\n|---|---|\n| Hashing policy | Must use the [Redis hashing policy](#redis-hashing-policy). Databases using the Standard or Custom hashing policy use traditional scaling instead. |\n| Database version | Redis 8.4 or later. |"
    },
    {
      "id": "not-supported",
      "title": "Not supported",
      "role": "content",
      "text": "Smooth scaling is not available for:\n\n- Active-Active databases\n- Flex (Auto Tiering) databases\n- Existing databases that use the Standard or Custom hashing policy"
    },
    {
      "id": "backward-compatibility",
      "title": "Backward compatibility",
      "role": "content",
      "text": "You do not need to make any changes to your application code. The changes related to smooth scaling are implemented internally and do not affect RESP commands or how clients connect to and communicate with the database."
    }
  ],
  "examples": []
}