[jvdongen]

This is a disingenuous comment at best.

As explained in the docs you link to, Postgres has both synchronous and asynchronous replication modes.

In asynchronous mode availability is favored over durability. Which means commits can get lost when the primary goes down in an uncontrolled fashion.

In sync mode that will not happen at a cost to some performance.

It’s the same trade-off any distributed system has to make, and the user gets to make the choice.

[Spivak]

MySQL can actually do one better which is semisync. The transactions get replicated synchronously but applying them is async. You can't lose data anymore due to a primary failure.

[jvdongen]

Postgres has a similar feature, if you chose ‘remote_write’ for the ‘synchronous_commit’ setting.

You can also mix and match sync/ascync options within a cluster and even between individual transactions.

Recent versions of Postgres have a really flexible replication configuration to cover a whole range of requirements. See e.g. https://www.postgresql.org/docs/current/warm-standby.html#SY...