Very cool, I have been keeping an eye on PG's multi-master developments since last summer. It looks like this implementation prioritizes the Consistency side o

Very cool, I have been keeping an eye on PG's multi-master developments since last summer. It looks like this implementation prioritizes the Consistency side of CAP, presumably to the detriment of it's ability to handle network partitions. This is a great option to have alongside the classic multi-master data store, which prioritized partitionability and availability, CouchDB and friends. There are applications where going slow, or even failing, is less bad than showing an inconsistent state, and that is where this would shine. I am curious though, could something like this be used like PouchDB, where each one of millions of clients runs a DB master that has a replica of a subset of the "canonical" state? Is that sort of capability a long-term goal, perhaps by means of a modified SQLite? Or, does this inevitably give any one client the power to DoS other clients just by playing dumb and clumsy with incoming data, when consistency is guaranteed? For the record, my experience with CouchDB is minimal; I have not scaled CouchDB beyond experiments with a handful of containerized masters.