I've seen
https://macrometa.co take a stab at an edge database, but their guarantees (consistency / correctness) don't really infuse any sort of confidence in me [0].
https://yugabyte.com is another global scale database that competes squarely with cockroach-db, though I haven't used either.
Cloudflare Workers KV has the simplest model, with a central-db that transparently and eventually only replicates read-only, hot-data specific to a DC but writes continue to incur heavy penalty in terms of operations-per-second, cost, and latency.
In our production setup, we back Workers KV with a single-region, source-of-truth DynamoDB [1] and employ DynamoDB Streams to push data to Workers KV [2], that is,
Writes (control-plane): clients -> (graphql) DynamoDB -> Streams -> Workers KV
Reads (data-plane): clients -> Workers KV
Reads (control-plane): clients -> (graphql) DynamoDB
[0] https://news.ycombinator.com/item?id=19307122
[1] We really should switch to QLDB once it supports Triggers.
[2] We do so mainly because we do not to be locked-down to Workers KV, especially at its very nascent stage.
Cloudflare Workers KV has the simplest model, with a central-db that transparently and eventually only replicates read-only, hot-data specific to a DC but writes continue to incur heavy penalty in terms of operations-per-second, cost, and latency.
In our production setup, we back Workers KV with a single-region, source-of-truth DynamoDB [1] and employ DynamoDB Streams to push data to Workers KV [2], that is,
Writes (control-plane): clients -> (graphql) DynamoDB -> Streams -> Workers KV
Reads (data-plane): clients -> Workers KV
Reads (control-plane): clients -> (graphql) DynamoDB
[0] https://news.ycombinator.com/item?id=19307122
[1] We really should switch to QLDB once it supports Triggers.
[2] We do so mainly because we do not to be locked-down to Workers KV, especially at its very nascent stage.