Redis Stack indexes multiple values inside nested JSON

A JSON document can contain the property an application wants to search in several nested places. Requiring one scalar value for each indexed attribute forces the application to reshape that document or maintain an additional searchable representation. Redis Stack's latest update expands indexing to paths that produce multiple values, reducing that restriction while making the chosen path part of the query design.

Pieter Cailliau's December 7 announcement describes multi-value indexing for arrays and multiple scalar values selected by JSONPath. It also introduces suffix and infix wildcard search. The update spans several modules, but the document indexing change is particularly relevant to applications that want to retain a nested object model while searching its contents.

I like JSON storage when the document structure corresponds to the application's actual unit of data. Search support becomes more useful when it can follow that structure directly. The index still needs a deliberate definition of which values belong to an attribute and how they should be interpreted.

A JSONPath can supply more than one indexed value

The announcement gives $..color as an example that selects color properties at different levels of a document. The resulting attribute is no longer limited to one scalar location. A search can operate over values reached through that path without requiring the application to flatten them into a separate top-level field first.

The RediSearch 2.6.3 multi-value text tests make the capability more concrete. They index categories stored in an array and authors stored inside nested book objects. The paths include $.category[*] and $.books[*].authors[*], with aliases used to expose those selected values as searchable attributes.

An index definition following that tested pattern can look like this. It assumes the document keys use the book: prefix and contain an array named authors.

FT.CREATE books ON JSON PREFIX 1 book: SCHEMA $.authors[*] AS author TEXT

This is an index definition, not a change to the shape of the stored document. The path selects values, the alias names the query attribute, and TEXT chooses its search interpretation. Those decisions should remain visible when reviewing the application's schema or object-mapping annotations.

The tests also distinguish a path selecting scalar elements from one selecting an array. Both can participate in multi-value indexing, but the path's result structure matters for later query semantics. It is useful to describe the actual path instead of saying only that the document has an author field.

More values do not imply a single text ordering

The same test file checks cases where text selected from nested arrays has undefined ordering. It expects errors for certain SLOP and INORDER queries in that situation. This is a concrete limit on treating several selected strings as though they formed one ordinary text sequence.

An index can answer whether selected values match terms without necessarily assigning the positional relationship an application expects for every phrase-like query. The structure of the selected values affects that relationship. The tests preserve the distinction rather than silently inventing one ordering for arbitrary nested content.

This matters when choosing a broad recursive path. Selecting every occurrence of a property can be convenient, but it may combine values from semantically different locations. The application has to decide whether all those values really belong to the same searchable attribute. The database cannot infer that domain decision merely because the properties share a name.

The tests also exercise non-text values in a text index. They distinguish nulls from values whose types do not satisfy the selected text interpretation. Expanding the number of values a path can return makes those input-type cases more relevant. A path should select the intended kinds of values as well as the intended locations.

The test setup creates several indexes over the same documents, using different paths and aliases. It waits for those indexes before checking query results. That demonstrates another useful distinction in an example. Defining the schema and verifying the searchable result are separate steps. The existence of a stored JSON document alone does not establish that a particular index has selected the expected values. Comparing explicit query results against those known documents makes the path behavior inspectable.

Wildcards expand a separate part of the query

The announcement adds suffix and infix wildcard searches and gives examples including *vatore and ant?rez. This changes the patterns a query can express over indexed text. It is separate from the JSONPath that determines which values enter the index.

That separation is useful for application design. The index path decides the candidate attribute contents. The wildcard expression describes a match against those contents. A broader expression cannot find a value excluded by the index definition, and a broader JSONPath does not by itself choose the right match expression.

The feature also does not make every existing Redis server a search server. These operations belong to the Stack module ecosystem. An application using FT.CREATE depends on the search module and the JSON integration needed for ON JSON. Core key access remains a different interface with different capabilities.

The bundle has separate server-line options

The announcement identifies Redis Stack 6.2.6 as built on Redis 6.2 and Redis Stack 7.0.6 as a release candidate built on Redis 7.0. That distinction should survive an application's description of its deployment. A Stack bundle version and the underlying server line are related identifiers, not interchangeable names for the same release.

The article also discusses time-series aggregation improvements and a t-digest structure for approximate quantiles. Those capabilities belong to different data-processing requirements. An application adopting the JSON indexing changes does not automatically need to use those other modules or treat their accuracy models as part of text search.

I prefer to evaluate this update through the index definition an application actually needs. Multi-value paths remove a concrete limitation for nested documents, and the tagged tests show both supported selection patterns and query cases with undefined ordering. That gives the developer a specific basis for deciding which values should enter each index attribute and which search operations have meaningful semantics over them.