to the folks asking why you'd use FDB, i'd highlight the main points as: > Interactive linearizable transactions (highest consistency level possible) over arbi

to the folks asking why you'd use FDB, i'd highlight the main points as: > Interactive linearizable transactions (highest consistency level possible) over arbitrary key ranges (none of this single partition transactions nonsense) with a guarantee that FDB will basically never violate this property. the transaction guarantees on FDB are just the best there is in any product you can get for free. not to fault the rest, FDB just went past what ~98% of folks will ever need. but if you're in that last 2%, god speed trying to get anything else to offer you the same semantics. > A strongly consistent store you can actually use in anger and that you don't have to baby. i've seen some folks trying to run a cluster without proper monitoring, who were nearly driving the poor thing into the ground, with hosts dying, and having so much pressure put on them they failed out, but it never lost anything. i don't think it ever even became unavailable. > Automatic range partitioning. So unlike Cassandra you don't have to pick a static partitioning key yourself, FDB just automatically detects and split ranges for you based on storage volume and write throughput eh, in defense of everything else, FDB is a key value store, and the keys are byte strings, so the situation is a bit easier for them.