Most projects need to start with something and know that they will "be good". Many will hit RAM limitations earlier than kvrocks latencies or single-threaded CPU limitations (if they will – usually author doesn't need advice). Most would benefit from "moving fast" (in terms of development).
Redis-compatible protocol guarantees that you can think about the things you've mentioned later. If project is successful – you'll find money to pay for RAM and move to pure Redis. If it's CPU-bound – you'll find multi-threaded alternatives.
So this is a pretty nice niche IMO actually.
Why not use a managed Redis or a large memory instance and run Redis yourself then? They aren't that much more expensive if you need to move fast.
Yes, but why pay for it if `sudo apt install zedis` works? Many use-cases for redis growing out of memory would actually be ok if it stores old values on disk for you and keeps hot items in cache (and does compression).
It’s not feasible to do that in a single threaded system. The main drawback of disk persistence is that you need a log of memory to keep the file buffer open and pointers. If the key you’re looking for is not on disk, you’ll get awful results, the rdb format will give you worst then Postgres performance. You have to use another file format to optimize for a larger cache