[losfair]

(I work on Deno KV)

A read-modify-write retry loop causes a high number of commit conflicts, e.g. for atomic increments on integers. Getting higher than 1/RTT per-key throughput requires the "backend" to understand the semantics of the operations - apply a function to the current value, instead of just checking whether timestamp(value) < timestamp(txn.start) and aborting commit if not.

[pstuart]

A small tangent on the subject of databases on top of FDB -- mvsqlite is such an insanely cool project and it looks like it's gone quiet. Any plans to pursue that further?

For those that haven't seen it, SQLite on top of FoundationDB: https://github.com/losfair/mvsqlite

[ec109685]

Why not funnel all writes to a single region and leverage simpler transaction semantics.

[losfair]

Distributed consensus + fsync() determines the lower bound on commit latency. We have to wait for the data to be durable on a quorum of transaction logs before returning success for a transaction. That's usually 5-10ms, even within a single region.

[intelVISA]

5-10ms for consensus is forever!

[simultsop]

For user based keys, that sounds nice. Except on multiplayer cases, again in these cases one might find alternative solution rather than KV. I don't remember reading that any other service offers this speed.