Moving off Flex: You can’t disable Flex on an existing database (what to do instead)

Redis Cloud Flex databases use a RAM + Flash storage model with different scaling, performance, and billing characteristics than RAM-only databases. Because of these architectural differences, Flex cannot be disabled or converted in place on an existing database.

If you need to move off Flex, the supported approach is to create a new non-Flex database and migrate your data and application traffic.

This guide covers what this limitation means, how to plan your migration, provides step-by-step instructions to move off Flex, and outlines troubleshooting steps to help you complete the transition safely.

Quick Fix

Prerequisites

• Access to the Redis Cloud Console

• Ability to create a new database under the desired plan (Essentials or Pro)

• Access to application configuration (to update connection endpoints)

• Understanding of current database configuration:

  • Dataset size (including replicas)

  • Modules/capabilities (JSON, etc.)

  • Persistence settings (AOF/RDB)

  • Security (ACLs, TLS, network access)

Step-by-Step Instructions

Step 1: Create a new non-Flex database

1. In the Redis Cloud Console, select Create Database

2. Choose a plan that supports RAM-only (non-Flex) configuration

3. Configure the database:

   • Ensure Flex / auto-tiering is NOT enabled

   • Set memory size:

     • Without replication: match dataset size

     • With replication: Size the new RAM-only database so the full primary dataset, plus replication/HA and operational overhead, fits in RAM.

   • Enable required capabilities (JSON, Search, etc.)

   • Configure:

     • Replication (HA)

     • Persistence (AOF or snapshots)

     • Security (ACLs, TLS, network rules)

4. Create the database and wait until it is active

Step 2: Match critical configuration

To avoid unexpected behavior after migration:

• Enable the same capabilities/modules

• Match eviction policy and memory behavior

• Replicate ACL users, passwords, and TLS settings

• Align Redis version and configuration where possible

Step 3: Migrate data (choose based on downtime tolerance)

Online sync (minimal downtime)

• Use replication or sync tooling where supported

• Keep source and target in sync until cutover

Backup and restore

• Take a snapshot from the Flex database

• Restore into the new database

Client-side migration

• Use tools such as:

  • redis-cli --rdb

  • redis-cli --pipe

  • Application-level export/import

• Perform during a maintenance window

Important: Ensure the new database has enough memory to hold the full dataset without Flex tiering.

Step 4: Validate the new database

Before switching traffic:

• Confirm data consistency (no missing keys)

• Monitor:

  • Memory usage

  • Latency

  • Throughput

  • Evictions

Step 5: Cut over application traffic

1. Update application connection strings to the new database endpoint (FQDN + port)

2. Roll out changes gradually if possible

3. Monitor:

   • Errors

   • Latency

   • Performance metrics

Important: You cannot reuse the existing Flex database endpoint. Applications must point to the new database.

Step 6: Decommission the Flex database

• Confirm no active connections to the old database

• Delete the Flex database to stop further charges

Troubleshooting

Key Considerations

• Flex cannot be disabled in place due to architectural differences

• Migration is required for any Flex to non-Flex transition

• All data must fit in RAM after migration

• Endpoints will change, requiring application updates during cutover

• Sizing must account for replicas and overhead, not just raw dataset size