It speaks Redis so ideally it can replace Redis in cases where persistence is required.

There are already several community solutions for Redis persistence - this one provides different guarantees.

The name implies the goal is to make it easy to mix "hot" (from memory) and "cold" (from disk) data. The author suggests this.

Redis itself already supports a number of persistence schemes and has since the beginning: https://redis.io/topics/persistence

That's a good point and I should have been clearer.

I might be off (and probably am) but if I remember correctly Redis persistence is more for disaster recovery - you can create snapshots and recover them or replay a log file. That's very different in terms of performance guarantees from persisting the data itself to disk and reading from it.

I was under the impression that's what tools (like this one) and stuff like Ardb try to solve.

I wouldn't call it disaster recovery per se.

It's just that Redis is mostly an in-memory database and if the process is terminated and restarted (for all sorts of reasons) the data can be restored from disk.

So what IceFireDB might be good for is data which would not fit easily into the memory of one node.

Again, it's really not clear to me.

I often see projects like this posted on HN, and it's very unclear to me what the actual use case is. Does anyone even end up actually using these things? I guess the developers hope it takes off, and they gain notoriety as 'the guy who made X'?

It's unclear.

Youre right. Redis will persist either the AOF or log but your whole dataset must fit in memory (the AOF file is used to fill existing memory on boot).

I'd guess for "I want redis, but more durable clustering" (although I don't quite remember how much redis nowadays offers there itself). Would want a lot more info before trusting it for that though.