RedisInsight v1.8, November 2020

Summary: RedisInsight v1.8.0

1.8.3 (January 2021)

This is a maintenance release of RedisInsight 1.8 (v1.8.3)!

This fixes the crash on MacOS Big Sur (11.1) for the MacOS package.
RedisInsight is supported on Mac hardware with Intel chips, but not for Mac hardware with the Apple M1 (ARM) chip.

1.8.2 (24 December 2020)

This is the maintenance release of RedisInsight 1.8 (v1.8.2)!

Fixes:

- Browser:
    - Improved handling of large strings, lists, hashes, sets and sorted sets.
    - Better error message when loading a key's value fails.
    - More robust handling of Java serialized objects - malformed Java serialized objects are now displayed as binary strings.
    - Increased the default width of the key selector.
- Memory Analysis:
    - Fixed crash on databases with modules that store auxiliary module data in the RDB (RediSearch 2, RedisGears, etc.).
    - Fix integer overflow which results in the size of large keys not being reported properly.
    - Add Streams statistics to the charts shown in the Memory Analysis Overview tool.
    - Better error message when online analysis fails due to both the `SYNC` and `DUMP` commands being unavailable.

1.8.1 (17 December 2020)

Maintenance release for RedisInsight 1.8 including bug fixes and enhancements.

Important Note:

We'd love to learn more how you are using RedisInsight. Now we have a user survey in the application, but you can also get to it [here](https://www.surveymonkey.com/r/ZZVR2ZG).

Fixes:

- Core:
    - Fixed placeholder page for modules which was not appearing on desktop packagings of RedisInsight.
    - Fixed error in handling disconnection to databases on desktop packaging of RedisInsight.
    - Fixed auto-fill-on-URL-paste when adding Redis databases.
    - Fixed add database form: scroll to error message if adding a database fails.
    - Fixed typo in Settings page.
- CLI:
    - Fixed on the repeat command option which was not properly cleared when the command was changed.

1.8.0 (November 2020)

This is the General Availability Release of RedisInsight 1.8 (v1.8.0)!

Important Note:

We'd love to learn more how you are using RedisInsight. We introduce a user survey, you'll see it in the application, but it's happening [here](https://www.surveymonkey.com/r/ZZVR2ZG).

Headlines:

- Guided experience to get started with RedisInsight, add a database and experiment with modules
- CLI now supports "help" commands and lets you repeat commands
- Ability to provide your CA Certificate and skip-verify option for TLS authentications
- Ability to display RediSearch indices summary
- Adding a database is getting simpler by auto-filling all database information from the Redis connection URL
- New environment variables for configuring HOST, PORT and application LOG LEVEL
- Support for RedisJSON on Redis Cluster

Full Details:

- Core:
    - New welcome page when no databases are configured
    - New information pages for each modules, when they are not configured
    - New environment variables for configuring HOST, PORT and application LOG LEVEL
    - Ability to add a CA Certificate and skip-verify for TLS authentications
    - Added auto-filling database details from Redis Connection URL
- Browser:
    - Added error message when trying to visualize large keys
    - Fixed issue when copying key with " character
- RedisGraph, RediSearch, RedisTimeseries:
    - Added ability to copy commands with a button click
- RedisSearch:
    - Display the selected Index's Summary
- RedisGraph:
    - Added ability to persist nodes display choices between queries
- ReJSON:
    - Support for RedisJSON on Redis Cluster
- ClientList:
    - Sort clients by type
- CLI:
    - Added support for the `help` command in CLI
    - Added ability to repeat commands multiple times with increments
    - Added the ability to close the Hint window
    - Added stream command assists
- Profiler:
    - Fixed issue with TLS databases


RedisInsight v1.9, January 2021

Summary: RedisInsight v1.9.0

1.9.0 (January 2021)

This is the General Availability Release of RedisInsight 1.9 (v1.9.0)!

Headlines:

- RedisGraph tools is getting improved with better UX and new interactions capabilities
- Adding the ability to configure a database, by just using its direct URL to auto fill all required fields
- CLI is now providing ability to configure your favorite key-bindings between Emacs or Vim

Full Details:

- Core:
    - Support for configuration of Redis where the number of databases goes over the default 16.
    - Ability to add a Redis database using a shareable URL.
- RedisGraph
    - UX improvements for large queries: fixed long pause while results are being rendered.
    - Made various improvements to interactions with the graph visualization:
    - Selected node's size increased to make it easier to distinguish.
    - Zoom via mouse wheel.
    - Double click to zoom in.
    - Double right-click to zoom out.
    - Keyboard shortcuts to zoom.
    - Center on node on fetching direct neighbours.
    - Halo masking indirect edges on selected node.
    - Button to reset view: center entire graph.
    - Button to center on the selected node.
    - New zoom buttons
- CLI
    - Basic navigation key-bindings for Emacs and Vim.
    - UX improvements: the inputs and other controls are now disabled and a message is shown while the command is executing.


RedisInsight v2.0, Nov 2021

Summary: RedisInsight v2.0.2

2.0.6 (April 2022)

This is the General Availability (GA) release of RedisInsight 2.0.6

Headlines:

- SNI support - added SNI support to indicate a hostname in the TLS handshake
- Save Profiler logs into a file - now you can save and download Profiler logs into a .TXT file
- Customize delimiters in Tree view - added support for custom delimiters in Tree view
- Support for node grouping and pulsing in RedisGraph visualizations in Workbench

Details

**Features and improvements:**
- [#548](https://github.com/RedisInsight/RedisInsight/pull/548), [#542](https://github.com/RedisInsight/RedisInsight/pull/542) Added SNI support - use the "Add Database Manually" form to see the new "Use SNI" option under the TLS section to specify the server name and connect to your Redis Database
- [#521](https://github.com/RedisInsight/RedisInsight/pull/521/files) Added an option to save Profiler logs. Enable saving before starting the Profiler to save the logs into a .TXT file and download it to analyze them outside of the application
- [#496](https://github.com/RedisInsight/RedisInsight/pull/496) Now you can specify your own delimiters to work with namespaces in the Tree view, default delimiter is colon (':')
- [#473](https://github.com/RedisInsight/RedisInsight/pull/473) Added a link to GitHub repository of RedisInsight to quickly find and access it - you can see the icon below the "Settings"
- [#586](https://github.com/RedisInsight/RedisInsight/pull/586) Added support for node grouping and pulsing in the visualisations for RedisGraph in Workbench
- [#455](https://github.com/RedisInsight/RedisInsight/pull/455) Limited the movement of the special editor with Cypher highlights to Workbench Editor area (to work with it, just type in RedisGraph commands in Workbench)
- [#462](https://github.com/RedisInsight/RedisInsight/pull/462) Provided additional information about database indexes in the form to add a database using host and port
- [#489](https://github.com/RedisInsight/RedisInsight/pull/489) Reworked user experience with filters per key type and key name in Browser
- [#535](https://github.com/RedisInsight/RedisInsight/pull/535) Added highlights of timestamps and improved text wrapping in Profiler

Bug fixes:

- [#581](https://github.com/RedisInsight/RedisInsight/pull/581) Fixed the issue with displaying keys in multi-shard databases
- [#576](https://github.com/RedisInsight/RedisInsight/pull/576) Fixed encoding in Workbench

2.0.5 (March 2022, GA)

Headlines

* **Tree view** - A new view of the keys in Browser, which automatically groups keys scanned in your database into folders based on key namespaces. Now you can navigate through and analyze your list of keys quicker by opening only folders with namespaces you want.
* **Support for Apple M1 (arm64)** - You can download it [here](https://redis.com/redis-enterprise/redis-insight/#insight-form).
* **Added auto-discovery of local databases** - RedisInsight will automatically find and add your local databases when you open the application for the first time.
* **A dedicated Editor for Cypher syntax** - Workbench supports autocomplete and highlighting of Cypher syntax for RedisGraph queries.

Details

- You can switch to the Tree view in Browser to see all the keys grouped into folders according to their namespaces. Note that we use the colon (:) as a default separator, and it is not customizable yet.
- Added support for Apple M1 (arm64).
- Added a mechanism to auto-discover local databases based on the following parameters:
  - The mechanism only triggers when you open the application for the first time.
  - The database has standalone connection type.
  - The database uses the default username and requires no password or TLS certificates.
- Added new built-in guides in Workbench for additional capabilities.
- Added tutorials in Workbench for Redis Stack databases that describe common use cases for Redis capabilities.
- Added a new dedicated Editor to Workbench with support for Cypher syntax autocomplete and highlighting. Use the "Shift+Space" shortcut inside of the quotes for your query to open the dedicated Editor.
- Show modules uploaded to databases in the list of databases.
- Added support for returning to the previous command in Workbench Editor. Use arrow up when your cursor is at the beginning of the first row to return to the previous command. Note: there is no support for the reverse direction yet, so use it with caution.

If you installed RedisInsight-preview before, this folder will still exist at the following path:
* For MacOs: <usersHomeDir>/.redisinsight-preview
* For Windows: C:/Users/{Username}/.redisinsight-preview
* For Linux: <usersHomeDir>/.redisinsight-preview

2.0.4 (February 2022)

This is the maintenance release of RedisInsight Preview 2.0 (v2.0.4)!

Headlines

- Fixes to the issues found
- Profiler
  - Added RedisInsight Profiler, which uses the MONITOR command to analyze every command sent to the redis instance in real-time.
- Workbench:
  - Added support for RedisGears and RedisBloom on the intelligent Redis command auto-complete.
  - Keep command results previously received in the Workbench.
  - Support for repeating commands.
- CLI:
  - Added support for RedisGears and RedisBloom on the intelligent Redis command auto-complete.
  - Support for repeating commands.
- Command Helper:
  - Added information about RedisGears and RedisBloom Redis commands.

Details

- Profiler
  - Added RedisInsight Profiler, which uses the MONITOR command to analyze every command sent to the redis instance in real-time. Note: Running the MONITOR command is dangerous to the performance of your production server, so run it reasonably and remember to stop the Profiler.
- Workbench:
  - Added support for RedisGears and RedisBloom on the intelligent Redis command auto-complete, so the list of similar commands and their arguments are displayed when you start typing any RedisGears or RedisBloom commands.
  - Keep command results (up to 1MB) previously received in the Workbench, so they are available even after you restart the application.
  - Connect Workbench to the database index selected when adding a database.
  - To repeat any command in Workbench, just enter any integer and then a Redis command with arguments.
- CLI:
  - Added support for RedisGears and RedisBloom on the intelligent Redis command auto-complete, so hints with arguments are displayed when you enter any RedisGears or RedisBloom commands
  - CLI is by default connected to the database index selected when adding a database. Added displaying of the database index connected.
  - To repeat any command in CLI, just enter any integer and then a Redis command with arguments.
- Command Helper:
  - Added information about RedisGears and RedisBloom Redis commands.
- Core:
  - Fixed an issue with displaying parameter values in the Overview when no information is received for these parameters.

2.0.3 (December 2021)

This is the maintenance release of RedisInsight Preview 2.0 (v2.0.3).

Headlines

- Workbench:
  - Added indications of commands
  - New hints with the list of command arguments
  - Reworked navigation for the built-in guides
- Help Center:
  - Added a page with list of supported keyboard shortcuts
- Core:
  - Uncoupled Command Helper from CLI
  - Renamed `ZSET` to Sorted Set

Details

- Browser:
  - Changed the format of TTL in the list of keys
- CLI:
  - Fixed a bug with `FT.CREATE` command that rendered the window blank
- Workbench:
  - Fixed a bug to avoid executing the Redis command one more time when the view of results is changed
  - Added a new information message when there are no results to display
  - Added indications of commands (currently, not clickable) in Editor area to point out the lines where commands start
  - Added new hints in Editor to display the list of command arguments with the following keyboard shortcuts:
    - Ctrl+Shift+Space for Windows and Linux
    - ⌘ ⇧ Space for Mac
  - Added support for remembering the state (expanded or collapsed) for left side panel in Workbench
  - Reworked navigation for the built-in guides
  - Changed icons for default and custom plugins
- Command Helper:
  - Changed titles of command groups to make them consistent with redis.io
- Help Center:
  - Added a page with supported keyboard shortcuts
- Core:
  - Reworked logic to open CLI and Command Helper, added an option to open Command Helper without a need to open CLI
  - Changed fonts and colors across the application to enhance readability
  - Renamed `ZSET` to Sorted Set
  - Added description of RedisGears and RedisBloom commands to hints in CLI, Command Helper, and Workbench
  - Added support for automatic updates to the list of commands and their description in CLI, Command Helper, and Workbench

2.0.2 (November 2021)

This is the public preview release of RedisInsight 2.0 (v2.0.2).

RedisInsight 2.0 is a complete product rewrite based on a new tech stack. This version contains a number of must-have and most-used capabilities from previous releases, plus a number of differentiators and delights.

RedisInsight-preview 2.0 can be installed along with the current GA (1.11) version of RedisInsight with no issues.

Headlines

- Developed using a new tech stack based on Electron, Elastic UI, and Monaco Editor
- Introducing Workbench - advanced command line interface with intelligent command auto-complete and complex data visualizations
- Ability to write and render your own data visualizations within Workbench
- Built-in click-through Redis guides available
- Support for Light and Dark themes
- Enhanced user experience with Browser

Details

- Core:
  - Enhanced user experience with the list of databases:
    - View, sort and edit databases added
    - Multiple deletion of databases
  - Ability to connect to Redis Standalone, Redis Cluster and Redis Sentinel
  - Auto discovery of databases managed by Redis Software, Redis Cloud (Flexible), and Redis Sentinel
  - Support for Redis OSS Cluster API
  - Support for TLS connection
  - Works with Microsoft Azure (official support upcoming)
- Workbench:
  - Advanced command-line interface that lets you run commands against your Redis server
  - Workbench editor allows comments, multi-line formatting and multi-command execution
  - Intelligent Redis command auto-complete and syntax highlighting with support for [RediSearch](https://oss.redis.com/redisearch/), [RedisJSON](https://oss.redis.com/redisjson/), [RedisGraph](https://oss.redis.com/redisgraph/), [RedisTimeSeries](https://oss.redis.com/redistimeseries/), [RedisGears](), [RedisAI](https://oss.redis.com/redisai/), [RedisBloom](https://oss.redis.com/redisbloom/)
  - Allows rendering custom data visualization per Redis command using externally developed plugins
- Browser:
  - Browse, filter and visualize key-value Redis data structures
    - Visual cues per data type
    - Quick view of size and ttl in the main browser view
    - Ability to filter by pattern and/or data type
    - Ability to change the number of keys to scan through during filtering
  - CRUD support for Lists, Hashes, Strings, Sets, Sorted Sets
    - Search within the data structure (except for Strings)
  - CRUD support for [RedisJSON](https://oss.redis.com/redisjson/)
- Database overview:
  - A number of metrics always on display within the database workspace
    - Metrics updated every 5 second
    - CPU, number of keys, commands/sec, network input, network output, total memory, number of connected clients
  - Enabled modules per Redis server listed
- CLI:
  - Command-line interface with enhanced type-ahead command help
  - Embedded command helper where you can filter and search for Redis commands
- RediSearch:
  - Tabular visualizations within Workbench of [RediSearch](https://oss.redis.com/redisearch/) index queries and aggregations (support for FT.INFO, FT.SEARCH and FT.AGGREGATE)
- Custom plugins:
  - Ability to build your own visualization plugins to be rendered within Workbench
  - [Documentation](https://github.com/redisinsight/redisinsight) on how to develop custom plugins and a reference example are provided
- Built-in guides:
  - Built-in click-through guides for Redis capabilities
  - Added a guide on Document Capabilities within Redis
- User interface (UI):
  - Light/dark themes available
  - Colour palette adjusted to the highest level of [Web content accessibility guidelines](https://www.w3.org/WAI/standards-guidelines/wcag/)
- Data encryption:
  - Optional ability to encrypt sensitive data such as connection certificates and passwords


RedisInsight v2.10.0, September 2022

Summary: RedisInsight v2.10.0

2.10.0 (September 2022)

This is the General Availability (GA) release of RedisInsight 2.10.

Highlights

- Formatters: Additional support for values of keys with Protobuf, Binary, PHP unserialize (view and edit serialized PHP values as JSON), and Java serialized objects, save formatters selected when viewing other keys
- New overview for cluster databases displays memory and key allocation as well as database information per shards
- Configure Workbench to persist the Editor after commands have been run and group the results
- Complete an optional user survey

Details

**Features and improvements**
- [#1159](https://github.com/RedisInsight/RedisInsight/pull/1159), [#1160](https://github.com/RedisInsight/RedisInsight/pull/1160), [#1068](https://github.com/RedisInsight/RedisInsight/pull/1068), [#1071](https://github.com/RedisInsight/RedisInsight/pull/1071), [#1095](https://github.com/RedisInsight/RedisInsight/pull/1095), [#1097](https://github.com/RedisInsight/RedisInsight/pull/1097), [#1098](https://github.com/RedisInsight/RedisInsight/pull/1098) A dedicated **Analysis Tools** page displays memory and key allocation in cluster databases as well as database information per shards
- [#1017](https://github.com/RedisInsight/RedisInsight/pull/1017), [#1025](https://github.com/RedisInsight/RedisInsight/pull/1025), [#1029](https://github.com/RedisInsight/RedisInsight/pull/1029), [#1059](https://github.com/RedisInsight/RedisInsight/pull/1059), [#1092](https://github.com/RedisInsight/RedisInsight/pull/1092) Added support for additional data formats in Browser/Tree view, including Protobuf, Binary, Pickle, PHP unserialize (view and edit serialized PHP values as JSON), and Java serialized objects
- [#1130](https://github.com/RedisInsight/RedisInsight/pull/1130) Save formatters selected when viewing other keys
- [#1177](https://github.com/RedisInsight/RedisInsight/pull/1177) Add a validation when edited value is not valid in the selected format in Browser/Tree view
- [#1048](https://github.com/RedisInsight/RedisInsight/pull/1048) Configure Workbench to persist the Editor after commands have been run
- [#1119](https://github.com/RedisInsight/RedisInsight/pull/1119) Pipeline mode configuration for Workbench moved to Settings > Workbench
- [#1149](https://github.com/RedisInsight/RedisInsight/pull/1149) Save Workbench space by grouping results
- [#1162](https://github.com/RedisInsight/RedisInsight/pull/1162) Complete an optional user survey
- [#1037](https://github.com/RedisInsight/RedisInsight/pull/1037) Added tooltip to display long fields in [Redis Streams](https://redis.io/docs/data-types/streams/)
- [#1202](https://github.com/RedisInsight/RedisInsight/pull/1202) Removed format validations from the admin username in the Redis Software Cluster autodiscovery process

**Bugs**
- [#1180](https://github.com/RedisInsight/RedisInsight/pull/1180) Fix to display full values for truncated TTL in munutes
- [#1197](https://github.com/RedisInsight/RedisInsight/pull/1197) Workbench is now available even when encryption failed
- [#1176](https://github.com/RedisInsight/RedisInsight/pull/1176) Save the refresh value in Browser/Tree view
- [#1101](https://github.com/RedisInsight/RedisInsight/pull/1101) Fixed an issue when key names are not displayed


RedisInsight v2.12.0, October 2022

Summary: RedisInsight v2.12.0

2.12.0 (October 2022)

This is the General Availability (GA) release of RedisInsight 2.12.

Highlights

- Database Analysis: Get insights and optimize the usage and performance of your Redis or Redis Stack based on the overview of the memory and data type distribution, big or complicated keys, and namespaces used
- Faster initial loading of the list of keys in Browser and Tree views
- Performance optimizations for large results in Workbench

Details

**Features and improvements**
- [#1207](https://github.com/RedisInsight/RedisInsight/pull/1207), [#1222](https://github.com/RedisInsight/RedisInsight/pull/1222), [#1295](https://github.com/RedisInsight/RedisInsight/pull/1295), [#1159](https://github.com/RedisInsight/RedisInsight/pull/1159), [#1231](https://github.com/RedisInsight/RedisInsight/pull/1231), [#1155](https://github.com/RedisInsight/RedisInsight/pull/1155) Get insights and optimize the usage and performance of your Redis or Redis Stack with Database Analysis. Navigate to Analysis Tools and scan up to 10,000 keys in the database to see the summary of memory allocation and the number of keys per Redis data type, memory likely to be freed over time, top 15 key namespaces, and the biggest keys found. You can extrapolate results based on the total number of keys or see the exact results for the number of keys scanned.
- [#1280](https://github.com/RedisInsight/RedisInsight/pull/1280) Speed up the initial load of the key list in Browser and Tree views
- [#1285](https://github.com/RedisInsight/RedisInsight/pull/1285) Support for infinite floating point numbers in sorted sets
- [#1290](https://github.com/RedisInsight/RedisInsight/pull/1290) Performance optimizations to process large results of Redis commands in Workbench

**Bugs**
- [#1293](https://github.com/RedisInsight/RedisInsight/pull/1293) Fixed Workbench visualizations in Redis Stack


RedisInsight v2.2.0, May 2022

Summary: RedisInsight v2.2.0

2.2.0 (May 2022)

This is the General Availability (GA) release of RedisInsight 2.2.0

Headlines:

- SlowLog: New tool based on results of the [Slowlog](https://redis.io/commands/slowlog/) command to analyze slow operations in Redis instances
- Streams: Added support for [Redis Streams](https://redis.io/docs/manual/data-types/streams/)
- Open the list of keys or key details in full screen
- Automatically refresh the list of keys and key values with a timer

Details

**Features and improvements:**
- [#621](https://github.com/RedisInsight/RedisInsight/pull/621) , [#645](https://github.com/RedisInsight/RedisInsight/pull/645) , [#649](https://github.com/RedisInsight/RedisInsight/pull/649) Added SlowLog, a tool that displays the list of logs captured by the [Slowlog](https://redis.io/commands/slowlog/) command to analyze all commands that exceed a specified runtime, which helps in troubleshooting performance issues. Specify both the runtime and the maximum length of SlowLog (which are server configurations) to configure the list of commands logged and set the auto-refresh interval to automatically update the list of commands displayed.
- [#597](https://github.com/RedisInsight/RedisInsight/pull/597) , [#598](https://github.com/RedisInsight/RedisInsight/pull/598), [#601](https://github.com/RedisInsight/RedisInsight/pull/601) , [#603](https://github.com/RedisInsight/RedisInsight/pull/603) , [#608](https://github.com/RedisInsight/RedisInsight/pull/608) , [#613](https://github.com/RedisInsight/RedisInsight/pull/613) , [#614](https://github.com/RedisInsight/RedisInsight/pull/614) , [#632](https://github.com/RedisInsight/RedisInsight/pull/632) Support for [Redis Streams](https://redis.io/docs/manual/data-types/streams/), including creation and deletion of Streams, addition and deletion of entries, and filtration of entries per timestamp. [Consumer groups](https://redis.io/docs/manual/data-types/streams/#consumer-groups) will be added in a future release.
- [#643](https://github.com/RedisInsight/RedisInsight/pull/643) List of keys or key details are supported in full screen mode. To open the key list in full screen, close the key details. To open key details in full screen, use the new **Full Screen** control in key details section.
- [#633](https://github.com/RedisInsight/RedisInsight/pull/633) Automatically refresh the list of keys and key values with a timer. To do so, enable the **Auto Refresh** mode by clicking the control next to the **Refresh** button and set the refresh rate.
- [#634](https://github.com/RedisInsight/RedisInsight/pull/634) Removed the max value limitation in the **Database Index** field of the form for adding a new database.

**Bugs Fixed:**
- [#656](https://github.com/RedisInsight/RedisInsight/pull/656) Binary key names will not trigger errors in databases with enabled OSS Cluster API. Data type, TTL, and size of such keys are displayed in the list of keys in all Redis instances. Key details are currently not available.


RedisInsight v2.28.0, June 2023

Summary: RedisInsight v2.28

2.28 (June 2023)

This is the General Availability (GA) release of RedisInsight 2.28.

Highlights

- Quickly and conveniently add [Redis Cloud](https://redis.com/redis-enterprise-cloud/overview/) databases that belong to fixed subscriptions using the auto-discovery tool
- UX optimizations in Browser for an improved experience when performing [full-text search and queries](https://redis.io/docs/stack/search/), filtering, and bulk actions.
- Support for a monospaced font in [JSON](https://redis.io/docs/stack/json/) key types

Details

**Features and improvements**
- [#2198](https://github.com/RedisInsight/RedisInsight/pull/2198), [#2207](https://github.com/RedisInsight/RedisInsight/pull/2207) Automatically discover and add [Redis Cloud](https://redis.com/redis-enterprise-cloud/overview/) databases that belong to fixed subscriptions using the `Redis Cloud` option on the form to auto-discover databases.
- [#2146](https://github.com/RedisInsight/RedisInsight/pull/2146),[#2161](https://github.com/RedisInsight/RedisInsight/pull/2161) Added UX optimizations in the Browser layout to improve the experience when performing [full-text search and queries](https://redis.io/docs/stack/search/), filtering, and bulk actions.
- [#2200](https://github.com/RedisInsight/RedisInsight/pull/2200) Changed to a monospaced font in [JSON](https://redis.io/docs/stack/json/) key types, and JSON formatters in Browser and Workbench.
- [#2204](https://github.com/RedisInsight/RedisInsight/pull/2204) Re-bind default RedisInsight port from 5001 to 5530 to avoid conflicts with other applications
- [#2120](https://github.com/RedisInsight/RedisInsight/pull/2120) Added the ability to investigate the commands processed by Redis or Redis Stack server without the need to stop Profiler when a new record appears.
- [#2186](https://github.com/RedisInsight/RedisInsight/pull/2186) Unified the RedisInsight icon with other macOS applications.

**Bugs**
- [#2154](https://github.com/RedisInsight/RedisInsight/pull/2154) Display `(integer) 0` instead of `nil` in [ZRANK](https://redis.io/commands/zrank/) results in Workbench


RedisInsight v2.8.0, August 2022

Summary: RedisInsight v2.8.0

2.8.0 (August 2022)

This is the General Availability (GA) release of RedisInsight 2.8.0

Headlines

- Formatters: See formatted key values in JSON, MessagePack, Hex, Unicode, or ASCII in Browser/Tree view for an improved experience of working with different data formats.
- Clone existing database connection or connection details: Clone the database connection you previously added to have the same one, but with a different database index, username, or password.
- Raw mode in Workbench: Added support for the raw mode in Workbench results

Details

**Features and improvements**
- [#978](https://github.com/RedisInsight/RedisInsight/pull/978), [#959](https://github.com/RedisInsight/RedisInsight/pull/959), [#984](https://github.com/RedisInsight/RedisInsight/pull/984), [#996](https://github.com/RedisInsight/RedisInsight/pull/996), [#992](https://github.com/RedisInsight/RedisInsight/pull/992), [#1030](https://github.com/RedisInsight/RedisInsight/pull/1030) Added support for different data formats in Browser/Tree view, including JSON, MessagePack, Hex, and ASCII. If selected, formatter is applied to the entire key value and is available for any data type supported in Browser/Tree view. If any non-printable characters are detected, data editing is available only in Workbench and CLI to avoid data loss.
- [#955](https://github.com/RedisInsight/RedisInsight/pull/965) Quickly clone a database connection to have the same one, but with a different database index, username, or password. Open a database connection in the edit mode, request to clone it, and make the changes needed. The original database connection remains the same.
- [#1012](https://github.com/RedisInsight/RedisInsight/pull/1012) Added support for the raw mode (--raw) in Workbench. Enable it to see the results of commands executed in the raw mode.
- [#987](https://github.com/RedisInsight/RedisInsight/pull/987) [DBSIZE](https://redis.io/commands/dbsize/) command is no longer required to connect to a database.
- [#971](https://github.com/RedisInsight/RedisInsight/pull/971) Updated icon for the [RediSearch](https://redis.io/docs/stack/search/) Light module.
- [#1011](https://github.com/RedisInsight/RedisInsight/pull/1011) Enhanced navigation in the Command Helper allowing you to return to previous actions.

**Bugs fixed**
- [#1009](https://github.com/RedisInsight/RedisInsight/pull/1009) Fixed an [error](https://github.com/RedisInsight/RedisInsight/issues/804) on automatic discovery of Sentinel databases.
- [#978](https://github.com/RedisInsight/RedisInsight/pull/978) Work with [non-printable characters](https://github.com/RedisInsight/RedisInsight/issues/873). To avoid data loss, when non-printable characters are detected, key and value are editable in Workbench and CLI only.


Redis for VS Code

Summary: Connect to Redis from Visual Studio Code.

Redis for VS Code release notes

Overview

Redis for VS Code is an extension that allows you to connect to your Redis databases from within Microsoft Visual Studio Code.
After connecting to a database, you can view, add, modify, and delete keys, and interact with your Redis databases using a Redis Insight like UI and also a built-in CLI interface.
The following data types are supported:

- [Hash]()
- [List]()
- [Set]()
- [Sorted Set]()
- [String]()
- [JSON]()

Install the Redis for VS Code extension

Open VS Code and click on the **Extensions** menu button. In the **Search Extensions in Marketplace** field, type "Redis for VS Code" and press the `enter` or `return` key. There may be more than one option shown, so be sure to click on the extension published by Redis. The correct extension is shown below. Click on the **Install** to install the extension.

Once installed, check the **Auto Update** button to allow VS Code to install future revisions of the extension automatically.

After installing the extension, your VS Code menu will look similar to the following.

Connect to Redis databases {#connect-db}

Click on the Redis mark (the cursive **R**) in the VS Code menu to begin connecting a Redis database to VS Code. If you do not currently have access to a Redis database, consider giving Redis Cloud a try. [It's free](https://redis.io/try-free/).

Click on the **+ Connect database** button. A dialog will display in the main pane. In the image shown below, all the options have been checked to show the available details for each connection. These connection details are similar to those accessible from [`redis-cli`]().

In the first release of Redis for VS Code, there is no way to change the logical database after you have selected it. If you need to connect to a different logical database, you need to add a separate database connection.

After filling out the necessary fields, click on the **Add Redis database** button. The pane on the left side, where you would normally see the Explorer view, shows your database connections.

Local databases, excluding OSS cluster databases, with default usernames and no passwords will automatically be added to your list of database connections.

Connection tools

Several tools are displayed for each open connection.

Left to right, they are:

- Refresh connection, which retrieves fresh data from the connected Redis database.
- Edit connection, which shows a dialog similar to the one described in [Connect to Redis Databases](#connect-db) above.
- Delete connection.
- Open CLI. See [CLI tool](#cli) below for more information.
- Sort keys, either ascending or descending.
- Filter keys by key name or pattern, and by key type.
- Add a new key by type: Hash, List, Set, Sorted Set, String, or JSON.

Key view

Here's what you'll see when there are no keys in your database (the image on the left) and when keys are present (the image on the right).

Redis for VS Code will automatically group the keys based on the one available setting, **Delimiter to separate namespaces**, which you can view by clicking on the gear icon in the top-right of the left side pane. Click on the current value to change it. The default setting is the colon (`:`) character.

Click on a key to display its contents.

Key editing tools

There are several editing tools that you can use to edit key data. Each data type has its own editing capabilities. The following examples show edits to JSON data. Note that changes to keys are immediately written to the server.

- **Rename**. Click on the key name field to change the name.

- **Set time-to-live (TTL)**. Click on the **TTL** field to set the duration in seconds.

- **Delete**. Click on the trash can icons to delete the entire key (highlighted in red) or portions of a key (highlighted in yellow).

- **Add to key**. Click on the `+` button next to the closing bracket (shown highlighted in green above) to add a new component to a key.

- **Refresh**. Click on the refresh icon (the circular arrow) to retrieve fresh data from the server. In the examples below, refresh was clicked (the image on the left) and the key now has a new field called "test" that was added by another Redis client (the image on the right).

For strings, hashes, lists, sets, and sorted sets, the extension supports numerous value formatters (highlighted in red in the image below). They are:

- Unicode
- ASCII
- Binary (blob)
- HEX
- JSON
- Msgpack
- Pickle
- Protobuf
- PHP serialized
- Java serialized
- 32-bit vector
- 64-bit vector

Also for Hash keys, you can set per-field TTLs (highlighted in yellow in the image above), a new feature added to Redis Open Source 7.4.

CLI tool {#cli}

The connection tool with the boxed `>_` icon opens a Redis CLI window in the **REDIS CLI** tab at the bottom of the primary pane.

The CLI interface works just like the [`redis-cli`]() command.


Redis for VS Code release notes

Summary: Redis for VS Code v1.4

Redis for VS Code v1.4.0, May 2025

Summary: Redis for VS Code v1.2

Redis for VS Code v1.2.0, December 2024

Summary: Redis for VS Code v1.0

Redis for VS Code v1.0.0, September 2024

Content

Here are the most recent changes for Redis for VS Code:


Summary: Redis for VS Code v1.0

1.0.0 (September 2024)

This is the first release of Redis for VS Code.

Redis for VS Code is the official Visual Studio Code extension that provides an intuitive and efficient GUI for Redis databases, developed by Redis.

Headlines

* Universal Redis Support: Connect to any Redis instance, including Redis Open Source, Redis Cloud, Redis Software, and Redis on Azure Cache.

* Advanced Connectivity: Supports TLS certificates and SSH tunnels, with an option for automatic data decompression for GZIP, SNAPPY, Brotli, and more.

* Data types: Supports strings, hashes, lists, sets, sorted sets, and JSON.

* Human-readable data representation: Offers formatters like ASCII, JSON, Binary, Hex, 32-bit, and 64-bit vectors, and others.

* Integrated Redis CLI: Leverage Redis CLI with syntax preview as you type commands.

Details

- Database connections:

  - Connect to any Redis instance, including Redis Open Source, Redis Cloud, Redis Software, and Redis on Azure Cache.

  - View, edit, and manage your Redis database connections.

  - Supports TLS connections and SSH tunnels for secure access.

  - Automatically handle data compressed with GZIP, LZ4, SNAPPY, ZSTD, Brotli, or PHP GZCompress.

  - Choose and work with a specific logical database within your Redis instance.

- Redis data structures:

  - Use an intuitive tree view interface to browse, filter, and visualize Redis key-value data structures.

  -  Perform create, read, update, and delete operations on the following Redis data types:

    - Strings

    - Hashes

    - Lists

    - Sets

    - Sorted sets

    - JSON

- View your data in multiple human-readable formats, including Unicode, ASCII, Binary, HEX, JSON, Msgpack, Pickle, Protobuf, PHP serialized, Java serialized, and Vector (32 and 64-bit).

 - Sort by key names and apply filters by pattern or data type for quick and precise data access.

 - Conduct detailed searches within fields in hashes, indexes in lists, and members in sets and sorted sets.

- Redis CLI:

  - Access a built-in Redis CLI with improved type-ahead command suggestions, helping you execute commands accurately and efficiently.

Get started with Redis for VS Code

This repository contains the source code for the Redis for VS Code extension.

Install the extension from the [Visual Studio Code Marketplace](https://marketplace.visualstudio.com/items?itemName=redis.redis-for-vscode) to use it.


Redis for VS Code v1.2.0, December 2024

Summary: Redis for VS Code v1.2

1.2.0 (December 2024)

This is the General Availability (GA) release of Redis for VS Code 1.2.

Headlines

* Work with keys across multiple database indexes, which are automatically discovered and displayed in the database list.
* Support for adding multiple elements to the head or tail of Redis lists, for both new and existing keys.
* Auto-refresh the list of keys and key values with a customizable timer.
* Delete and update previously added CA and client certificates to keep them updated.

Details

- [#223](https://github.com/RedisInsight/Redis-for-VS-Code/pull/223) Work with keys across multiple database indexes. Database indexes with keys are automatically discovered and displayed in the database list.
- [#207](https://github.com/RedisInsight/Redis-for-VS-Code/pull/207) Support for adding multiple elements to the head or tail of Redis lists for new and existing key.
- [#226](https://github.com/RedisInsight/Redis-for-VS-Code/pull/226) Auto-refresh the list of keys and key values with a customizable timer. To do so, enable the Auto-refresh mode by clicking the control next to the Refresh button and setting the refresh rate.
- [#224](https://github.com/RedisInsight/Redis-for-VS-Code/pull/224) Ability to delete previously added CA and Client certificates to keep them up-to-date.
- [#224](https://github.com/RedisInsight/Redis-for-VS-Code/pull/224) Enhanced both the Java and PHP serialized formatters: the Java formatter now supports date and time data, while the PHP formatter includes UTF-8 encoding for better handling of special characters and multi-language data.
- [#224](https://github.com/RedisInsight/Redis-for-VS-Code/pull/224) Keep databases and the list of keys [expanded](https://github.com/RedisInsight/Redis-for-VS-Code/issues/217) after navigating away.
- [#226](https://github.com/RedisInsight/Redis-for-VS-Code/pull/226) New users can optionally encrypt sensitive data, such as connection certificates and passwords. Existing users can enable encryption by deleting the ~/.redis-for-vscode/redisinsight.db file and re-adding their database connections.

**Bugs**
- [#224](https://github.com/RedisInsight/Redis-for-VS-Code/pull/224) Resolved an issue where large integers in JSON keys were being rounded, ensuring data integrity.
- [#224](https://github.com/RedisInsight/Redis-for-VS-Code/pull/224) Saved SNI and SSH connection information for newly added database connections.
- [#224](https://github.com/RedisInsight/Redis-for-VS-Code/pull/224) Fixed an issue to display multiple hash fields when expanding a hash value.

Get started with Redis for VS Code

Install the extension from the [Visual Studio Code Marketplace](https://marketplace.visualstudio.com/items?itemName=redis.redis-for-vscode) to use it.


Redis for VS Code v1.4.0, May 2025

Summary: Redis for VS Code v1.4

1.4.0 (May 2025)

This is the General Availability (GA) release of Redis for VS Code 1.4.

Headlines

- Easily provision a free Redis Cloud database directly from within Redis for VS Code, great for prototyping AI workloads like semantic search, chat memory, and embedding-based retrieval, among many other Redis use cases, all without leaving your dev environment.
- Ability to encrypt connection certificates, passwords, and other sensitive data for all users.
- Support for multiple key name delimiters, making it easier to browse databases with varied key structures.

Details

- [#252](https://github.com/RedisInsight/Redis-for-VS-Code/pull/252), [#257](https://github.com/RedisInsight/Redis-for-VS-Code/pull/257) Easily provision a free [Redis Cloud](https://redis.io/cloud/) database directly from within Redis for VS Code, great for prototyping AI workloads like semantic search, chat memory, and embedding-based retrieval, among many other Redis use cases, all without leaving your dev environment.
- [#255](https://github.com/RedisInsight/Redis-for-VS-Code/pull/255) Added the ability to encrypt connection certificates, passwords, and other sensitive data for all users.
- [#247](https://github.com/RedisInsight/Redis-for-VS-Code/pull/247) Support for multiple key name delimiters, making it easier to browse databases with varied key structures.

Get started with Redis for VS Code


Using Redis commands

Summary: Learn how to interact with Redis using commands.

Summary: Managing keys in Redis: Key expiration, scanning, altering and querying the key space

Keys and values

Summary: How to optimize round-trip times by batching Redis commands

Redis pipelining

Summary: How transactions work in Redis

Transactions

Summary: Multi-key command behavior across Redis configurations and clustering setups

Multi-key operations

Overview

Client applications and tools interact with Redis using commands. Most of the
commands implement [data types]() to store and retrieve data,
but there are also commands that deal with server configuration, security, and more.

The sections below give an overview of how Redis commands operate. See the
[Redis commands reference]() for a complete list of commands.

Command structure

Each command is identified by a unique name. Related groups of commands
tend to follow a consistent naming convention. For example, all commands that
deal with [hashes]() start with the `H` prefix.
Most commands receive one or more arguments that specify the data to operate on.
For data type commands, the first argument is usually the [key]() that identifies the target data object.

After you issue a command, the server attempts to process it and then returns
a response. Commands that update data typically return a status message (such as `OK`)
or a number that indicates the number of items changed or updated. Commands that
retrieve data return the requested data. An unsuccessful command returns an
error message that describes the problem.

Interacting with a Redis server involves a sequence of commands and responses.
The effect of a given command is the same regardless of whether you send it
from a [client library](), or from a client tool
such as [redis-cli]() or
[Redis Insight](). This is very useful
during development. You can use a high-level tool to experiment with a
command, set up test data, or prototype a data model, and then access the
prepared data from your application code. Most Redis code examples are
presented with an excerpt of a CLI session and the equivalent application code
for each client library.

Batching commands

Although you can issue Redis commands one at a time, it's often more efficient
to batch a sequence of related commands together into a *pipeline*. A pipeline
sends several commands to the server as a single communication and receives
the responses in the same way. See
[Pipelining]() for a full
description of the technique and see also the pipelining examples for the
[client libraries]().

Another reason to batch commands is to treat them as an uninterrupted unit.
You should do this if you need to be sure that the commands are all
completed without the same data being modified by another client (which
could leave the data in an inconsistent state). Redis uses *transactions*
to implement this behavior. See
[Transactions]() for
more information and see also the transaction examples for the
[client libraries]().

More information

The other pages in this section describe Redis command concepts in more detail:


Keys and values

Overview

Every data object that you store in a Redis database has its own unique
*key*. The key is a string that you pass to Redis commands to
retrieve the corresponding object or modify its data. The data object associated with a
particular key is known as the *value* and the two together are known as
as *key-value pair*.

Content of keys

A key is typically a textual name that has some meaning within your
data model. Unlike variable names in a programming language, Redis keys have few
restrictions on their format, so keys with whitespace or punctuation characters
are mostly fine (for example, "1st Attempt", or "% of price in $"). Redis doesn't
support namespaces or other categories for keys, so you must take care to avoid
name collisions. However, there is a convention for using the colon ":"
character to split keys into sections (for example, "person:1", "person:2",
"office:London", "office:NewYork:1"). You can use this as a simple way to collect
keys together into categories.

Although keys are usually textual, Redis actually implements *binary-safe* keys,
so you can use any sequence of bytes as a valid key, such as a JPEG file or
a struct value from your app. The empty string is also a valid key in Redis.

There are also a few other things to bear in mind about keys:

* Very long keys are not a good idea. For instance, a key of 1024 bytes is a bad
  idea not only memory-wise, but also because the lookup of the key in the
  dataset may require several costly key-comparisons. Even when the task at hand
  is to match the existence of a large value, hashing it (for example
  with SHA1) is a better idea, especially from the perspective of memory
  and bandwidth.
* Very short keys are often not a good idea. There is little point in writing
  "u1000flw" as a key if you can instead write "user:1000:followers".  The latter
  is more readable and the added space is minor compared to the space used by
  the key object itself and the value object. While short keys will obviously
  consume a bit less memory, your job is to find the right balance.
* Try to stick with a schema. For instance "object-type:id" is a good
  idea, as in "user:1000". Dots or dashes are often used for multi-word
  fields, as in "comment:4321:reply.to" or "comment:4321:reply-to".
* The maximum allowed key size is 512 MB.

Hashtags

Redis uses [hashing](https://en.wikipedia.org/wiki/Hash_table) to retrieve the
value associated with a key in a highly efficient way. Hashing involves combining the
raw byte values from the key to produce an integer *index* number. The index is then
used to locate the *hash slot* where the value for the key is stored.

Normally, the whole key is used to calculate the hash index, but there are some
situations where you need to hash only a part of the key. You can select the
section of the key you want to hash using a pair of curly braces `{...}` to create
a *hashtag*. For example, the keys `person:1` and `person:2` produce different
hash indices but `{person}:1` and `{person}:2` produce the same index because
only the `person` hashtag section in the braces is used for the hash calculation.

A common use of hashtags is to allow
[multi-key operations]()
with a *clustered* database (see
[Database clustering]()
for more information). Redis doesn't allow most multi-key operations in a clustered database
unless all the keys produce the same hash index. For example, the
[SINTER]()
command finds the [intersection](https://en.wikipedia.org/wiki/Intersection_(set_theory))
of two different [set]() values.
This means that the command

[code example]

won't work with a clustered database but

[code example]

will work because the hashtag ensures the two keys produce the same hash index.

Note that although hashtags are useful in certain cases, you shouldn't make
a habit of using them generally. If you have too many keys mapped to the same
hash slot then this will eventually harm the performance of your database.
See [Database clustering]()
for more information about how to use hashtags.

Altering and querying the key space

There are commands that are not defined on particular types, but are useful
in order to interact with the space of keys, and thus, can be used with
keys of any type.

For example the [`EXISTS`]() command returns 1 or 0 to signal if a given key
exists or not in the database, while the [`DEL`]() command deletes a key
and associated value, whatever the value is.

    > set mykey hello
    OK
    > exists mykey
    (integer) 1
    > del mykey
    (integer) 1
    > exists mykey
    (integer) 0

From the examples you can also see how [`DEL`]() itself returns 1 or 0 depending on whether
the key was removed (it existed) or not (there was no such key with that
name).

There are many key space related commands, but the above two are the
essential ones together with the [`TYPE`]() command, which returns the kind
of value stored at the specified key:

    > set mykey x
    OK
    > type mykey
    string
    > del mykey
    (integer) 1
    > type mykey
    none

Key expiration

Before moving on, we should look at an important Redis feature that works regardless of the type of value you're storing: key expiration. Key expiration lets you set a timeout for a key, also known as a "time to live", or "TTL". When the time to live elapses, the key is automatically destroyed.

A few important notes about key expiration:

* They can be set both using seconds or milliseconds precision.
* However the expire time resolution is always 1 millisecond.
* Information about expires are replicated and persisted on disk, the time virtually passes when your Redis server remains stopped (this means that Redis saves the date at which a key will expire).

Use the [`EXPIRE`]() command to set a key's expiration:

    > set key some-value
    OK
    > expire key 5
    (integer) 1
    > get key (immediately)
    "some-value"
    > get key (after some time)
    (nil)

The key vanished between the two [`GET`]() calls, since the second call was
delayed more than 5 seconds. In the example above we used [`EXPIRE`]() in
order to set the expire (it can also be used in order to set a different
expire to a key already having one, like [`PERSIST`]() can be used in order
to remove the expire and make the key persistent forever). However we
can also create keys with expires using other Redis commands. For example
using [`SET`]() options:

    > set key 100 ex 10
    OK
    > ttl key
    (integer) 9

The example above sets a key with the string value `100`, having an expire
of ten seconds. Later the [`TTL`]() command is called in order to check the
remaining time to live for the key.

In order to set and check expires in milliseconds, check the [`PEXPIRE`]() and
the [`PTTL`]() commands, and the full list of [`SET`]() options.

Navigating the keyspace

Scan

To incrementally  iterate over the keys in a Redis database in an efficient manner, you can use the [`SCAN`]() command.

Since [`SCAN`]() allows for incremental iteration, returning only a small number of elements per call, it can be used in production without the downside of commands like [`KEYS`]() or [`SMEMBERS`]() that may block the server for a long time (even several seconds) when called against big collections of keys or elements.

However while blocking commands like [`SMEMBERS`]() are able to provide all the elements that are part of a Set in a given moment.
The [`SCAN`]() family of commands only offer limited guarantees about the returned elements since the collection that we incrementally iterate can change during the iteration process.

Keys

Another way to iterate over the keyspace is to use the [`KEYS`]() command, but this approach should be used with care, since [`KEYS`]() will block the Redis server until all keys are returned.

**Warning**: consider [`KEYS`]() as a command that should only be used in production
environments with extreme care.

[`KEYS`]() may ruin performance when it is executed against large databases.
This command is intended for debugging and special operations, such as changing
your keyspace layout.
Don't use [`KEYS`]() in your regular application code.
If you're looking for a way to find keys in a subset of your keyspace, consider
using [`SCAN`]() or [sets]().

[tdts]: /develop/data-types#sets

Supported glob-style patterns:

* `h?llo` matches `hello`, `hallo` and `hxllo`
* `h*llo` matches `hllo` and `heeeello`
* `h[ae]llo` matches `hello` and `hallo,` but not `hillo`
* `h[^e]llo` matches `hallo`, `hbllo`, ... but not `hello`
* `h[a-b]llo` matches `hallo` and `hbllo`

Use `\` to escape special characters if you want to match them verbatim.


Multi-key operations

Overview

Multi-key operations in Redis allow you to work with multiple keys in a single command, but their behavior varies significantly depending on your Redis configuration and clustering setup. This page provides a quick reference for developers working with multi-key operations across different Redis configurations.

Configurations

Redis supports five distinct configurations, each with different multi-key command behaviors:

1. **ROS/RS clustering disabled** - Single Redis instance
2. **ROS, clustering enabled** - Redis Open Source cluster
3. **RS, clustering enabled, OSS cluster API enabled** - Redis Software with ROS cluster compatibility
4. **RS, clustering enabled, OSS cluster API disabled** - Redis Software proprietary clustering
5. **RS, Active-Active** - Redis Software Active-Active (considered clustered even with a single shard)

ROS stands for Redis Open Source and RS stands for Redis Software.

Command behaviors

For each configuration, commands exhibit one of three behaviors:

- **single-slot**: Commands must operate on keys within the same hash slot
- **cross-slot (all shards)**: Commands can operate across all shards in the cluster
- **cross-slot (within a single shard)**: Commands can operate across slots but only within a single shard

Read-only commands

| Behavior | Commands |
|----------|----------|
| **ROS/RS clustering disabled:**
– the whole DB (single shard)

**ROS clustering enabled, RS clustering enabled (OSS cluster API enabled):**
– the current shard

**RS clustering enabled (OSS cluster API disabled):**
– all shards | DBSIZE, KEYS, SCAN |
| **ROS/RS clustering disabled:**
– cross-slot

**ROS clustering enabled, RS clustering enabled (OSS cluster API enabled):**
– single-slot

**RS clustering enabled (OSS cluster API disabled):**
– cross-slot (all shards) | EXISTS, MGET |
| **ROS/RS clustering disabled:**
– cross-slot

**ROS clustering enabled, RS clustering enabled (OSS cluster API enabled), RS clustering enabled (OSS cluster API disabled):**
– single-slot | PFCOUNT, SDIFF, SINTER, SINTERCARD, SUNION, WATCH, XREAD, XREADGROUP, ZDIFF, ZINTER, ZINTERCARD, ZUNION |
| **ROS/RS clustering disabled:**
– cross-slot

**ROS clustering enabled, RS clustering enabled (OSS cluster API enabled), RS clustering enabled (OSS cluster API disabled):**
– single-shard | JSON.MGET

Users won't get a CROSSSLOT error. However, when clustering is enabled, and not all specified keys are in the same slot, users will get partial results for all the slots on the current shard. |
| **ROS/RS clustering disabled:**
– cross-slot (all shards)

**ROS clustering enabled, RS clustering enabled (OSS cluster API enabled), RS clustering enabled (OSS cluster API disabled):**
– cross-slot (all shards), cannot be part of a transaction | TS.MGET, TS.MRANGE, TS.MREVRANGE, TS.QUERYINDEX |

Read-write commands

| Behavior | Commands |
|----------|----------|
| **ROS/RS clustering disabled:**
– the whole DB (single shard)

**ROS clustering enabled, RS clustering enabled (OSS cluster API enabled):**
– the current shard

**RS clustering enabled (OSS cluster API disabled):**
– all shards | FLUSHALL, FLUSHDB |
| **ROS/RS clustering disabled:**
– cross-slot

**ROS clustering enabled, RS clustering enabled (OSS cluster API enabled):**
– single-slot

**RS clustering enabled (OSS cluster API disabled):**
– cross-slot (all shards) | DEL, MSET, TOUCH, UNLINK

Note: on Active-Active, DEL, MSET, and UNLINK are single-slot |
| **ROS/RS clustering disabled:**
– cross-slot

**ROS clustering enabled, RS clustering enabled (OSS cluster API enabled), RS clustering enabled (OSS cluster API disabled):**
– single-slot | BITOP, BLMOVE, BLMPOP, BLPOP, BRPOP, BRPOPLPUSH, BZMPOP, BZPOPMAX, BZPOPMIN, CMS.MERGE, COPY, GEORADIUS or GEORADIUSBYMEMBER (with STORE or STOREDIST), GEOSEARCHSTORE, JSON.MSET, LMOVE, LMPOP, MSETNX, PFMERGE, RENAME, RENAMENX, RPOPLPUSH, SDIFFSTORE, SINTERSTORE, SMOVE, SUNIONSTORE, TDIGEST.MERGE, TS.MADD, ZDIFFSTORE, ZINTERSTORE, ZMPOP, ZRANGESTORE, ZUNIONSTORE |
| **ROS/RS clustering disabled:**
– cross-slot

**ROS clustering enabled, RS clustering enabled (OSS cluster API enabled), RS clustering enabled (OSS cluster API disabled):**
– single-shard | TS.CREATERULE, TS.DELETERULE

Users won't get a CROSSSLOT error. However, when clustering is enabled and the two specified keys are not in the same slot, users will get `(error) ERR TSDB: the key does not exist`. |

Pipelines, transactions, and scripts

| Behavior | Operations |
|----------|------------|
| **ROS/RS clustering disabled:**
– cross-slot
**ROS clustering enabled, RS clustering enabled (OSS cluster API enabled):**
– single-slot
**RS clustering enabled (OSS cluster API disabled):**
– cross-slot (all shards) | Pipelines |
| **ROS/RS clustering disabled:**
– cross-slot
**ROS clustering enabled, RS clustering enabled (OSS cluster API enabled), RS clustering enabled (OSS cluster API disabled):**
– single-slot | Keys in a `MULTI/EXEC` transaction
Keys in a Lua script executed using EVAL or EVALSHA |

Examples by Configuration

Single Instance (No Clustering)

In a single Redis instance, all multi-key operations work without restrictions:

[code example]

Clustered Environments

In clustered setups, you need to consider slot distribution:

[code example]

Active-Active Databases

Active-Active databases have additional restrictions for write operations:

[code example]

Troubleshooting Multi-Key Operations

Common Error Messages

- **CROSSSLOT**: Keys in request don't hash to the same slot
- **MOVED**: Key has moved to a different node (during resharding)
- **TRYAGAIN**: Operation temporarily unavailable (during migration)

Solutions

1. **Use hash tags** to group related keys
2. **Redesign data model** to minimize cross-slot operations
3. **Check cluster state** during errors
4. **Implement retry logic** for temporary failures

Performance Considerations

- **Single-slot operations** are fastest as they don't require coordination
- **Cross-slot operations** may have higher latency due to internal routing
- **Pattern commands** (KEYS, FLUSHALL) scan all shards and can be expensive
- **Module operations** may have optimized cross-slot implementations

Choose your Redis configuration and design your data model based on your multi-key operation requirements.

# Pipeline operations work across any keys
PIPELINE
SET user:1 "Alice"
SET product:100 "Widget"
GET user:1
GET product:100
EXEC

# Transactions work with any keys
MULTI
SET counter:a 1
SET counter:b 2
INCR counter:a
INCR counter:b
EXEC

# This may fail if keys are in different slots
MSET user:1 "Alice" user:2 "Bob"

# Use hash tags to ensure same slot
MSET {users}:1 "Alice" {users}:2 "Bob"

# Check which slot a key belongs to
CLUSTER KEYSLOT user:1
CLUSTER KEYSLOT {users}:1

# Read operations can work across slots
MGET user:1 user:2 product:100

# Write operations must be in same slot
MSET {data}:user:1 "Alice" {data}:user:2 "Bob"


Redis pipelining

Overview

Redis pipelining is a technique for improving performance by issuing multiple commands at once without waiting for the response to each individual command. Pipelining is supported by most Redis clients. This document describes the problem that pipelining is designed to solve and how pipelining works in Redis.

Request/Response protocols and round-trip time (RTT)

Redis is a TCP server using the client-server model and what is called a *Request/Response* protocol.

This means that usually a request is accomplished with the following steps:

* The client sends a query to the server, and reads from the socket, usually in a blocking way, for the server response.
* The server processes the command and sends the response back to the client.

So for instance a four commands sequence is something like this:

 * *Client:* INCR X
 * *Server:* 1
 * *Client:* INCR X
 * *Server:* 2
 * *Client:* INCR X
 * *Server:* 3
 * *Client:* INCR X
 * *Server:* 4

Clients and Servers are connected via a network link.
Such a link can be very fast (a loopback interface) or very slow (a connection established over the Internet with many hops between the two hosts).
Whatever the network latency is, it takes time for the packets to travel from the client to the server, and back from the server to the client to carry the reply.

This time is called RTT (Round Trip Time).
It's easy to see how this can affect performance when a client needs to perform many requests in a row (for instance adding many elements to the same list, or populating a database with many keys).
For instance if the RTT time is 250 milliseconds (in the case of a very slow link over the Internet), even if the server is able to process 100k requests per second, we'll be able to process at max four requests per second.

If the interface used is a loopback interface, the RTT is much shorter, typically sub-millisecond, but even this will add up to a lot if you need to perform many writes in a row.

Fortunately there is a way to improve this use case.

Redis Pipelining

A Request/Response server can be implemented so that it is able to process new requests even if the client hasn't already read the old responses.
This way it is possible to send *multiple commands* to the server without waiting for the replies at all, and finally read the replies in a single step.

This is called pipelining, and is a technique widely in use for many decades.
For instance many POP3 protocol implementations already support this feature, dramatically speeding up the process of downloading new emails from the server.

Redis has supported pipelining since its early days, so whatever version you are running, you can use pipelining with Redis.
This is an example using the raw netcat utility:

[code example]

This time we don't pay the cost of RTT for every call, but just once for the three commands.

To be explicit, with pipelining the order of operations of our very first example will be the following:

 * *Client:* INCR X
 * *Client:* INCR X
 * *Client:* INCR X
 * *Client:* INCR X
 * *Server:* 1
 * *Server:* 2
 * *Server:* 3
 * *Server:* 4

> **IMPORTANT NOTE**: While the client sends commands using pipelining, the server will be forced to queue the replies, using memory. So if you need to send a lot of commands with pipelining, it is better to send them as batches each containing a reasonable number, for instance 10k commands, read the replies, and then send another 10k commands again, and so forth. The speed will be nearly the same, but the additional memory used will be at most the amount needed to queue the replies for these 10k commands.

It's not just a matter of RTT

Pipelining is not just a way to reduce the latency cost associated with the
round trip time, it actually greatly improves the number of operations
you can perform per second in a given Redis server.
This is because without using pipelining, serving each command is very cheap from
the point of view of accessing the data structures and producing the reply,
but it is very costly from the point of view of doing the socket I/O. This
involves calling the `read()` and `write()` syscall, that means going from user
land to kernel land.
The context switch is a huge speed penalty.

When pipelining is used, many commands are usually read with a single `read()`
system call, and multiple replies are delivered with a single `write()` system
call. Consequently, the number of total queries performed per second
initially increases almost linearly with longer pipelines, and eventually
reaches 10 times the baseline obtained without pipelining, as shown in this figure.

A real world code example

In the following benchmark we'll use the Redis Ruby client, supporting pipelining, to test the speed improvement due to pipelining:

[code example]

Running the above simple script yields the following figures on my Mac OS X system, running over the loopback interface, where pipelining will provide the smallest improvement as the RTT is already pretty low:

[code example]
As you can see, using pipelining, we improved the transfer by a factor of five.

Pipelining vs Scripting

Using [Redis scripting](), available since Redis 2.6, a number of use cases for pipelining can be addressed more efficiently using scripts that perform a lot of the work needed at the server side.
A big advantage of scripting is that it is able to both read and write data with minimal latency, making operations like *read, compute, write* very fast (pipelining can't help in this scenario since the client needs the reply of the read command before it can call the write command).

Sometimes the application may also want to send [`EVAL`]() or [`EVALSHA`]() commands in a pipeline.
This is entirely possible and Redis explicitly supports it with the [SCRIPT LOAD]() command (it guarantees that [`EVALSHA`]() can be called without the risk of failing).

Appendix: Why are busy loops slow even on the loopback interface?

Even with all the background covered in this page, you may still wonder why
a Redis benchmark like the following (in pseudo code), is slow even when
executed in the loopback interface, when the server and the client are running
in the same physical machine:

[code example]

After all, if both the Redis process and the benchmark are running in the same
box, isn't it just copying messages in memory from one place to another without
any actual latency or networking involved?

The reason is that processes in a system are not always running, actually it is
the kernel scheduler that lets the process run.
So, for instance, when the benchmark is allowed to run, it reads the reply from the Redis server (related to the last command executed), and writes a new command.
The command is now in the loopback interface buffer, but in order to be read by the server, the kernel should schedule the server process (currently blocked in a system call)
to run, and so forth.
So in practical terms the loopback interface still involves network-like latency, because of how the kernel scheduler works.

Basically a busy loop benchmark is the silliest thing that can be done when
metering performances on a networked server. The wise thing is just avoiding
benchmarking in this way.

$ (printf "PING\r\nPING\r\nPING\r\n"; sleep 1) | nc localhost 6379
+PONG
+PONG
+PONG

require 'rubygems'
require 'redis'

def bench(descr)
  start = Time.now
  yield
  puts "#{descr} #{Time.now - start} seconds"
end

def without_pipelining
  r = Redis.new
  10_000.times do
    r.ping
  end
end

def with_pipelining
  r = Redis.new
  r.pipelined do |rp|
    10_000.times do
      rp.ping
    end
  end
end

bench('without pipelining') do
  without_pipelining
end
bench('with pipelining') do
  with_pipelining
end

without pipelining 1.185238 seconds
with pipelining 0.250783 seconds

FOR-ONE-SECOND:
    Redis.SET("foo","bar")
END


Transactions

Summary: How transactions work in Redis

Overview

Redis Transactions allow the execution of a group of commands
in a single step, they are centered around the commands
[`MULTI`](), [`EXEC`](), [`DISCARD`]() and [`WATCH`]().
Redis Transactions make two important guarantees:

* All the commands in a transaction are serialized and executed
sequentially. A request sent by another client will never be
served **in the middle** of the execution of a Redis Transaction.
This guarantees that the commands are executed as a single
isolated operation.

* The [`EXEC`]() command
triggers the execution of all the commands in the transaction, so
if a client loses the connection to the server in the context of a
transaction before calling the [`EXEC`]() command none of the operations
are performed, instead if the [`EXEC`]() command is called, all the
operations are performed. When using the
[append-only file]() Redis makes sure
to use a single write(2) syscall to write the transaction on disk.
However if the Redis server crashes or is killed by the system administrator
in some hard way it is possible that only a partial number of operations
are registered. Redis will detect this condition at restart, and will exit with an error.
Using the `redis-check-aof` tool it is possible to fix the
append only file that will remove the partial transaction so that the
server can start again.

Starting with version 2.2, Redis allows for an extra guarantee to the
above two, in the form of optimistic locking in a way very similar to a
check-and-set (CAS) operation.
This is documented [later](#cas) on this page.

Usage

A Redis Transaction is entered using the [`MULTI`]() command. The command
always replies with `OK`. At this point the user can issue multiple
commands. Instead of executing these commands, Redis will queue
them. All the commands are executed once [`EXEC`]() is called.

Calling [`DISCARD`]() instead will flush the transaction queue and will exit
the transaction.

The following example increments keys `foo` and `bar` atomically.

[code example]

As is clear from the session above, [`EXEC`]() returns an
array of replies, where every element is the reply of a single command
in the transaction, in the same order the commands were issued.

When a Redis connection is in the context of a [`MULTI`]() request,
all commands will reply with the string `QUEUED` (sent as a Status Reply
from the point of view of the Redis protocol). A queued command is
simply scheduled for execution when [`EXEC`]() is called.

Errors inside a transaction

During a transaction it is possible to encounter two kind of command errors:

* A command may fail to be queued, so there may be an error before [`EXEC`]() is called.
For instance the command may be syntactically wrong (wrong number of arguments,
wrong command name, ...), or there may be some critical condition like an out of
memory condition (if the server is configured to have a memory limit using the `maxmemory` directive).
* A command may fail *after* [`EXEC`]() is called, for instance since we performed
an operation against a key with the wrong value (like calling a list operation against a string value).

Starting with Redis 2.6.5, the server will detect an error during the accumulation of commands.
It will then refuse to execute the transaction returning an error during [`EXEC`](), discarding the transaction.

> **Note for Redis < 2.6.5:** Prior to Redis 2.6.5 clients needed to detect errors occurring prior to [`EXEC`]() by checking
the return value of the queued command: if the command replies with QUEUED it was
queued correctly, otherwise Redis returns an error.
If there is an error while queueing a command, most clients
will abort and discard the transaction. Otherwise, if the client elected to proceed with the transaction
the [`EXEC`]() command would execute all commands queued successfully regardless of previous errors.

Errors happening *after* [`EXEC`]() instead are not handled in a special way:
all the other commands will be executed even if some command fails during the transaction.

This is more clear on the protocol level. In the following example one
command will fail when executed even if the syntax is right:

[code example]

[`EXEC`]() returned two-element [bulk string reply]() where one is an `OK` code and
the other an error reply. It's up to the client library to find a
sensible way to provide the error to the user.

It's important to note that
**even when a command fails, all the other commands in the queue are processed** – Redis will _not_ stop the
processing of commands.

Another example, again using the wire protocol with `telnet`, shows how
syntax errors are reported ASAP instead:

[code example]

This time due to the syntax error the bad [`INCR`]() command is not queued
at all.

What about rollbacks?

Redis does not support rollbacks of transactions since supporting rollbacks
would have a significant impact on the simplicity and performance of Redis.

Discarding the command queue

[`DISCARD`]() can be used in order to abort a transaction. In this case, no
commands are executed and the state of the connection is restored to
normal.

[code example]

Optimistic locking using check-and-set

[`WATCH`]() is used to provide a check-and-set (CAS) behavior to Redis
transactions.

[`WATCH`]()ed keys are monitored in order to detect changes against them. If
at least one watched key is modified before the [`EXEC`]() command, the
whole transaction aborts, and [`EXEC`]() returns a [Null reply]() to notify that
the transaction failed.

For example, imagine we have the need to atomically increment the value
of a key by 1 (let's suppose Redis doesn't have [`INCR`]()).

The first try may be the following:

[code example]

This will work reliably only if we have a single client performing the
operation in a given time. If multiple clients try to increment the key
at about the same time there will be a race condition. For instance,
client A and B will read the old value, for instance, 10. The value will
be incremented to 11 by both the clients, and finally [`SET`]() as the value
of the key. So the final value will be 11 instead of 12.

Thanks to [`WATCH`]() we are able to model the problem very well:

[code example]

Using the above code, if there are race conditions and another client
modifies the result of `val` in the time between our call to [`WATCH`]() and
our call to [`EXEC`](), the transaction will fail.

We just have to repeat the operation hoping this time we'll not get a
new race. This form of locking is called _optimistic locking_.
In many use cases, multiple clients will be accessing different keys,
so collisions are unlikely – usually there's no need to repeat the operation.

Starting with version 8.4, Redis offers new atomic compare-and-set and compare-and-delete commands for string keys.
A client can use a single ([`SET`]() command with the `IFEQ`/`IFNE`/`IFDEQ`/`IFDNE` options to atomically update a string key only if its value has not changed since it was fetched.
This is much simpler and faster.
Similarly, a client can use a single [`DELEX`]() command for compare-and-delete: atomically deleting a string key if its value hasn't changed since it was fetched.

WATCH explained

So what is [`WATCH`]() really about? It is a command that will
make the [`EXEC`]() conditional: we are asking Redis to perform
the transaction only if none of the [`WATCH`]()ed keys were modified. This includes
modifications made by the client, like write commands, and by Redis itself,
like expiration or eviction. If keys were modified between when they were
[`WATCH`]()ed and when the [`EXEC`]() was received, the entire transaction will be aborted
instead.

**NOTE**
* In Redis versions before 6.0.9, an expired key would not cause a transaction
to be aborted. [More on this](https://github.com/redis/redis/pull/7920)
* Commands within a transaction won't trigger the [`WATCH`]() condition since they
are only queued until the [`EXEC`]() is sent.

[`WATCH`]() can be called multiple times. Simply all the [`WATCH`]() calls will
have the effects to watch for changes starting from the call, up to
the moment [`EXEC`]() is called. You can also send any number of keys to a
single [`WATCH`]() call.

When [`EXEC`]() is called, all keys are [`UNWATCH`]()ed, regardless of whether
the transaction was aborted or not.  Also when a client connection is
closed, everything gets [`UNWATCH`]()ed.

It is also possible to use the [`UNWATCH`]() command (without arguments)
in order to flush all the watched keys. Sometimes this is useful as we
optimistically lock a few keys, since possibly we need to perform a
transaction to alter those keys, but after reading the current content
of the keys we don't want to proceed.  When this happens we just call
[`UNWATCH`]() so that the connection can already be used freely for new
transactions.

Using WATCH to implement ZPOP

A good example to illustrate how [`WATCH`]() can be used to create new
atomic operations otherwise not supported by Redis is to implement ZPOP
([`ZPOPMIN`](), [`ZPOPMAX`]() and their blocking variants have only been added
in version 5.0), that is a command that pops the element with the lower
score from a sorted set in an atomic way. This is the simplest
implementation:

[code example]

If [`EXEC`]() fails (i.e. returns a [Null reply]()) we just repeat the operation.

Redis scripting and transactions

Something else to consider for transaction like operations in redis are
[redis scripts]() which are transactional. Everything
you can do with a Redis Transaction, you can also do with a script, and
usually the script will be both simpler and faster.

> MULTI
OK
> INCR foo
QUEUED
> INCR bar
QUEUED
> EXEC
1) (integer) 1
2) (integer) 1

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
MULTI
+OK
SET a abc
+QUEUED
LPOP a
+QUEUED
EXEC
*2
+OK
-WRONGTYPE Operation against a key holding the wrong kind of value

MULTI
+OK
INCR a b c
-ERR wrong number of arguments for 'incr' command

> SET foo 1
OK
> MULTI
OK
> INCR foo
QUEUED
> DISCARD
OK
> GET foo
"1"

val = GET mykey
val = val + 1
SET mykey $val

WATCH mykey
val = GET mykey
val = val + 1
MULTI
SET mykey $val
EXEC

WATCH zset
element = ZRANGE zset 0 0
MULTI
ZREM zset element
EXEC


Redis 6.2

Summary: What's new in Redis 6.2

Overview

Redis version 6.2 introduces new capabilities designed to improve data indexing, querying, and analytics. This update brings multi-value indexing, expanded wildcard query support, and a new probabilistic data structure for quantile estimation. Additionally, significant enhancements to Redis streams and time series data processing offer greater flexibility for developers working with real-time and historical datasets. Over 25 new commands have been added to Redis that address key feature requests and further extending its capabilities.
Below is a detailed breakdown of these improvements.

New features

Multi-value indexing and querying

Redis now supports indexing and querying multi-value attributes across all field types, including `TEXT`, `TAG`, `NUMERIC`, `GEO`, and `VECTOR`. Developers can define JSONPath expressions leading to arrays or multiple scalar values, overcoming the previous limitation of indexing only single scalar attributes.

Wildcard query support

Redis Search now enables suffix and infix wildcard searches for `TEXT` and `TAG` fields. This enhancement provides greater flexibility in data retrieval and filtering.

t-digest: a new probabilistic data structure for quantile estimation

Redis introduces t-digest, an advanced probabilistic data structure that efficiently estimates quantiles in large datasets or continuous data streams. This is particularly beneficial for analytics and monitoring applications where quantile calculations are required.

Retrieve aggregation results for ongoing time series buckets

A new feature allows users to retrieve the latest, still-open time series buckets during compaction.

Time-weighted average aggregator for time series

Redis now includes a time-weighted average aggregator, improving accuracy in average-over-time calculations. This feature is especially valuable for time series data with irregular sampling intervals.

Gap-filling for time series data

To improve time series analytics, Redis introduces gap-filling capabilities. This feature allows interpolation of missing values or repetition of the last known value for empty time buckets, ensuring continuity in time series analysis.

Improvements

Existing data structures

Redis 6.2 introduces over 25 new commands, fulfilling long-standing community requests. Notably:

- The long-awaited `ZUNION` and `ZINTER` commands now allow direct retrieval of results, unlike `ZUNIONSTORE` and `ZINTERSTORE`, which store results in a key.
- Redis streams enhancements include:
  - Support for exclusive range queries, providing finer control over data retrieval.
  - The ability to filter pending messages based on idle time, improving message management.
  - A new mechanism to automatically claim pending messages from a stream consumer group, transferring ownership of messages that have exceeded their idle timeout to a new consumer without requiring manual acknowledgment.

Component versions

The Redis version 6.2 is built from the following component versions:

- [Redis 6.2](https://github.com/redis/redis/blob/6.2/00-RELEASENOTES)
- [Search 2.6](https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/release-notes/redisearch/redisearch-2.6-release-notes/)
- [JSON 2.4](https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/release-notes/redisjson/redisjson-2.4-release-notes/)
- [Time series 1.8](https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/release-notes/redistimeseries/redistimeseries-1.8-release-notes/)
- [Bloom 2.4](https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/release-notes/redisbloom/redisbloom-2.4-release-notes/)
- [Graph 2.10](https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/release-notes/redisgraph/redisgraph-2.10-release-notes/)


Redis 7.2

Summary: What's new in Redis 7.2

Overview

Redis version 7.2 introduces new capabilities, including improved geospatial queries, and streamlined JSON data manipulation. Performance optimizations, client-side enhancements, and behavioral refinements further improve the efficiency, security, and usability of Redis.
Below is a detailed breakdown of these updates.

New features

Geospatial queries with polygon search

Redis Search now supports querying geospatial data using polygon search, enabling developers to efficiently filter and retrieve data within complex geographic boundaries.

Streamlined data manipulation in JSON

JSON now includes two new commands for improved data handling:

- `JSON.MERGE`: Merges a given JSON value into matching paths, allowing more flexible updates.
- `JSON.MSET`: Sets or updates multiple JSON values simultaneously based on specified key-path-value triplets, improving efficiency when handling structured data.

Improvements

Existing data structures

Significant performance improvements have been made across Redis data types. Sorted sets, commonly used for gaming leaderboards, now see performance improvements ranging from [30% to 100%](https://redis.io/blog/introducing-redis-7-2/#:~:text=We%20made%20Redis%20more%20powerful%20for%20developers).

Additionally, Redis stream consumer tracking has been enhanced to provide better visibility into consumer activity, and blocked stream commands now return a distinct error when the target key no longer exists.

Redis Search improvements

Redis Search has received several updates, including optimized `SORT BY` operations and the addition of a new `FORMAT` response in RESP3, improving both efficiency and readability.

Script execution enhancemets

Client-side tracking now monitors actual keys read during script execution, improving key usage tracking accuracy. Additionally, blocked commands will re-evaluate security checks before execution, ensuring compliance with updated permissions. Standardized ACL failure messages and error codes now provide clearer error handling.

Client and replication enhancements

TLS-based replication now supports Server Name Indication (SNI) to improve compatibility with secure deployments. The `HELLO` command behavior has also been refined to modify client state only upon successful execution, ensuring more predictable client behavior.

Changes

Breaking changes

Redis 7.2 introduces several backward-incompatible changes. Lua scripts no longer support the `print()` function, blocking of `PFCOUNT` and `PUBLISH` in read-only scripts, and time sampling freezing during command execution. Error handling updates include case changes in error responses, new behavior for `ZPOPMIN/ZPOPMAX` with `count 0`, and adjustments to `XCLAIM/XAUTOCLAIM`. ACL changes affect command categorization and key access permissions, while command introspection now includes per-subcommand statistics. Redis now allows certain `CONFIG` commands during loading and tracks statistics only when commands are executed.

For more details, see [Redis 7.2 Breaking Changes](https://redis.io/docs/latest/embeds/r7.2-breaking-changes/).

Expired keys are now deleted from replica indexes

Expired keys are now deleted from Redis Search replica indexes, ensuring that queries return an empty array rather than `nil` when the data no longer exists.

Other changes

Redis Stack 7.2 no longer includes Graph capabilities. For more details, refer to the [RedisGraph End-of-Life Announcement](https://redis.io/blog/redisgraph-eol/#:~:text=After%20January%2031%2C%202025%2C%20RedisGraph,subscriptions%20until%20January%2031%2C%202024.).

Component versions

The Redis version 7.2 includes the following components:

- [Redis 7.2](https://github.com/redis/redis/blob/7.2/00-RELEASENOTES)
- [Search 2.8](https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/release-notes/redisearch/redisearch-2.8-release-notes/)
- [JSON 2.6](https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/release-notes/redisjson/redisjson-2.6-release-notes/)
- [Time series 1.10](https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/release-notes/redistimeseries/redistimeseries-1.10-release-notes/)
- [Bloom 2.6](https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/release-notes/redisbloom/redisbloom-2.6-release-notes/)


Redis 7.4

Summary: What's new in Redis 7.4

Overview

Redis 7.4 introduces several new features and improvements aimed at enhancing memory efficiency, performance, and ease of use for various applications. These updates include support for hash field expiration, new memory-efficient data types for AI workloads, simplified secondary indexing, and time series optimizations. Additionally, Redis 7.4 brings several behavior and component changes.
Below is a detailed breakdown of these updates.

New features

Hash field expiration support

Redis 7.4 adds the ability to set expiration times for individual hash fields or adjust their remaining TTL. This feature, long-requested by users, improves memory efficiency and performance, especially in caching and session storage scenarios.

New memory-efficient data types for AI workloads

With the growing demand for AI applications, Redis 7.4 introduces `BFLOAT16` and `FLOAT16` data types. These new types reduce memory usage by up to 47% and lower latency by as much as 59% under load, making them ideal for storing and processing vector embeddings in AI-powered applications, including vector databases and Retrieval Augmented Generation (RAG) systems.

Time series optimization with insertion filters

Redis 7.4 introduces insertion filters for time series data, allowing sensors to ignore new measurements when the differences in time or value are minimal. This feature helps reduce the size of time series data and boosts efficiency.

Improvements

Simplified secondary indexing

Redis Search now offers a more straightforward approach to secondary indexing with the addition of the `TAG` index type. Querying tags with special characters (like `@` and `.`) is easier, as it no longer requires escaping; simply wrap query terms in double quotes. The update also includes improved handling of empty and missing fields, making the data model more flexible. Geospatial search has been enhanced with new operators, such as `INTERSECT` and `DISJOIN`, and memory usage reporting for indexes has been improved.

Changes

Behavior changes

Redis 7.4 includes behavior changes such as using jemalloc instead of libc for allocating Lua VM code. This adjustment reduces memory fragmentation and improves performance. Additionally, the `ACL LOAD` command has been modified to ensure that only clients with affected user configurations are disconnected, reducing unnecessary disruptions.

Component versions

The Redis version 7.4 includes the following components:

- [Redis 7.4](https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/release-notes/redisce/redisce-7.4-release-notes/)
- [Search 2.10](https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/release-notes/redisearch/redisearch-2.10-release-notes/)
- [JSON 2.8](https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/release-notes/redisjson/redisjson-2.8-release-notes/)
- [Time series 1.12](https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/release-notes/redistimeseries/redistimeseries-1.12-release-notes/)
- [Bloom 2.8](https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/release-notes/redisbloom/redisbloom-2.8-release-notes/)


Redis 8.0

Summary: What's new in Redis 8.0

Overview

Redis 8.0 introduces powerful new capabilities, including the beta release of the Vector Set data structure, designed for AI use cases such as semantic search and recommendation systems.

This release also delivers over 30 performance improvements, including:
- Up to 87% faster command execution
- Up to 18% faster replication

Additionally, the Redis Community Edition has been renamed to Redis Open Source, marking a shift toward a unified, modern distribution. This version offers the full power of Redis — no modules, no fragmentation — just Redis.

Below is a detailed breakdown of these updates.

New features

Vector set [beta]

The new `Vector set` data structure supports high-dimensional vector similarity search, which is ideal for AI use cases such as semantic search and recommendation systems. Vector set complements Redis’s existing vector search capabilities via Redis Search and is currently available in beta. APIs and behaviors may change in future releases.

New hash commands

Redis 8 builds on Redis 7.4’s introduction of field-level expiration in hashes and adds three new commands for working with hashes:
- [HGETEX](https://redis.io/docs/latest/commands/hgetex/): Fetch a hash field and optionally set an expiration
- [HSETEX](https://redis.io/docs/latest/commands/hsetex/): Set a hash field and optionally set an expiration
- [HGETDEL](https://redis.io/docs/latest/commands/hgetdel/): Fetch and delete a hash field

These commands simplify common caching and session management usage patterns.

Improvements

Redis Search Improvements

Redis Search allows users to use Redis as a document database, a vector database, a secondary index, and a search engine. With Redis Search, users can define indexes for hash and JSON documents, and use a rich query language for vector search, full-text search, geospatial queries, and aggregations.

Use cases include:

- Vector Search: Search based on semantic similarity using vector embeddings stored in `JSON` or `hashes`
- Exact Matching: Lookups using filters, tags, and ranges
- Full-Text Search: Supports stemming, synonyms, and fuzzy matching

Redis Search powers a wide range of applications, from AI retrieval-augmented generation (RAG) systems to full-featured search engines.

Access Control Improvements

Access Control Lists (ACLs) have been updated to support the new data structures introduced in Redis 8. Existing ACL categories such as `@read` and `@write` now include commands for `JSON`, `time series`, `VECTOR`, and `probabilistic` data structures.

These updates allow for more precise control over which operations users can perform on each data structure.

Performance improvements

Redis 8 delivers the largest performance leap in Redis history with over 30 optimizations, including:
- Up to 87% lower command latency
- 35% memory savings for replica nodes
- 16x more query processing capacity with horizontal and vertical scaling

These improvements benefit both single-node and clustered deployments. More details are available in the [Redis 8 GA](https://redis.io/blog/redis-8-ga/) blog post.

Changes

Breaking changes

#### ACL behavior
Commands from included modules are now covered under standard categories (e.g., `+@read`, `+@write`). For example, a user with `+@all` `-@write` will no longer be able to execute `JSON.SET` as they could before.
Explicit inclusion of new command categories is required to maintain access.

#### Redis Search

Other changes

#### One Redis
Over time, Redis introduced several modules to address new use cases such as search, vector similarity, time series analysis, and probabilistic modeling. While these modules extended Redis’s functionality, managing version compatibility and module installation introduced friction.

Redis Stack partially solved this by bundling modules together, but it also created fragmentation across the ecosystem.

Redis 8 merges Redis Stack and Redis Community Edition into a single unified distribution: Redis Open Source. All previously modular functionality is now built into the Redis Open Source package, eliminating the need to manage separate modules. You now get a single, consistent feature set across all deployments.

Component versions

Redis 8.0 delivers just Redis — no modules, no fragmentation.