Hacker News new | past | comments | ask | show | jobs | submit login

I feel dumb asking, what’s the common use case for FDB. And how does it compare to Redis?

I’ve read lots about how fantastic FDB (and unique) but I’m struggling to understand the use case / problem to use it for.




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.

Here's a video playlist from several other companies talking about it at FoundationDB Summit: https://www.youtube.com/playlist?list=PLbzoR-pLrL6oWYrC950yA...


This was a great, very detailed answer to a fairly open-ended question, and I appreciate that a lot.


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.

For example, there is a MongoDB layer on top of FoundationDB: https://www.foundationdb.org/blog/announcing-document-layer/


from website

"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.


Transaction support, not just on a key but across multiple keys. Not many key/value DB support transaction.


Redis loses data, it has to be a cache. And it range scans only on individual machines. Eg, it doesn't scale, you have to scale it.

Foundation is transactional correct on a cluster, and supports range scans.


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: