CockroachDB is another good option, as would Cassandra depending on need. At least for geodistribution. If the data is large, then bringing it fully to a client wouldn't work so well. If it's mostly read, then a great number of options exist there as well.
Today no good options exist for databases on the edge (think CDNs) or even right on the client. But enough of the research if you want to make it yourself. You can have a partial view of the database on an edge node or a client with updates merging and propagating without conflicts.
It's CRDT-based automatic merging of JSON-like structures with core and edge nodes. It looks like it's called Kuhiro now, although the status is unknown: https://www.kuhiro.com
CRDB doesn't quite handle multiple separate regions yet, it treats all nodes as part of the same cluster. There is a 'locality' feature but they're still working on local reads functionality using that for queries.
Comments
CockroachDB is another good option, as would Cassandra depending on need. At least for geodistribution. If the data is large, then bringing it fully to a client wouldn't work so well. If it's mostly read, then a great number of options exist there as well.
Today no good options exist for databases on the edge (think CDNs) or even right on the client. But enough of the research if you want to make it yourself. You can have a partial view of the database on an edge node or a client with updates merging and propagating without conflicts.
There was Datanet: http://highscalability.com/blog/2016/10/17/datanet-a-new-crd...
It's CRDT-based automatic merging of JSON-like structures with core and edge nodes. It looks like it's called Kuhiro now, although the status is unknown: https://www.kuhiro.com
Redis will add a client cache on the protocol/client.
CRDB doesn't quite handle multiple separate regions yet, it treats all nodes as part of the same cluster. There is a 'locality' feature but they're still working on local reads functionality using that for queries.