WHITE PAPER 2 · DATABASE CACHING
Every cache must decide which entries to keep and which new entries to admit. Classic policies such as LRU, LFU and their adaptive descendants encode a fixed idea of what makes an entry worth keeping, and each works well on some access patterns and poorly on others.
Bassirah Technology — Innovation & R&D · 26 October 2026 · Free to share with attribution
Every cache must decide which entries to keep and which new entries to admit. Classic policies such as LRU, LFU and their adaptive descendants encode a fixed idea of what makes an entry worth keeping, and each works well on some access patterns and poorly on others. Learned cache replacement replaces or augments that fixed idea with a model trained on the workload’s own history. This paper surveys the field. It starts from the optimal offline policy that most learned approaches imitate and the relaxations that make it learnable. It then describes the main families of learned policies: online learning over expert policies, statistical models of object behavior, per-object prediction of the next access, heuristic-aided learning, group-level learning, and learning that tunes a simple heuristic off the critical path. It covers learned admission, prediction-augmented algorithms with worst-case guarantees, and applications to database buffer pools. It then discusses what it takes to run a learned cache in practice (features, delayed labels, inference cost, drift, objectives and safe rollout) and what recent studies show about how simple heuristics compare. It closes with adjacent work on KV-cache eviction for language models and on policies generated by language models, a qualitative comparison, open challenges and notes for platform decisions.
Paper 1 of this series described the classic eviction and admission policies. Each embodies an assumption: LRU that recent use predicts future use, LFU that frequent use does, ARC and its relatives that a balance of the two can be tuned online. Real workloads mix patterns, change over time and differ between tenants of the same cache, so no fixed assumption fits all of them. Learned policies take a different approach. They collect features of each entry’s past behavior, learn from what actually happened next, and use that knowledge to choose victims or admit new entries. Two developments made the idea practical: production traces that show how diverse cache workloads are [1], and research showing how to turn the optimal offline decisions into training labels [2], [3].
Paper 1 introduced Belady’s optimal policy, miss-ratio curves, the adaptive policies ARC, LIRS and 2Q, the TinyLFU admission filter, and the recent FIFO-based designs S3-FIFO and SIEVE. This paper assumes those foundations. Its question is narrower: when, and how, does learning improve on them, and at what cost? It uses the same evidence standard as the rest of the series, and it gives particular weight to studies that compare learned policies against strong simple baselines.
This paper covers learned eviction and admission for software caches: CDN and web caches, in-memory key-value caches, flash caches and database buffer pools. It cites hardware cache work where it introduced an idea that software caches later adopted, and it treats KV-cache eviction in language-model serving as adjacent work. It concentrates on peer-reviewed work from 2016 to 2026 and cites foundational work where needed. Preprints and workshop papers are identified as such. It does not report hit ratios, miss-ratio reductions, throughput or overhead figures; where a paper reports results, we describe them qualitatively and attribute them to the authors.
A policy decides which entry to evict (eviction) or whether to store a new entry (admission). A feature is a measured property of an entry, such as the time since its last access, its access count or its size. A label is the outcome a model learns to predict, such as the time until the entry’s next access; in caching, labels are known only after the fact, so they are delayed. An expert is a fixed policy, such as LRU, whose advice a learning algorithm may follow. Regret is the extra cost of an online decision compared with the best fixed choice in hindsight. Drift is a change in the workload that makes a trained model’s assumptions out of date.
Belady’s policy evicts the entry whose next use lies furthest in the future [4]. It needs knowledge of future requests, so no online cache can run it, but it can be computed on a recorded trace. That makes it both the yardstick against which policies are measured and, for most learned policies, the teacher: the model learns to predict what Belady’s policy would have done.
Belady’s policy is optimal only when all objects have the same size. Web and CDN caches hold objects of very different sizes, and with variable sizes, finding the optimal decisions is computationally hard. Berger, Beckmann and Harchol-Balter modeled caching as a min-cost flow problem to compute practical upper and lower bounds on the optimal policy, showing how much room remains above existing policies and providing near-optimal decisions that can serve as training labels [2].
Imitating Belady exactly is hard, because it requires ranking every entry by its next access. LRB relaxes the target: any entry whose next request lies beyond a threshold, which its authors call the Belady boundary, is an acceptable victim [3]. Under that relaxation, a policy need not find the single best victim, only a good one, so it can examine a small random sample of candidates and still find an entry beyond the boundary [3]. LHR takes a related route, computing an online upper bound on optimal hit probability and learning from its decisions [5]. These relaxations are what turned Belady’s policy from a theoretical bound into a practical training signal.
The literature can be grouped by what the model learns and at what granularity. GL-Cache’s authors distinguish object-level learning, learning from distributions, and learning from simple experts [6]; later work added heuristic-aided, group-level and parameter-tuning approaches. Table 1 summarizes the families; the subsections give detail.
| Family | What the model learns | Examples | Main cost | Main strength |
|---|---|---|---|---|
| Online learning over experts | Which fixed policy (or setting) to trust now | LeCaR, CACHEUS, Darwin, ALPS | Limited by the experts chosen | Low overhead; adapts quickly |
| Learning from distributions | Statistical model of behavior by age and size | LHD | Sampling many candidates per eviction | Principled, lightweight model |
| Object-level prediction | Next-access time, or its distribution, per object | LRB, Raven, 3L-Cache | Per-object features and inference | Closest approximation of Belady |
| Heuristic-aided learning | Preferences among a few candidates a heuristic proposes | HALP, MAT | A heuristic and a model to maintain | Low inference cost; deployable |
| Group-level learning | Utility of groups of objects | GL-Cache | Coarser decisions | Amortizes learning over many objects |
| Learning to tune a heuristic | Cache-level parameters of a simple policy | Learning-Augmented Heuristics (S4-FIFO) | Pre-training across traces | Simple data path; interpretable |
| Imitation and reinforcement learning | A policy from oracle actions or rewards, or expert weights | Parrot, RL-Cache, Zhou et al. | Training difficulty; model size | Can capture complex patterns |
The lightest form of learning keeps a set of fixed policies and learns which one to follow. LeCaR treats LRU and LFU as two experts and uses regret minimization to shift weight toward whichever expert’s evictions would have caused fewer misses [7]. CACHEUS extends the idea: it characterizes workloads as mixes of primitive patterns (LRU-friendly, LFU-friendly, scans and churn), introduces scan-resistant and churn-resistant experts, and learns which to trust as the workload shifts [8]. Darwin applies the approach to admission knobs in a CDN’s hot object cache, clustering traffic patterns and selecting among candidate settings with a neural bandit, so that the cache adapts when traffic shifts and can optimize different objectives [9]. ALPS uses a light model, fed by compact sketches, to choose among classic heuristics, addressing the objection that learned components keep per-item state and run on every access [10]. Expert-based learning is cheap and robust, but its decisions are limited by the experts in its set.
LHD predicts each object’s hit density, its expected hits per unit of space consumed, from conditional probabilities over its age and size that are re-estimated online, and evicts the object with the lowest hit density among a sample [11]. The model is statistical rather than a trained predictor, and it adapts in real time. Its authors implemented it in a memcached-based key-value cache designed to avoid synchronization in the common case [11].
Object-level policies predict, for each object, something close to what Belady’s policy needs. LRB regresses the logarithm of each object’s time to next request with gradient-boosted trees, using features that generalize those of classic policies: the gaps between consecutive requests, exponentially decayed counters at several rates, and static attributes such as size [3]. It samples objects from a sliding window, labels each when its next request arrives or when it passes the Belady boundary without one, retrains periodically so the model tracks the workload, and at eviction scores a small random set of candidates in one batch [3]. Its authors chose gradient-boosted trees because they need no feature normalization, tolerate missing values and are cheap to train and evaluate [3]. Raven learns the full distribution of each object’s next arrival time with a mixture density network and evicts the object most likely to be requested last, an explicitly probabilistic approximation of Belady [12]. 3L-Cache attacks the overhead of object-level learning directly, by filtering which requests become training data, adapting retraining frequency, sampling candidates with a bias toward less popular objects, and tuning its parameters per workload [13].
Object-level prediction is expensive when every eviction scores many candidates. Heuristic-aided designs let a classic policy propose a few candidates and let a model choose among them. HALP, built for YouTube’s content delivery network, has a heuristic such as LRU propose a small candidate set and a small neural network rank the candidates by pairwise comparison; the comparisons become training examples, labeled after the fact by which object was accessed first, and the model is updated online from a replay buffer [14]. Its authors argue that sampling many candidates per eviction costs too much CPU in production, and report that HALP has run as the eviction policy of YouTube’s CDN DRAM cache since early 2022 [14]. MAT, a preprint, follows the same pattern, using the heuristic as a filter that supplies both likely victims and useful training samples, so that the model needs only a few predictions per eviction [15].
GL-Cache amortizes learning across groups. It groups objects by insertion time, learns a utility for each group online, evicts the least useful groups, and uses lightweight per-object metrics to retain a few valuable objects from evicted groups [6]. Learning per group cuts training, inference and metadata costs, so throughput approaches that of simple heuristics, and group size becomes a knob that trades efficiency against throughput [6].
The most recent direction moves learning off the request path altogether. Learning-Augmented Heuristics splits the cache into a fast data path that runs a simple policy and a control path in which a model, pre-trained across many production traces, occasionally sets the policy’s cache-level parameters from cache-level features [16]. Its concrete policy, S4-FIFO, is a tuned variant of S3-FIFO; its authors present it as avoiding the large regressions of earlier learned policies and as interpretable, with a language model explaining the chosen configurations [16]. This design keeps the per-request cost of a heuristic while letting learning adapt it.
Parrot frames eviction as imitation learning: Belady’s oracle supplies the expert action, and a neural policy learns to mimic it from past accesses [17]. It is a research model evaluated in simulation, and its authors released an environment for cache-replacement research [17]. Reinforcement learning has been applied mainly to admission: RL-Cache learns a CDN admission policy with model-free reinforcement learning over a wide feature set, and its authors report that a model trained at one location transferred to others in the same region [18]. RL faces a structural obstacle in caching: the reward for a decision arrives long after it is made, because a large cache holds many objects; Wang et al. shortened the horizon by subsampling the trace and shrinking the cache, then transferring the policy to larger caches [19]. Zhou et al. avoid learning eviction from scratch: their deep reinforcement learning agent learns how to weight two conventional replacement policies according to the workload, for cloud block storage, with offline training constrained so that it does not disturb the live system [20]. Berger argued early that domain-specific supervised learning from optimal decisions is lighter and more robust than generic reinforcement learning for networked caches [21].
Several of these ideas first appeared in processor caches. Hawkeye simulates Belady’s policy on past accesses to learn which instructions tend to load lines worth keeping [22]. Glider trained a deep model offline to predict Belady’s decisions, then used insights from that model to design a simple online predictor that runs at hardware speed [23]. The lesson carries over to software caches: a heavy model can guide the design of a cheap one, but rarely runs in the hot path itself.
Admission decides whether a new object enters the cache at all, and it matters most where space or writes are expensive. AdaptSize, an analytical rather than learned policy, tunes size-aware admission continuously with a Markov model for the small memory cache of a CDN [24], and TinyLFU admits a new item only if its estimated frequency, kept in a compact sketch, exceeds that of the eviction candidate [25]. These are the baselines learned admission must beat. Flash caches add device endurance to the objective. Flashield uses DRAM as a filter and a lightweight learned predictor to admit to flash only objects likely to be read often without being updated [26]. Baleen, evaluated on traces from Meta’s storage clusters, learns admission and prefetching together to reduce peak load on backend disks [27]. Its authors describe early ML attempts that failed, a residency model they built to produce correct training labels, and a version that improved hit ratio while worsening the end-to-end metric they cared about, which led them to optimize disk-head time directly [27]. In their setting, gradient-boosted trees outperformed deeper models [27]. LHR also learns admission, pairing an auto-tuned, threshold-based admission model with a simple eviction rule and retraining only when it detects a workload change [5].
A learned policy can fail badly when its predictions are wrong, for example after a workload shift. Theoretical work on learning-augmented algorithms asks how to use predictions without losing worst-case guarantees. Lykouris and Vassilvitskii introduced the framework for caching: each request carries a prediction of the object’s next request time, and their algorithm is near-optimal when predictions are good while staying within classical worst-case bounds when they are bad [28]. Rohatgi gave improved algorithms and nearly matching lower bounds on how performance must depend on prediction error [29]. Wei showed that combining a policy that simply follows the predictions with a robust classical algorithm gives a simpler design with better trade-offs [30], and Antoniadis et al. extended robust use of predictions to a broader class of online problems that includes caching [31]. Chłędowski et al. tested these ideas on real caching data with learned predictors and found that a simple scheme, switching between the predictor-driven policy and a classical robust one whenever one falls behind, costs little when predictions are good and stays competitive when they fail [32]. The practical lesson matches the systems work in Section 4: keep a classical policy in the loop as a fallback.
Database buffer pools are caches with their own constraints: pages are fixed-size, the database controls concurrency, and replacement decisions sit on the hot path of every query. Research has applied learning here too. Yuan and Jin proposed retraining a model periodically on historical page requests, as a hot-or-cold classifier or as a regressor, to adapt buffer replacement to workload change, evaluated in simulation [33]. Learning has also been applied to prefetching, the complement of eviction: Hashemi et al. framed memory prefetching as sequence prediction with recurrent neural networks [34], and Chen et al. treated next-page prediction for database prefetching as classification [35]. These works are research prototypes; the database buffer caches described in paper 1, such as InnoDB’s midpoint-insertion LRU variant, use heuristic replacement. Production caches outside databases take the same pragmatic route. Redis approximates LRU and LFU by sampling a few keys rather than maintaining full orderings, uses a small probabilistic counter with decay for LFU, and lets operators trade CPU for accuracy by changing the sample size [36]. Any learned policy must beat such approximations on cost as well as on hit ratio.
Features describe each entry’s past: gaps between accesses, decayed counts, age, size and type [3]. More features improve predictions with diminishing returns, but each costs metadata memory per entry, which competes with the cache’s own capacity [3], [10]. Grouping [6] and cache-level features [16] reduce this cost.
Labels come from the future, so learned caches must wait to learn. LRB labels a sampled object when its next request arrives, or as beyond the boundary when none arrives in time [3]; HALP labels each pairwise comparison by which object was accessed first [14]; Baleen needed a separate residency model to construct correct labels [27]. Training is usually online and periodic so that models follow the workload [3], [14], although Learning-Augmented Heuristics pre-trains a single model across many traces [16].
The central obstacle to deployment is the cost of decisions. A cache serves requests at high rates, and a model consulted on every access, or one that scores many candidates per eviction, consumes CPU that the cache needs [10], [14]. The field has answered with sampling [3], [11], heuristic proposals of a few candidates [14], [15], biased sampling [13], grouping [6] and moving learning off the critical path [16].
Workloads change with time of day, releases and tenants. Online retraining lets a model follow them [3], [14], change detection retrains only when needed [5], and expert-based methods adapt by reweighting [7], [8]. Drift remains a risk: the Baleen authors note that learned policies in other settings tended to regress over time even with retraining [27].
Hit ratio is not always the objective that matters. Baleen’s experience shows that a policy can raise hit ratio while worsening backend load [27], Flashield and Baleen weigh flash writes [26], [27], and Darwin can target different objectives such as hit rate or disk writes [9]. A learned policy optimizes what it is trained on, so the training target should be the end-to-end metric the system cares about.
Production caches are noisy, so the effect of a policy change is hard to measure. HALP’s authors introduced an analysis method for measuring an eviction change’s effect under noisy production conditions [14]. Robust fallbacks [32], staged rollout and continuous comparison with a heuristic baseline are the practical safeguards.
Public traces and shared tools make learned and heuristic policies comparable. Twitter released anonymized one-week traces from its cache clusters [1], and Wikimedia has published anonymized CDN request traces in several rounds, which LRB’s evaluation used [37]. libCacheSim implements classic heuristics, FIFO-based designs, expert-based learners and learned policies in one harness, with LRB, GL-Cache and 3L-Cache available as optional builds [38]. LRB’s simulator and prototype are open source [3].
Recent studies set a high bar for learned policies. The Twitter study found that FIFO performed as well as or better than LRU for many production workloads [1]. Yang et al. showed that FIFO-based designs with quick demotion can outperform LRU and several complex policies, while scaling better [39]. S3-FIFO’s authors compared it directly with LRB on a sample of traces that included the Wikimedia traces from LRB’s own evaluation and found similar efficiency, with S3-FIFO far simpler, and they report that a small FIFO used as a flash admission filter outperformed Flashield’s learned filter in their tests on open CDN traces [40]. SIEVE, simpler than LRU, often matches or improves on more complex policies on web cache workloads and was adopted in several caching libraries [41]. W-TinyLFU remains a strong admission-plus-eviction baseline [25]. These results do not show that learning never helps: HALP’s production deployment [14] and the gains reported for learned admission on flash [27] show where it can. They do show that a learned policy should be compared with the strongest simple policies, on the workload at hand, with its cost included.
Language-model serving has its own eviction problem: the attention key-value (KV) cache grows with context length and batch size, and keeping all of it is often impossible. Several methods evict KV entries using signals from the model itself rather than a separately trained predictor. H2O keeps recent tokens together with “heavy hitters” that receive much of the attention [42]; Scissorhands relies on the observation that tokens that mattered at one step tend to keep mattering [43]; and SnapKV uses an observation window at the end of the prompt to decide which earlier positions to keep [44]. These are attention-guided heuristics, and they echo the recency and frequency signals of classic caches. Paper 3 of this series covers KV-cache reuse across requests.
A newer direction uses language models to write cache policies rather than to make cache decisions. PolicySmith searches over code generated by a language model to synthesize heuristics specialized for a particular deployment, applied to web cache eviction on libCacheSim and to congestion control; its output is readable code with no per-request inference cost [45]. A recent preprint applies LLM-guided program evolution to discover KV-cache eviction scorers and reports reward hacking during the search as a failure mode to design against [46]. Generated policies inherit the advantages of heuristics, low cost and inspectable logic, while the search, not the policy, carries the learning.
Table 2 compares the approaches in this paper. The ratings are qualitative and relative to each other; actual behavior depends on the implementation, workload and hardware.
| Approach | Decision cost per request | Adaptivity | Worst-case behavior | Interpretability | Production evidence in the cited work |
|---|---|---|---|---|---|
| Strong simple heuristic (S3-FIFO, SIEVE, W-TinyLFU) | Very low | Limited, by design | Predictable | High | Adoption in caching libraries |
| Online learning over experts | Low | Medium | Bounded by the experts | High | Prototypes |
| Object-level prediction | High | High | Can regress under drift | Low | Prototypes |
| Heuristic-aided learning | Low to Medium | High | Bounded by the heuristic's proposals | Medium | Production CDN deployment (HALP) |
| Group-level learning | Low | Medium to High | Coarser decisions | Medium | Implemented on an open-source production cache code base |
| Learning to tune a heuristic | Very low on the data path | Medium | Close to the underlying heuristic | High | Pre-trained on production traces |
| Learned admission for flash | Low to Medium | High | Depends on the objective chosen | Medium | Evaluated on production traces |
| Prediction with a robust fallback | Depends on the predictor | High | Bounded by the fallback | Medium | Experimental study on real data |
Challenge. A model that runs on every access or scores many candidates competes with the cache for CPU and memory [10], [14]. Research direction. Candidate filtering [14], [15], [13], grouping [6] and moving learning to a control path [16]. Opportunity. Learned policies whose data path is as cheap as a heuristic’s would remove the main barrier to adoption.
Challenge. Trained models can regress when workloads change [27]. Research direction. Prediction-augmented algorithms with worst-case guarantees [28], [30], practical switching to a robust fallback [32], and change detection [5]. Opportunity. Learned caches that never do much worse than a strong heuristic would make learning a safe default rather than a gamble.
Challenge. Optimizing hit ratio can worsen the metric that matters, such as backend load or flash wear [27]. Research direction. End-to-end objectives and multi-objective policies [27], [9]. Opportunity. Policies trained on cost, latency and device endurance together would align caching with platform goals.
Challenge. A model trained on one workload may not transfer to another; some work reports transfer within a region [18], but generality is unproven. Research direction. Models pre-trained across many traces [16] and workload characterization [8]. Opportunity. Policies that ship pre-trained and adapt lightly would suit multi-tenant platforms.
Challenge. Learned and heuristic policies have often been compared on different traces, with different baselines and without cost. Research direction. Shared simulators [38], public traces [1], [37], and head-to-head studies against strong simple baselines [40]. Opportunity. A common evaluation practice would show where learning helps and where it does not.
Challenge. Operators must understand and trust a policy before running it on critical systems. Research direction. Learned parameters for simple policies [16], and generated policies expressed as readable code [45]. Opportunity. Policies whose decisions can be explained and reviewed would fit change-management practice.
Challenge. Database buffer pools and query caches have strict concurrency and latency constraints, and published learned approaches remain prototypes [33], [35]. Research direction. Lightweight learned replacement and prefetching designed for database engines. Opportunity. Engines that adapt replacement and prefetching to their workload without tuning would reduce operational effort.
Challenge. Policies generated by language models can overfit to the traces used in the search, and search loops can be gamed [46]. Research direction. Program search with robust evaluation across traces [45], [46]. Opportunity. Generated, inspectable heuristics specialized to a deployment could combine the cost profile of heuristics with the adaptivity of learning.
Start with a strong simple policy and measure it: approximate LRU or LFU as provided by the cache, W-TinyLFU where available, or FIFO-based designs such as S3-FIFO and SIEVE. Record access traces and build miss-ratio curves, as paper 1 describes, so that any change can be evaluated offline first. Consider learning where the stakes justify it: very large caches, flash tiers where admission decides device wear, or workloads that change in ways a fixed policy cannot follow. When adopting a learned policy, prefer designs that keep a heuristic in the loop or tune a heuristic off the critical path, train on the end-to-end objective, keep a robust fallback, and roll out with measurement that can detect regressions.
For in-memory caching, Bassirah works with Redis as a Strategic Technology Partner; Redis’s sampled LRU and LFU policies, with tunable sample size and decay, are the kind of efficient approximation that learned policies must outperform on cost as well as hit ratio. Other products and projects named in this paper are ecosystem references. In each case, validate the policy on representative traces, workloads and versions before relying on it.
Product and project names are trademarks of their respective owners. Their mention describes publicly documented technology and does not imply a business relationship, except where Bassirah names a Strategic Technology Partner.
About this paper.
A technology survey of published research and publicly documented systems. It does not report Bassirah benchmarks or customer results. Product and project names are trademarks of their respective owners; their mention does not imply a business relationship, except where Bassirah names a Strategic Technology Partner.
THE SERIES
The foundation paper covers the core patterns; each research paper takes one frontier in depth.
Read and write strategies, cache architecture types, eviction and invalidation policies, and the common pitfalls with their mitigations.
Reusing answers and computation by meaning, with the correctness, access control and evaluation questions it raises.
Caches that span DRAM, CXL-attached memory and flash, and the placement and endurance trade-offs between tiers.
Bring one workload and its freshness requirements to a short architecture workshop. We will map it to the strategies in this paper and plan how to validate the design.