BDR compared to PostgreSQL's built-in streaming replication

BDR is very different to Pg's existing streaming replication, though it builds on some of the same infrastructure.

Key differences:

BDR supports multiple masters. All members are writeable nodes that replicate changes.

BDR doesn't send VACUUM traffic, index updates, full page images from full page writes, etc over the wire. Only data rows, DDL, and internal co-ordination data are sent. This saves a huge amount of bandwidth on some workloads.

BDR replicates per-database, not per-cluster. So you don't have to split your databases up into different PostgreSQL instances just to control how they replicate.

Unlike built-in SR, you can't combine BDR with WAL archiving. It only transfers data when there's a direct TCP connection between the servers.

There's no warm-standby or PITR with BDR. It only has only multi-master mode (though the underlying Logical Log Streaming Replication facility is capable of single-master hot-standby configurations).

There are also some implementation limits that will be progressively removed:

BDR compared to trigger-based replication

BDR has a lower impact on the master(s) than trigger based replication solutions. There is no write-amplification, as it does not require triggers to write to queue tables in order to replicate writes.