Postgres-BDR works very well for its intended business use case, which is geographically distributed multiple master database. Master-slave replication is not comparable cos there is only one master. You should use as few masters as your business case requires, so it is possible you don't need BDR at all. The underlying technology is roughly the same between master-slave and master-master, so that is not a big distinction and not the key point.
Postgres-BDR is designed to solve a common problem: access to a database from users all around the world. In cases where you have a single master and multiple standbys then all write transactions must be routed globally to the same location, adding 100s of milliseconds latency and in many cases making applications unusable.
Postgres-BDR offers the opportunity to make those writes to multiple copies of the database in different locations, significantly reducing the latency for users.
What BDR doesn't solve is what you do if all your users want to update the same data at the same time. But that type of application is just not scalable. If you run such an application on any database that gives you perfect consistency and lots of other shiny buzzwords, all you get is a really, really slow application, just like you had in the first place. But it will tick all the keywords.
All distributed systems require you to understand the business case and the trade-offs required to make it work. This is not fancy technology to use because you think its cool, its for use where it is useful and important to do so. BDR gives you the tools to know whether your application will work in a distributed manner and to keep it working in production without fear.
I could'n agree more. Be _very_ careful with this illusion. Multi-master replication implementation like this makes sense for very few use cases and even then the development team better know what the hell are they doing or a lot of unwanted/unaccounted things will show up in production
But you have a point. Not all semantics are suspended, only atomicity, isolation and consistency.
Durability has become probabilistic, because merge conflicts with a concurrent mutation from another host can discard our change.
>offering performance about x100 what is possible with eager consensus
And what's the performance gain over regular asynchronous master-slave replication? All nodes have to process all mutations at some point, no?
>but this is multi-master - why would you read two nodes when all the data is on one node?
The "why" is because my use-case requires consistent reads and the business risk of inconsistent reads is unacceptable.
I am guessing you are working on the project? It scares me that you are asking this question.
It remains to be seen how many people are happy with such trade-off. I claim total ignorance here - it could be millions :)