Troubleshooting Redis Search on Flex in Redis Cloud: Common Issues and Solutions – Redis Knowledge Base

Redis Search on Flex stores search indexes on Redis Flex tiered storage while retaining hot index metadata in RAM. It uses the same Redis Search commands and client interfaces as an in-memory Redis Search database, but SSD access changes the expected latency and workload profile.

Use this guide to troubleshoot missing indexes, incomplete results, indexing lag, high query latency, and unsupported command or schema errors. Search on Flex is currently a Redis Cloud Pro Preview with a narrower feature set than in-memory Redis Search.

Quick Fix

What you see	Likely cause	What to do
Search on Flex is not available during database creation	Preview is not enabled, the subscription is not Pro, or the rollout has not reached the account	Confirm Preview enrollment and subscription eligibility.
`FT.CREATE` or `FT.SEARCH` is unknown	The database was not created with supported Search on Flex capability, or the command is sent to another endpoint	Confirm the database, endpoint, and Preview configuration.
Index creation rejects the schema	The schema uses a field or document type outside the current Cloud Preview scope	Use HASH documents with supported TEXT, TAG, or VECTOR fields.
`FT.AGGREGATE` or `FT.HYBRID` fails	The command is not currently included in the Cloud Preview	Redesign the preview test or use a compatible in-memory database.
An index exists but expected documents are missing	Document type, key prefix, field name, data type, or ingestion timing does not match the index	Check `FT.INFO`, inspect sample HASH documents, and validate the schema.
Queries are slower than an in-memory baseline	SSD-backed indexes trade RAM use for higher latency	Benchmark representative queries and review RAM-to-Flash and workload suitability.
Indexing or results lag after writes	The workload is still ingesting or the selected operation is outside current Preview behavior	Measure the delay and capture reproducible examples for the Preview team.

Current Preview scope

The Redis Cloud Pro Preview currently focuses on:

HASH documents
TEXT fields
TAG fields
VECTOR fields with HNSW or FLAT indexes
Supported SORTBY and RETURN use cases
High availability, persistence, backup, and upgrades

The following capabilities are not currently part of the Redis Cloud Preview:

JSON documents
NUMERIC fields
GEO fields
FT.AGGREGATE
FT.HYBRID
Background indexing

Preview scope can change. Confirm the current Search on Flex announcement and Redis Cloud documentation before treating an unavailable capability as a product defect.

Before you begin

Collect:

Subscription and database IDs
Database version
RAM-to-Flash configuration
Index name and complete FT.CREATE schema
Output from FT._LIST and FT.INFO <index>
Example keys that should match
Exact query and response
Query latency and concurrency
Time the behavior started in UTC

Remove sensitive field values before sharing commands or output.

Step 1: Confirm Preview eligibility and database selection

Verify:

The subscription is Redis Cloud Pro.
The Search on Flex Preview is enabled for the subscription.
The database is a Flex database created with the applicable Preview capability.
The application is connecting to that database’s endpoint.

Enabling a Preview for a subscription does not necessarily modify an existing incompatible database in place. Confirm the database itself was created with the required capability.

Step 2: Confirm Redis Search is available

Connect to the affected database and run:

FT._LIST

If the command succeeds, confirm the expected index appears.

If it returns an unknown-command error:

Confirm the endpoint.
Confirm Preview enrollment.
Confirm the database type and capabilities.
Compare the result with the Redis Cloud console.

Step 3: Validate the index schema

Run:

FT.INFO <index-name>

Confirm:

The index uses HASH documents.
The schema contains only fields supported in the current Cloud Preview.
Field names match the HASH field names exactly.
The index prefix matches the keys being written.
VECTOR configuration matches the stored vector encoding and dimensions.

If index creation fails, capture the complete command and exact error. Do not substitute an unsupported field type simply to make the command succeed unless the new schema still meets the application’s requirements.

Step 4: Investigate missing or incomplete results

For an expected result that is missing:

Read the source HASH and confirm it exists on the same database.
Confirm the key matches the index prefix.
Confirm indexed fields exist and contain the expected values.
Confirm TAG separators and query escaping match the stored value.
Confirm TEXT query syntax matches the intended tokenization.
For VECTOR queries, confirm dimensions, data type, distance metric, and binary encoding.
Review FT.INFO document and indexing statistics.

Use several known keys rather than relying on one document. This helps distinguish a schema-wide issue from a single malformed record.

Step 5: Investigate indexing lag

Record:

Time the HASH was written
Time it first appeared in results
Write rate during the test
Dataset and index size
Whether the behavior affects all or selected fields

Background indexing is not currently part of the Cloud Preview. Do not compare an operation that depends on background indexing directly with an in-memory configuration that uses different behavior.

If lag is sustained or grows under a steady workload, provide the measurements to the Preview support owner.

Step 6: Investigate high query latency

Search on Flex intentionally trades lower RAM consumption for SSD-backed index access. It is best suited to workloads that can tolerate higher latency than an all-in-memory index in exchange for larger, more economical indexes.

Compare:

Median and tail latency
Cold and repeated queries
Query concurrency
Result count
SORTBY and RETURN usage
Vector K and candidate size
RAM-to-Flash configuration
Dataset and index size

The published “10:10” design target describes an approximate product goal, not a per-query performance guarantee or service-level objective. Benchmark the application’s real queries before production use.

Workload and sizing best practices

Use representative production data and query distributions during evaluation.
Measure p95 and p99 latency, not only averages.
Separate ingestion benchmarks from query benchmarks.
Avoid returning fields and result counts the application does not need.
Confirm vector dimensions and precision are appropriate for the use case.
Leave capacity for dataset and index growth.
Revalidate performance after changing the RAM-to-Flash ratio or workload concurrency.
Keep a tested fallback plan while the feature remains in Preview.

Related to