Bidirectional Replication is coming to PostgreSQL 9.6
Holy crap, I am scared!<p>Please, please, please read the fine print and ensure you understand the design tradeoffs as well as your application&#x27;s requirements before blindly using this.<p>The moment I heard multi-master I thought Paxos, Raft or maybe virtual synchrony. Hmm, nothing in the documentation. Maybe a new consensus protocol was written from scratch then? That should be interesting!<p>No, none of that either - this implementation completely disregards consistency and makes write conflicts the developer&#x27;s problem.<p>From <a href="http:&#x2F;&#x2F;bdr-project.org&#x2F;docs&#x2F;stable&#x2F;weak-coupled-multimaster.html" rel="nofollow">http:&#x2F;&#x2F;bdr-project.org&#x2F;docs&#x2F;stable&#x2F;weak-coupled-multimaster....</a><p>* Applications using BDR are free to write to any node so long as they are careful to prevent or cope with conflicts<p>* There is no complex election of a new master if a node goes down or network problems arise. There is no wait for failover. Each node is always a master and always directly writeable.<p>* Applications can be partition-tolerant: the application can keep keep working even if it loses communication with some or all other nodes, then re-sync automatically when connectivity is restored. Loss of a critical VPN tunnel or WAN won&#x27;t bring the entire store or satellite office to a halt.<p>Basically:<p>* Transactions are a lie<p>* Consistent reads are a lie<p>* Datasets will diverge during network partitioning<p>* Convergence is not guaranteed without a mechanism for resolving write conflicts<p>I am sure there are use-cases where the risk of this design is acceptable (or necessary), but ensure you have a plan for dealing with data inconsistencies!