Postgres documents that their replication protocol can lose committed transactions. https://patroni.readthedocs.io/en/latest/replication_modes.h...
Looking real good.
Let me TLDR them for you
> Advantages of statement-based replication: Proven technology, can be used as an audit log
> Disadvantages of statement-based replication: INSERT DELETE, UPDATE, and REPLACE may not replicate correctly
Are you getting worried yet?
> Advantages of row-based replication: All changes can be replicated.
> Stored functions execute with the same NOW() value as the calling statement. However, this is not true of stored procedures.
Wonderful. Also not a problem in Postgres AFAIK because you're replicating the WAL so it doesn't need to execute it locally.
Don't forget about the pitfalls of replicating CREATE USER and ALTER USER in MySQL
https://www.percona.com/blog/what-if-the-user-exists-on-the-...
MySQL has improved things in recent years but this list used to be much larger. Just go look through their bug tracker. It's not something that instills confidence and I need to deploy databases I can trust will not eat my data. I've had too many customers with broken MySQL databases over the years and zero with Postgres.
Statement-based replication is deprecated: https://dev.mysql.com/doc/refman/8.0/en/replication-options-...
> Stored functions execute with the same NOW() value as the calling statement. However, this is not true of stored procedures.
That's from the "disadvantages of statement-based replication" section, not the row-based replication section. So to recap, the disadvantages you've quoted from the manual are specific to statement-based replication, which is deprecated.
> Don't forget about the pitfalls of replicating CREATE USER and ALTER USER in MySQL
As mentioned in that Percona blog post, all you need to do is add IF EXISTS / IF NOT EXISTS to your SQL and it solves the problem. Or in MariaDB, you also have the option of CREATE OR REPLACE syntax.
Sure, it's a minor footgun for newbies, but not exactly a horrendous problem.
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.
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...