Isn’t it another ticking time bomb to accept writes that will be lost if the server is shut down?

Expecting that any key in redis will be there next time you read it is a ticking timebomb. Redis is not a database. It's a cache.

Unless you're using AOF mode with fsync always, you can lose writes. If you're doing that, you should be using a real database instead.

The first line of redis.io:

> The open source, in-memory data store

I don't mean to knock redis. I love redis. I implore you to benchmark Redis in FSYNC_ALWAYS vs Postgres. I encourage you to benchmark it as well with FSYNC_EVERYSEC and understand the tradeoffs that makes - Postgres is still very competitive with EVERYSEC in most workloads, and with a lot less tradeoffs in data reliability.

Yeah, in-memory. That should tell you it's not a persistent data store.

Also, comment out all `SAVE` to disable snapshotting so you can use the full machine RAM. Otherwise, you have to limit Redis to 50% RAM usage because Redis duplicates the dataset in memory when saving to disk, wasting half the machine's RAM. If you go over 50% RAM usage with snapshotting enabled you risk triggering bgsave error.

Finally, check out Redis-compatible alternatives that don't require the data set to fit in RAM. [0]

0: https://github.com/ideawu/ssdb