[SamReidHughes]

100%. I don't have the time to read the paper but online schema changes, with the ability to fail and abort the entire operation if one row is invalid, are basically the same problem as background index building.

If instead of using some generic K/V backend, it made use of specific FDB features, it might be even better. Conflict ranges and snapshot reads have been useful for me for some background index building designs, and atomic ops have their uses.

> Oh yes, it also has a Raft implementation, so if you want multi-cluster FDB with Raft-driven failover you could do that too (iirc, FDB doesn't have this out of the box).

I don't know what you mean by this. Multiple FDB clusters?

[mike_hearn]

It supports atomic ops and snapshot reads. Don't remember about conflict ranges. It doesn't require all backends to be identical, it supports a kind of graceful degradation when backends don't have all the features. The creator is quite keen on FDB and made sure Permazen works well with it.

Yes multiple FDB clusters. IIRC FDB replication doesn't support full geo-replication, or didn't. There's a post by me about it somewhere on their forums.