Most apps can use a single-instance relational database or document store. Fast enough with plenty of features. When requirements increase, there are many distributed relational and document stores that provide more scalability and performance.
Key/value stores offer a low-level API to handle extreme requirements when nothing else works. An example is adtech platforms where user profiles and contextual data need to be accessed in a fraction of a second to respond to an ad request, often hitting queries-per-second in the 6/7 figure range. Another example is CDNs that need to lookup a specific piece of data across a large dataset very quickly.
As of 2022, there are plenty of key/value stores like Redis, HBase/Bigtable, Aerospike, ScyllaDB that have various trade-offs in speed, scale and flexibility. What sets FDB apart is strong consistency (supporting transactions across multiple keys) and extreme reliability which makes it a good choice as a core metadata and coordination service that other complex apps and distributed systems can rely on.
For example, Apple uses it as a backend for CloudKit, and Snowflake uses it to store the metadata and operations of its cloud data warehouse.
You can build a distributed SQL database on top of FDB, or some other kind of database. It has everything you need to build primary and secondary indexes, including not just transactions but also being able to specify weaker consistency guarantees, the sort of stuff that is useful for internals like, IIRC, building secondary indexes in the background such that they don't conflict (much?) with writes. Its API is very, very nice for this.
"Multi-model data store. FoundationDB is multi-model, meaning you can store many types data in a single database. All data is safely stored, distributed, and replicated in the Key-Value Store component.
Easily scalable and fault tolerant. FoundationDB is easy to install, grow, and manage. It has a distributed architecture that gracefully scales out, and handles faults while acting like a single ACID database."
I've never used it personally but the claims are ACID transactions, persistence, distributed, and reliable.. So basically if you want something like Redis, but also want transactions, scale up across multiple machines and higher reliability.
Care to comment a bit further about losing data? There are two different persistence methods offered by Redis at the moment. https://redis.io/topics/persistence
I’ve read lots about how fantastic FDB (and unique) but I’m struggling to understand the use case / problem to use it for.