> We are looking closely at moving to FoundationDB at some point.
I'm curious to better understand the use case where this change makes sense.
CockroachDB does a lot more than FoundationDB. FoundationDB is pretty much just a KV store. There are layers out there but they IIUC they have immature drivers. Have you had success developing applications on top of any of them?
Do features like secondary indexes, joins, or constraints matter for your use case?
A big thing cockroach does that foundation doesn't help with at all is contention. If transactions contend in foundation, they will fail with retriable errors at commit time. The process of coordinating concurrent read-write and write-write interactions fall onto the layer implementer. This is a huge burden. Cockroach has an increasingly advanced story around concurrency control. It's a problem which should not be understated.
Other important properties are:
* Rolling upgrades
* Long-running transactions (they are starting to have a story about read-only transaction with the new storage engine)
* Online schema changes coordinated by the system.
* FoundationDB has a nascent story around multi-region which seems doomed to poor performance and even then only exists to provide higher availability at the cost of synchronous replication (i.e. there is no geo-partitioning).
I don't want to sound overly critical about FoundationDB. It's a very cool piece of software for a single-region, scale-out, consistent KV that, for right use-case, which is low-contention or externally coordinated, can probably deliver a high degree of predictability.
edit: I work on CockroachDB.