With FDB latency shoots up when a bunch of writers compete to update the same entry, because writers can have to retry many times before the write finally goes

With FDB latency shoots up when a bunch of writers compete to update the same entry, because writers can have to retry many times before the write finally goes through, with a network round-trip each time. Personally I found this much harder to work with than a postgres queue with SKIP LOCKED for example. There's this however: "QuiCK: A Queuing System in CloudKit": https://www.foundationdb.org/files/QuiCK.pdf https://www.foundationdb.org/files/QuiCK.pdf. I suspect it really depends on what you expect from a queue, e.g. if you need strict FIFO or priorities, and how much effort you're willing to invest.