Redis 8.10 and 8.12: Compact Hashes, Online Backups and Upgrade Planning

Redis Open Source 8.10, released in July 2026, changes two things that operators care about: how much memory object-shaped data needs, and how backups are taken. Compact hashes store shared field names once for many keys. A new BACKUP command family produces restorable backups without stopping writes. Redis 8.12 reached its first release candidate in October 2026 and continues the memory theme.

This article explains both features, their limits and the security releases that arrived alongside them, then sets out an upgrade plan. It covers self-managed Redis Open Source. Redis Software and Redis Cloud have their own feature sets and backup mechanisms, which differ by product and contract.

Where the release lines stand

The Redis Open Source release notes listed these lines on the research date:

Version	Date	Status
8.12-RC1	October 2026	Release candidate; the notes state pre-releases are not suitable for production
8.10.1	August 2026	Patch release marked with security update urgency
8.10.0	July 2026	General availability
8.8.2	August 2026	Patch release marked with security update urgency
8.6.0	February 2026	General availability

The Redis licenses page states that from Redis 8, a user may select one of three licences for Redis Open Source: RSALv2, SSPLv1 or AGPLv3. Redis 7.2.x and earlier remain under BSD-3-Clause, and Community Edition 7.4.x to 7.8.x under RSALv2 or SSPLv1. Teams upgrading from 7.2 to 8.x are therefore also changing licence terms, and should record which option they select. Your legal team should confirm that choice.

The security releases come first

Before new features, look at what the 2026 patch releases fixed. The 8.10 release notes list, for 8.10.1, fixes that include memory corruption from a malicious RDB payload that may lead to remote code execution, several Vector Sets issues during RDB loading and concurrent use, and a TLS client certificate authentication bypass involving an embedded NUL byte in a certificate Common Name. The 8.8 release notes record related fixes in 8.8.1 and 8.8.2, and several CVEs in 8.8-RC1 where invalid memory access in RESTORE may lead to remote code execution.

Two practical lessons follow:

• Stay on a current patch release. If you run 8.8 or 8.10, the patch releases are the minimum. Older lines should be assessed against these notes.
• Treat serialized data as untrusted input. Many fixes concern loading RDB files or RESTORE payloads. Restrict RESTORE and related commands through ACLs, and only load RDB or AOF files from sources you control.

Compact hashes: one copy of field names for many keys

Many applications store objects as hashes: one hash per user, order or session, each with the same field names. The hashes documentation describes compact hashes as an internal encoding that stores the shared set of field names once, keeping only the values and a small reference in each key. Existing hash commands keep the same semantics and replies.

The documentation is clear about when the encoding helps and when it does not:

Good fit	Poor fit
Many keys share the same, mostly stable field names	Field names are added or removed often; each change moves the key to a different field-name set
Reads and overwrites of existing fields dominate	Field names are unique per key, so sets carry overhead without sharing
Hundreds or thousands of keys share a set	Very large hashes, which are transferred as a single blob during replication and slot migration

Two behaviours deserve a note in your design record. Once a hash becomes a compact hash, it stays one for the life of the key. And a hash that uses field expiration is not converted.

Opting in

There are two ways in. The first is the new HIMPORT command family, available since 8.10.0. A client declares a fieldset once with HIMPORT PREPARE and then creates keys with HIMPORT SET, sending only values. Fieldsets belong to the connection that declared them. The hashes documentation notes that most client libraries mark their HIMPORT support as experimental, and that HIMPORT SET replaces an existing key rather than merging into it.

The second is automatic conversion, for applications that cannot change code. All the related settings default to 0, meaning off:

• hash-min-template-entries and hash-max-template-entries convert eligible hashes lazily, on their next write.
• hash-rdb-load-min-template-entries, hash-rdb-load-max-template-entries and hash-rdb-load-template-disassembly-threshold convert plain hashes while an older RDB loads. They are effectively one-time upgrade settings: an RDB that already contains compact hashes loads as-is.

The disassembly threshold returns poorly shared sets to plain hashes at the end of a load, and Redis stops creating new sets partway through if most are below the threshold. To measure the effect, the What’s new in 8.10 page lists new metrics: hash_templates and hash_template_keys in INFO STATS, and used_memory_hash_templates in INFO MEMORY. Compare memory on a copy of production data before enabling conversion on a live primary.

Online backups with the BACKUP command family

Backing up an AOF-only instance used to mean pausing automatic rewrites while copying files. The persistence documentation describes the 8.10 alternative: the BACKUP family produces a self-contained, restorable backup without stopping writes or manually managing rewrites. The artefact set reuses the multi-part AOF format: a BASE snapshot, an INCR file of later writes, and a manifest.

1. BACKUP START opens a backup window and produces a fresh BASE snapshot, whether or not AOF is enabled.
2. BACKUP LIST returns the paths of files pinned so far, so copying the BASE can begin early.
3. BACKUP SEAL freezes the backup and writes the manifest.
4. Copy the sealed files to backup storage outside the machine and site.
5. BACKUP CLEANUP releases the pinned files.

A restore loads BASE plus INCR, so it reflects the seal point. Restores use the startup-only preload-file setting pointed at the manifest. If the target is missing or cannot be loaded, startup aborts, which is the safer failure.

Operational details from the BACKUP START page and the persistence page:

• The backup directory, set by the startup-only backupdirname, must be empty, and only one backup can run at a time.
• BACKUP START sits in the @admin and @dangerous ACL categories. Grant it only to the backup identity.
• backup-sealed-ttl defaults to 0, so sealed files stay pinned until cleanup. Monitor disk space if a copy job fails.
• Because start and seal are separate, a control plane can stagger BACKUP START across cluster nodes so they do not all fork at once.
• The command page marks BACKUP START as not supported on Redis Software or Redis Cloud, which provide their own backup features.

A backup that has never been restored is an assumption. Schedule restore tests into a separate instance and check key counts and sample values.

Other 8.10 changes worth knowing

• Search queries enforce TIMEOUT more strictly, and search-on-timeout gains a RETURN_STRICT option alongside FAIL and the default RETURN. Review timeout handling in search-heavy applications.
• XREAD and XREADGROUP accept MAXCOUNT and MAXSIZE to cap reply size, which helps protect consumers from oversized replies.
• New list and set commands include LMOVEM, BLMOVEM, SUNIONCARD and SDIFFCARD.
• redis-cli --cluster reshard and rebalance now move slots with server-side atomic slot migration.

What 8.12 previews

The 8.12 release notes describe a release candidate, so treat these as items to test, not to deploy:

• Compressed bitmaps through redis-roaring integration, enabled by bitmap-default-roaring, which is off by default.
• Expiration on individual set members, with SEXPIRE, STTL and related commands.
• A BLESS command to avoid eviction of specified keys, relevant where cache and durable keys share an instance.
• Search behaviour changes, including stricter numeric argument parsing and a Search module that requires Redis 8.9.241 or newer.

An upgrade plan

• Record the current version, licence option and modules in use; confirm the licence choice for 8.x.
• Move to a current patch release first, then plan feature adoption separately.
• Restrict RESTORE, BACKUP and other administrative commands with ACLs.
• Upgrade replicas before primaries and test failover on the new version. Confirm, in a test, how older replicas and tools handle data written with new encodings before enabling them.
• Measure compact hash savings on a copy of production data before enabling automatic conversion.
• Replace ad hoc AOF copy scripts with the BACKUP workflow where self-managed, and test a restore end to end.
• Keep 8.12 in a test environment until it reaches general availability.

Our platform reliability and optimization work covers this kind of staged change.

How Bassirah can help

Redis is a Bassirah strategic technology partner. We help teams plan Redis upgrades, assess compact hash savings on their own data, and build and test backup and restore procedures, whether on Redis Open Source or a Redis commercial product. See our Redis partner page. Edition, licensing and support entitlements are confirmed in each engagement.