{
  "id": "shard-placement-policy",
  "title": "Shard placement policy",
  "url": "https://redis.io/docs/latest/operate/rs/8.0/databases/memory-performance/shard-placement-policy/",
  "summary": "Detailed info about the shard placement policy.",
  "content": "In Redis Software, the location of master and replica shards on the cluster nodes can impact the database and node performance.\nMaster shards and their corresponding replica shards are always placed on separate nodes for data resiliency.\nThe shard placement policy helps to maintain optimal performance and resiliency.\n\nIn addition to the shard placement policy, considerations that determine shard placement are:\n\n- Separation of master and replica shards\n- Available persistence and Auto Tiering storage\n- [Rack-zone awareness](https://redis.io/docs/latest/operate/rs/clusters/configure/rack-zone-awareness)\n- Memory available to host the database when fully populated\n\nThe shard placement policies are:\n\n- `dense` - Place as many shards as possible on the smallest number of nodes to reduce the latency between the proxy and the database shards;\n    Recommended for Redis on RAM databases to optimize memory resources\n- `sparse` - Spread the shards across as many nodes in the cluster as possible to spread the traffic across cluster nodes;\n    Recommended for databases with Auto Tiering enabled to optimize disk resources\n\nWhen you create a Redis Software cluster, the default shard placement policy (`dense`) is assigned to all databases that you create on the cluster.\n\nYou can:\n\n- Change the default shard placement policy for the cluster to `sparse` so that the cluster applies that policy to all databases that you create\n- Change the shard placement policy for each database after the database is created\n\n## Shard placement policies\n\n### Dense shard placement policy\n\nIn the dense policy, the cluster places the database shards on as few nodes as possible.\nWhen the node is not able to host all of the shards, some shards are moved to another node to maintain optimal node health.\n\nFor example, for a database with two master and two replica shards on a cluster with three nodes and a dense shard placement policy,\nthe two master shards are hosted on one node and the two replica shards are hosted on another node.\n\nFor Redis on RAM databases without the OSS cluster API enabled, use the dense policy to optimize performance.\n\n![images/rs/dense_placement.png](https://redis.io/docs/latest/images/rs/dense_placement.png)\n\n*Figure: Three nodes with two master shards (red) and two replica shards (white) with a dense placement policy*\n\n### Sparse shard placement policy\n\nIn the sparse policy, the cluster places shards on as many nodes as possible to distribute the shards of a database across all available nodes.\nWhen all nodes have database shards, the shards are distributed evenly across the nodes to maintain optimal node health.\n\nFor example, for a database with two master and two replica shards on a cluster with three nodes and a sparse shard placement policy:\n\n- Node 1 hosts one of the master shards\n- Node 2 hosts the replica for the first master shard\n- Node 3 hosts the second master shard\n- Node 1 hosts for the replica shard for master shard 2\n\nFor Redis on RAM databases with OSS cluster API enabled and for databases with Auto Tiering enabled, use the sparse policy to optimize performance.\n\n![images/rs/sparse_placement.png](https://redis.io/docs/latest/images/rs/sparse_placement.png)\n\n*Figure: Three nodes with two master shards (red) and two replica shards (white) with a sparse placement policy*\n\n## Related articles\n\nYou can [configure the shard placement policy](https://redis.io/docs/latest/operate/rs/databases/configure/shard-placement.md) for each database.\n",
  "tags": ["docs","operate","rs"],
  "last_updated": "2026-07-23T12:00:25-05:00"
}