You can configure redis to flush to disk on write operations though you lose on performance.

That is not comparable to writes completing after they are flushed to disk.

>appendfsync always: fsync every time new commands are appended to the AOF. Very very slow, very safe. Note that the commands are appended to the AOF after a batch of commands from multiple clients or a pipeline are executed, so it means a single write and a single fsync (before sending the replies).

https://redis.io/docs/management/persistence/

It's very slow, but if you really want to wait for fsync before replying, it can do that.

I was unaware they could make that guarantee.

Thanks for the correction.

Redis can be configured to persist and fsync every operation.

Redis is not meant as a primary database and should not be used as such. FoundationDB is meant as a reliable source of truth.

Redis began as a caching database, but it has since evolved into a primary database. Many applications built today use Redis as a primary database.

https://redis.com/blog/redis-cache-vs-redis-primary-database...

Very much seems like an acceptable use now

Redis can't have a working set larger than memory. It has no mechanism to page data to disk. If your data set grows too large, you're hosed unless you add more hardware.