Our performance page (http://foundationdb.com/performance/ http://foundationdb.com/performance/) shows how we've worked very hard to provide predictable and low

Our performance page (http://foundationdb.com/performance/ http://foundationdb.com/performance/) shows how we've worked very hard to provide predictable and low latencies, even at saturating workloads [1] (on the order of 1ms for a read and 10ms for a commit). This means that transactions with 50 serial reads are still going to complete in two orders of magnitude less time than the maximum transaction duration (and futures make it easy to parallelize most reads). This is more than enough for client operations -- regardless of your database, you usually don't want to have a user wait for 5s, hold a lock for 5s, or be subject to conflicts for 5s. [1] Under saturating load, FoundationDB will queue transactions before assigning them a read version (starting the 5 second window), so that latencies within the transaction stay low. This explicit queuing also makes it easy to prioritize transactions, so you can mix latency-sensitive and saturating batch workloads safely.