# Valkey 9.2 RC1: Path Hash Is the Data Type Redis Never Built > Source: > Published: 2026-09-25 05:14:49+00:00 Valkey 9.2 RC1 landed on September 16 with the most consequential feature set since the Redis fork. The headliner is Path Hash — a brand-new radix-tree data type that Redis has no equivalent for. Add open-source ACL roles, forkless RDB snapshots, and a B+ tree replacement for sorted sets, and this release is where Valkey stops playing catch-up and starts pulling ahead. GA targets November 15. RC1 is available today. ## Path Hash: The Data Type Redis Never Built A new data type in a mature data store is a rare event. Path Hash earns that bar. It is a radix-tree structure exposed via `PH*` commands that does something no other Valkey type can: return all stored ancestor prefixes of a query path in a single atomic operation. The motivating use case is AI inference routing. When you are serving a large language model across multiple workers, each worker caches KV computation for specific token-sequence prefixes. Before routing an incoming request, you want to know which workers already have the longest matching prefix cached — that is the worker that gets the cheapest inference. With a regular Hash you cannot express “find all stored ancestor prefixes of this path” in one query. You would need multiple round trips or a client-side scan of every stored key. Path Hash collapses that to a single `PHPREFIXES` call. The same structure applies to [API route tables, hierarchical config lookups, CIDR prefix matching, and feature flag namespaces](https://github.com/valkey-io/valkey/issues/4498). Any time you need longest-prefix-match semantics over a large keyspace, Path Hash is the right tool. ``` # Store routes at different prefix depths PHSET route:/api/v1/users GET handler_a PHSET route:/api/v1 GET handler_b # Find all ancestor prefixes in one call PHPREFIXES route:/api/v1/users/123/profile GET # Returns: ["/api/v1/users", "/api/v1"] ``` ## Forkless Snapshots: Fix the BGSAVE Memory Spike If you have ever watched a 20 GB Valkey instance request 35 GB of free memory the moment BGSAVE fires, you know the problem. The traditional `fork()`-based snapshot creates a child process that shares the parent’s address space, but every write in the parent triggers a copy-on-write page fault. On write-heavy workloads, that doubles your resident memory. Large instances have also seen main-thread pauses in the hundreds of milliseconds while the kernel copies page tables. Valkey 9.2 ships an opt-in forkless path. Instead of a child process, a [background thread walks the dictionary and serializes keys](https://blog.elest.io/valkey-9-2-forkless-snapshots-bgsave-without-fork/) while the main thread keeps running. Overhead is four bytes per key — not a second copy of your dataset. The one trade-off: if the main thread writes a key the background thread has not yet serialized, that client briefly pauses while the key is moved to the front of the queue and flushed. For most workloads this is imperceptible. Enable it in two steps: add `forkless-infrastructure-enabled yes` to `valkey.conf` (requires restart, immutable), then set `CONFIG SET bgsave-default-method forkless` at runtime. RC1 has rough edges — module support requires explicit opt-in, and replica full-sync still uses fork. Test on replicas before deploying on primaries. ## ACL Roles: Open-Source RBAC at Last Redis Enterprise has had named, reusable ACL roles for years. Valkey 9.2 ships the equivalent open-source. A role is a named set of ACL selectors you define once and assign to as many users as you need. ``` ACL SETROLE readonly ~* &* +@read ACL SETROLE readwrite ~* &* +@read +@write -@dangerous ACL SETUSER service1 on >password role:readonly ACL SETUSER service2 on >password role:readwrite ``` Updates are zero-cost: users hold pointers to role objects, so changing a role instantly propagates to every user assigned it. Roles persist across restart via `CONFIG REWRITE`. For platform teams managing dozens of service accounts, this replaces a brittle copy-paste ACL management pattern with something you can actually audit. ## B+ Trees, INCREX, and EXEC IF Three more changes worth noting. First, large sorted sets switch from skiplist to B+ tree — `OBJECT ENCODING` returns `btree` instead of `skiplist` for affected sets. You change nothing in your code; you get approximately 24 bytes per item in memory savings and up to 7x faster rank lookups. Second, `INCREX` atomically increments a key and sets its expiry in one command, eliminating the non-atomic INCR-then-EXPIRE pattern that has caused subtle rate-limiting bugs since Redis 1.0. Third, `EXEC` now accepts `IFEQ`, `IFNE`, `NX`, and `XX` conditions as optimistic locking guards — cleaner than `WATCH` for many patterns. ## What to Do Now RC1 is available at [github.com/valkey-io/valkey](https://github.com/valkey-io/valkey/releases/tag/9.2.0-rc1). The project asks that you test against your workloads and report issues before GA. The GA window opens November 15. If you are running Valkey 9.1, there are no breaking API changes — this is an additive release. If you want to evaluate Path Hash, the [original design proposal](https://github.com/valkey-io/valkey/issues/4498) walks through the AI inference use case in detail. For forkless snapshots, start on a replica and run a representative BGSAVE workload before touching primaries. The [9.2 release plan issue](https://github.com/valkey-io/valkey/issues/4218) on GitHub is the best place to follow progress toward GA.