We’re presenting a new FoundationDB feature that is currently worked on as a collaboration project between Apple and Snowflake. If a key-range (or a single key) is very read-hot, the storage processes will start to run out of resources. Currently, the only mitigation for this is to either change the access pattern or implement a caching functionality on top of FoundationDB. Both of these are difficult to implement and often need special implementations depending on the consistency requirement. We’re currently working on a solution for hot read ranges that attacks this problem from two angles: (1) allow for some key-ranges to be held in memory and (2) increase the replication factor for read-hot ranges. (1) will take rad-load off disks while (2) will allow using more CPUs to handle the load. This cache will provide the same consistency guarantees as the rest of FoundationDB. The administrator will have the option to define ranges and replication factors for certain ranges and additionally, FoundationDB will detect ranges that are read-hot and not write-hot and will start to cache them automatically