Redis opens its searchable JSON document store preview
RedisJSON and RediSearch combine document operations with content-based discovery. The public preview extends an existing JSON command model whose paths, serialized results and update operations have explicit semantics.
Storing a JSON document and finding documents by their contents are different database capabilities. A key can identify one document without providing an index over its nested values. Redis's searchable document-store preview combines RedisJSON's document operations with RediSearch's indexing. The useful architectural change is that the search component can consume structured JSON values through an interface between the modules.
The November 16 announcement introduces the combination as a public preview. It describes RedisJSON as a source-available document store powered by RediSearch for searching. The event concerns these additional modules, not a change that makes every ordinary Redis server a JSON document database. Its preview status is also distinct from general availability.
I have used Redis since its early releases, and I find the distinction between storage and discovery useful when assessing a new data model. Direct key access is often sufficient. When an application needs to find records by nested attributes, the design acquires an indexing requirement as well as a document representation.
JSON operations already have a document model
The earlier RedisJSON 1.0 documentation, then named ReJSON, describes a native JSON module with documents stored as binary trees. It supports selecting sub-elements through a JSONPath-like syntax and typed atomic operations on JSON values. This predates the searchable preview and supplies useful background for what the search integration builds upon.
The 1.0 command reference distinguishes JSON objects and arrays from scalar values. A document can therefore contain structured values that the server understands. An opaque string containing serialized JSON does not by itself provide those module operations on its sub-elements.
The command reference describes JSON.SET as setting a value at a path. New keys require the root path. For an existing key, an existing path can be replaced. The NX and XX options condition the change on whether the target exists. These rules define which updates the command expresses without requiring an application to reconstruct the entire document manually.
This legacy example illustrates those established path operations rather than a new multi-match JSONPath feature:
JSON.SET product:example . '{"name":"Example","stock":4}'
JSON.NUMINCRBY product:example .stock 2
JSON.GET product:example .stock
The commands create a document, increment its numeric stock field and retrieve that field. Their significance is the unit of work. The increment names a numeric value within a document instead of requiring the client to fetch a string, parse it, modify it and replace the whole value.
Reply representation remains part of the API
The legacy reference says JSON.GET returns a JSON-serialized value. JSON.NUMINCRBY returns the stringified new numeric value as a bulk string. Those replies should not be confused with Redis integer replies merely because the represented value is numeric. Client decoding still needs to respect the command's response representation.
JSON.MGET reads a path from several keys and reports nonexistent keys or paths as null. This distinguishes a multi-key document operation from a search query. The caller already supplies the keys. Asking for values at a path does not discover every document containing a matching value.
The reference also defines the effect of deleting the root as deleting the Redis key. Deleting a nested path has a narrower target. These operations need different interpretations in application code even though both use JSON.DEL. The path determines whether the operation removes the whole document or only one of its values.
I appreciate that the model makes these choices explicit. A document API can be concise without concealing which part of a stored value changes. The path and reply form provide the information needed to connect a server operation to the application's intended update.
Indexing consumes JSON values through a module interface
The July preview explanation describes the integration between RedisJSON and RediSearch. RedisJSON exposes an API to other modules running inside the node. RediSearch consumes that API to index document contents. Index schemas accept JSONPath expressions and associate their results with searchable attributes.
That is the connection between document addressing and cross-document discovery. A JSONPath expression selects values within a document. An index records those selected values so a query can locate documents by content. The same expression can participate in both tasks without making them the same operation.
The July explanation also describes aggregation loading JSON values into a pipeline and using indexed attributes for query purposes. Those facilities add query behavior around documents. They do not remove the need to decide which values an index should expose or which types of matching the application requires.
The older RediSearch 2.0 README provides context for the search side. It describes compressed inverted indexes, full-text matching and numeric filtering. Its capabilities also include exact-match tag fields and sortable properties. These are distinct query mechanisms, so a document attribute's indexing choice affects how a caller can search it.
The legacy API includes array-specific updates too. JSON.ARRAPPEND appends values and returns the resulting array size, while JSON.ARRPOP removes and returns a selected element. Those operations give an application explicit array semantics within the document.
The module boundary affects deployment
The module combination is a separate deployment dependency from core Redis. RedisJSON supplies document representation and updates. RediSearch supplies the search implementation and its index definitions. The public preview makes that combination available to a broader audience without implying that every client library or bare server installation already provides the corresponding commands.
The existing command documentation also shows why result size and update scope should remain explicit. Reading one nested value serializes that value, while retrieving a whole document serializes the root. A query that discovers document identities and a command that retrieves a selected document path solve different application steps.
For an application considering the preview, the concrete addition is content-based discovery over structured documents. The established JSON commands identify where values live and how they change. The module interface lets RediSearch consume selected values for indexing, which connects those per-document operations to queries across the collection.