Hacker News Reader

I’d love to see a good primer on data models and scenarios that are well suited to FDB.

Their docs might be a good place to start. https://apple.github.io/foundationdb/developer-guide.html#da...

this is limited by your creativity and willingness to make tradeoffs.

the only really general statement i can think of is that the "larger"/"longer" your transactions are, the harder a time you'll have getting it to cooperate with FDB. "small"/"fast" transactions will be easier to fit into its model.

(to likely replies: this isn't an absolute, see all the quotes. yes things like redwood will alleviate some of this, but not all.)

IIRC fdb is fully optimistic concurrency control. It doesn't do any locking. If you have workloads which are highly contended, you'll need to do something in the layer above to coordinate. Otherwise, performance will be unbearable.

This may be out-dated, please let me know if the story has evolved here.

if your transactions are conflicting heavily with each other, yeah, you'll have a bad time. and if everything synchronizes on some small set of keys, you'll have a really bad time. monitoring the transaction conflict rate on your cluster is important.

Reply on news.ycombinator.com