Reduce Redis Shard Count by Creating a New Database and Migrating Data

Redis shard count cannot be reduced on an existing database. Once a Redis Cloud or Redis Software clustered database is created, you can only increase the shard count (by a multiple of the current number of shards), not decrease it. To move to fewer shards, you must create a new database with the desired shard count and migrate your data. If you need fewer shards, the supported approach is to create a new database with the desired shard count and migrate your data to it, then cut application traffic over.

This article explains why shard reduction is not supported in place, outlines a clear migration workflow, and walks through supported migration options, validation steps, and cutover considerations so you can reduce shard count safely and predictably.

Quick answer

You can’t reduce the shard count in place.
To reduce shards, you must:

1. Create a new database with fewer shards

2. Migrate data to it

3. Cut traffic over to the new database

Quick Fix: Reducing shard count

Why Can't the Shard be Reduced in Place?

Redis distributes data across shards using hash slots. Reducing shard count would require redistributing all data across fewer shards while maintaining consistency, performance, and availability. This operation is not supported in Redis Cloud or Redis Software.

Key constraints

• Shard count can only be increased by a multiple of the current shard count (for example, from 3 to 6, 9, or 12 shards). Doubling (2x) is the most common pattern.

• There is no supported “scale down” or “unshard” operation.

• Any shard reduction requires creating a new database and migrating data.

Migration flow

1. Plan capacity, compatibility, and timing

2. Create a new database with fewer shards

3. Migrate data using a supported method

4. Validate data and application behavior

5. Cut over application traffic

6. Decommission the old database when safe

Prerequisites

• An existing Redis Cloud or Redis Software database

• Capacity to temporarily run two databases during migration

• Access to Redis Cloud Console or Redis Enterprise admin tools

• A maintenance window if brief write freeze or downtime is required

Migration Steps

Step 1: Plan and validate

Before creating the target database, validate the following:

Capacity and performance

• Fewer shards mean fewer CPU cores and network paths

• Ensure the target database can handle peak load and memory requirements

Version and configuration alignment

• Use the same or a newer Redis version

• Align persistence, eviction policy, TLS, authentication, ACLs, and timeouts

Networking and security

• Confirm VPC or VNet connectivity

• Validate IP allowlists, firewall rules, TLS certificates, and credentials

Feature usage

• Plan to recreate modules, ACL users, Lua scripts, Redis 7 functions, and Streams consumer groups if used.

• Confirm that your application is cluster-aware and that any multi-key operations only target keys that hash to the same slot (or use hashtags where required). Changing the shard count changes the hash-slot layout.

Step 2: Create the target database

Create a new Redis database with the desired shard count.

Match these settings as closely as possible:

• Redis version and modules

• Persistence configuration (RDB and or AOF)

• maxmemory and eviction policy

• TLS and authentication configuration

• ACL users and permissions

Record the new endpoints and credentials. For cluster mode, ensure clients can refresh slot mappings.

Step 3: How should I migrate my data?

Choose the migration method that best fits your downtime tolerance and complexity requirements.

Option A: Backup and restore (downtime required)

Best when: Downtime is acceptable
Complexity: Low
Risk: Low

Process

1. Quiesce writes to the source database

2. Take a final backup or snapshot

3. Restore the backup into the new database

4. Validate data and application behavior

5. Cut traffic over to the new database

Notes

• RDB restores include keys, TTLs, Streams, consumer groups, scripts, and functions.

• Pub/Sub subscriptions and live client connections do not migrate.

• Use the platform’s restore workflow where required

Option B: Live copy or sync (low downtime)

Best when: Downtime must be minimized
Complexity: Medium to high
Risk: Medium

Common approaches include:

• Redis-to-Redis migration tools that support full sync plus incremental sync

• Custom scripts using SCAN with DUMP and RESTORE or MIGRATE

Key considerations

• Preserve TTLs during copy

• Ensure clients are cluster‑aware and can refresh cluster topology after cutover.

• Run a final delta sync or brief write freeze before cutover

• Explicitly migrate scripts and Redis 7 functions if needed

Option C: Application-driven rebuild (cache-only workloads)

Best when: Redis is used strictly as a cache
Complexity: Low
Risk: Low

Approach

1. Create the new database

2. Redirect reads and writes to it

3. Allow the cache to warm naturally

Step 4: Validate before cutover

Data validation checklist

• Key count roughly matches the source

• Memory usage is within the expected range

• TTLs are preserved on sampled keys

• Scripts, functions, modules, and ACLs exist

• Application read and write paths behave as expected

Step 5: Cut over traffic

Recommended cutover process

1. Announce a maintenance window if required

2. Pause heavy writers or run a final delta sync

3. Update application endpoints or DNS records

4. Restart or roll applications to refresh connections

5. Monitor latency, errors, evictions, CPU, and memory

Keep the source database idle or read-only for rollback until confidence is high.

Common gotchas

• Client shard awareness
  Clients must refresh the cluster topology. Restart applications or clear cached slot mappings.

• ACLs and authentication
  Users and permissions must be recreated on the target before cutover.

• Pub/Sub and keyspace notifications
  Subscriptions do not migrate. Applications must resubscribe.

• Eviction behavior
  Fewer shards can change memory pressure. Match eviction policy unless intentionally changing behavior.

• Module compatibility
  Ensure the same module versions are installed on the target database.

Frequently asked questions

• Can I reduce shard count directly on my existing database?

  • No. Reducing the shard count in place is not supported.

• Can I restore a backup from a larger cluster into a smaller one?

  • Often yes, if your platform supports restoring backups to a different database. Data is rebalanced automatically across the new shard layout.

• How long does migration take?

  • It depends on data size, key types, throughput, and downtime tolerance. Test with a representative subset to estimate duration.

Advanced: Script-based migration (optional)

• Iterate keys using SCAN with small COUNT values

• Use DUMP and RESTORE with TTL preservation

• Perform a final delta sync before cutover

• Avoid long-running pipelines that can exceed timeouts