> Citus deployed in a cloud is a bit sensitive. As the master node keeps track of each worker in almost realtime fashion, any breaks in communication results i

> Citus deployed in a cloud is a bit sensitive. As the master node keeps track of each worker in almost realtime fashion, any breaks in communication results in corrupted shards. If you don't use just one user (postgres) but have different rights for different users, fixing the shards can be a pain (if you don't pay for the enterprise version, which provides you with helpful scripts). Citus supports two replication models: statement-based replication and streaming replication. [1] In statement-based replication the master directly writes to several replicas. If writing to a particular replica fails due to a network issue, then to maintain both availability and read-your-writes consistency, the master marks that replica as inactive to be repaired at a later time. In streaming replication there is primary and secondary worker. The master only writes to the primary which replicates its changes to the secondary. If writing to the primary fails, then the transaction rolls back and no repair is necessary. If the primary goes down, it can be replaced by the secondary. In this model the master doesn't have to keep track of any state or perform any special locking, which is also what enables Citus MX [2]. Citus Cloud exclusively uses streaming replication with automated failover, meaning shards never have to be repaired. [1] https://www.citusdata.com/blog/2016/12/15/citus-replication-model-today-and-tomorrow/ https://www.citusdata.com/blog/2016/12/15/citus-replication-... [2] https://www.citusdata.com/blog/2016/09/22/announcing-citus-mx/ https://www.citusdata.com/blog/2016/09/22/announcing-citus-m...