Redis Enterprise can keep part of a dataset on SSD rather than entirely in RAM (marketed as Auto Tiering, previously Redis on Flash). How does that work, what workload does it assume, and why is it not a durability feature?

## Why the feature exists RAM is the dominant line item in a large Redis deployment. Many datasets, though, are strongly skewed: a small hot subset serves most of the traffic while a long cold tail is retained because it is occasionally needed. Paying DRAM prices for the cold tail is wasteful, and evicting it is not acceptable when it must remain queryable. Auto Tiering (formerly Redis on Flash) targets exactly that shape — it lowers cost per gigabyte by putting the cold tail on local NVMe SSD while keeping the hot path in memory. ## How the tiering works Within a shard, memory holds the structures that must be traversed on every request: the keyspace dictionary, key names, expiry information, and the values currently considered hot. Values that go cold are written down to an embedded storage engine on local flash and their in-memory representation is released. On access to a cold value, the shard reads it from flash and promotes it back to RAM; something else is demoted to make room. The policy is driven by access recency/frequency and by a configured RAM-to-flash ratio per database, so an operator effectively declares how much of the dataset should be resident. Two structural consequences follow: 1. **Metadata is never tiered.** Key names and the dictionary stay in RAM, so RAM consumption scales with the *number* of keys no matter how cold they are. A billion 20-byte values gains little from tiering; a hundred million multi-kilobyte values gains a lot. 2. **Value size drives the benefit.** Bigger values mean more bytes moved off DRAM per unit of retained metadata, and better amortisation of each flash read. ## The workload assumption, stated plainly The entire economic argument rests on **skew**. If 90% of requests hit values that are resident in RAM, the average latency stays close to an all-RAM database and only the remaining 10% pay a flash read. If access is uniform over a dataset several times larger than RAM, nearly every request becomes an SSD read: latency moves from single-digit microseconds to hundreds of microseconds or milliseconds, tail latency degrades much further, and the shard — which executes commands one at a time — is now blocked on I/O where it used to be blocked on nothing. That means the honest evaluation criteria are: measure the working-set size and the hit ratio you would get at the intended RAM ratio, and check whether your latency SLO tolerates the miss path at your miss rate. Write-heavy workloads that constantly dirty cold data are the least suitable, because they generate flash writes as well as reads and consume device endurance. ## Why it is not durability This is the most common misconception and the one an interviewer is probing. The flash tier holds part of the **live dataset**, not a recovery copy. It is local to the node, it is not designed to be replayed after a crash, and losing the node loses that shard's data exactly as it would in an all-RAM configuration. Durability and availability come from the same mechanisms as always: snapshot and/or append-only persistence configured per database, and replica shards on other nodes for failover. Tiering is orthogonal — you can and normally do enable both, and one does not substitute for the other. ## Operational notes - **Local NVMe is required.** Network-attached storage defeats the latency budget the design assumes. - **Provisioning is per database**, expressed as a RAM/flash ratio, so different databases on the same cluster can make different choices. - **Restart and failover are slower** than for an all-RAM database of the same *hot* size, because the shard has more total data to bring back into a serving state. - **Monitor the resident-hit ratio, not just memory usage.** Memory looking comfortable while hit ratio drops is the early signal that the working set has outgrown the RAM tier. ## When to choose it Good candidates: large caches or key-value stores with pronounced hot/cold skew and reasonably sized values — user profiles, product catalogues, feature stores, session archives — where the cold tail must remain accessible and the SLO can absorb an occasional flash read. Poor candidates: latency-critical paths with tight tails, uniformly accessed datasets, huge counts of tiny keys, and write-dominated workloads over cold data. As with the rest of the Enterprise capability set, the interesting answer is not that the feature exists but that its benefit is entirely contingent on an access-pattern assumption you should verify before adopting it.