Why am I seeing a clustering warning when scaling my Redis Cloud database?

If you're increasing the size of your Redis Cloud database and see a clustering warning, you may be wondering:

• Why you're receiving the warning.

• Whether your application will continue to work.

• Whether you can still use a standalone database.

• Why a newly created database of the same size might not show the same warning.

In most cases, the warning is informational and does not mean the resize operation will fail. It indicates that Redis Cloud may need to distribute data across multiple shards, which can affect some application behaviors.

This article explains what the warning means, what changes after scaling, and how to validate your application before making changes in production.

Quick Fix

Why am I seeing this warning?

When you increase the size of an existing database, Redis Cloud evaluates whether additional shards may be required.

If the resize operation changes how data is distributed, Redis Cloud displays a clustering warning before applying the change.

The warning exists because some application behaviors should be reviewed before moving to a multi-shard configuration.

The warning does not mean the resize operation will fail.

My new database didn't show the warning. Is it still clustered?

Possibly.

Customers often notice that resizing an existing database displays a clustering warning, while creating a new database of the same size does not.

This behavior is expected.

When you resize an existing database, Redis Cloud is warning about a potential topology change.

When you create a new database, Redis Cloud provisions it directly in its target configuration. Because there is no transition occurring, there may be no equivalent warning during creation.

Do not assume a database is standalone simply because no warning was displayed.

Can I still use a standalone database at larger sizes?

Do not assume that a database remains single-sharded based solely on its size or because it was created successfully without a warning.

Depending on your deployment model and selected configuration, Redis Cloud may provision the database using one or more shards based on factors such as:

• Database size

• Performance requirements

• Deployment configuration

Based on those requirements, Redis Cloud may provision multiple shards automatically.

If you need to understand how your database is configured, review the database settings in the Redis Cloud Console after provisioning.

Will my commands still work?

In many cases, yes.

Most applications continue to function normally after scaling.

However, operations involving multiple keys may require additional validation.

Examples include:

• Multi-key operations

• Transactions using WATCH, MULTI, and EXEC

• Lua scripts that operate on multiple keys

• RENAME

• RENAMENX

• COPY

Important: Some multi-key commands continue to work

Customers often test a command such as:

DEL key1 key2 key3

and assume:

The command worked, so the database must still be standalone.

That conclusion is not necessarily correct.

Some multi-key commands remain supported in clustered deployments. However, support depends on the specific command and, in many cases, whether all referenced keys are in the same hash slot. Refer to the Redis Cloud clustering documentation for complete command compatibility details.

A successful DEL operation does not indicate whether a database is single-sharded or multi-sharded.

Refer to the Redis Cloud clustering documentation for complete command compatibility details.

How can I test before changing production?

Before enabling clustering or scaling a production database, we recommend:

• Reviewing application code for multi-key operations.

• Reviewing Lua scripts that access multiple keys.

• Reviewing transactions that use WATCH, MULTI, or EXEC.

• Reviewing RENAME, RENAMENX, and COPY usage.

• Testing workloads against a non-production database.

• Monitoring for CROSSSLOT errors during validation.

This process helps identify compatibility issues before production rollout.

What are hash tags and when should I use them?

If your application needs related keys to remain together, you can use hash tags.

When a key contains text enclosed in braces ({}), Redis uses only that portion of the key when determining placement.

For example:

user:{123}:profile
user:{123}:settings

Because both keys use the same hash tag, they are placed together and can be used in operations that require keys to be in the same slot.

Should I resize my existing database or create a new one?

Both approaches are valid. The best choice depends on your migration strategy and operational requirements.

Can I go back to a single-shard database later?

No.

Once clustering is enabled on a Redis Cloud database, it cannot be disabled in place.

If you later need a different topology, create a new database and migrate your data.

Because of this limitation, we recommend validating application compatibility before enabling clustering on production workloads.

Frequently Asked Questions

I received a clustering warning. Does that mean my application will break?

No.

The warning indicates that the database configuration may change. Many applications continue to work normally after scaling.

Review multi-key operations, transactions, and scripts before proceeding.

My DEL command still works after scaling. Is the database clustered?

Possibly.

Some multi-key commands continue to work in multi-shard environments. DEL is not a reliable indicator of whether a database is single-sharded or multi-sharded.

I created a larger database and did not receive a clustering warning. Is it standalone?

Not necessarily.

A newly created database may be provisioned directly in a multi-shard configuration.

Review the database configuration after creation to determine how it has been provisioned.

Can I disable clustering later?

No.

If you need a different topology later, create a new database and migrate your data.